On Wed, Mar 01, 2006 at 12:04:39PM +0100, Ragnar Lonn wrote:
> Can anyone give me some ideas about where I should be looking to find/fix
> this problem or if there is any probably workaround?
The em(4) driver, probably. Locking on 4.x is quite different -- the kernel
in 4.x is not preemptive and u
> Hello
> I am setting up a framework for measuring one way delay between two Internet
> end points.
> For higher accuracy I am using libpcap time stamps (from the packet header)
> at the reciever.
> Does any one know if there is any method for improving accuracy at the
> sender side.
> Is it poss
Hate to follow up, but realized a mistake... NIC's with TCP offload
engines in hardware may put the TCP timestamp option in the header.
I know from a co-worker that the Nvida TOE chipset does for example.
On 3/1/06, Aaron Turner <[EMAIL PROTECTED]> wrote:
> No, NIC's don't put timestamps in pack
No, NIC's don't put timestamps in packets. And depending on your
OS/NIC driver, the libpcap timestamp of the packet could be wrong or
at least non-sensical too (I've seen packets stamped with an earlier
timestamp then the previous read packet).
IMHO, your best bet is to either use the TCP timesta
Hello
I am setting up a framework for measuring one way delay between two Internet
end points.
For higher accuracy I am using libpcap time stamps (from the packet header)
at the reciever.
Does any one know if there is any method for improving accuracy at the
sender side.
Is it possible for sender's
Hello all,
I have a problem with libpcap, which may or may not be a problem with
BPF but
I thought I'd ask here anyhow, to make sure.
I'm writing an application that listens promiscuously to an interface
and which also
generates packets on the same interface. It is not multithreaded so it
ne
