On Tue, May 25, 2004 at 11:25:06AM +0900, Stock, Stuart [TKY] wrote:
> This is a bit complicated, so please bear with me. The short version is: we
> have 3 instances of the same application all consuming the same low rate
> (max 1.5 MBps) multicast data. Randomly one of the instances will report
> out-of-order reception of the data while the other 2 see the data correctly
> ordered. All of the instances are on the same switch and consume data from
> the same source. Ethereal dumps of these events consistently show a negative
> frame.time_delta for the instance reporting the problem and normally ordered
> data for the 2 others.
>
> I would think that the issue lies somewhere with the kernel or ethernet
> driver since the timestamps show the data was received off-the-wire
> correctly, but is mixed-up before being handed to libpcap/my application.
> The OS is Red Hat Linux AS 2.1 x386.
>
> My questions are:
> 1. Anybody experienced similar out-of-order problems and might be able to
> shed some light on this?
I haven't dealt with such a problem myself, so I can't help you there.
> 2. Where do the libpcap timestamps really come from? Looking at my libpcap
> sources I see pcap_pkthdr.ts getting its value from ioctl(handle->fd,
> SIOCGSTAMP, &pcap_header.ts) but I'm not sure if it's the file handle that
> supplies the timestamp or the underlying driver.
It's OS-dependent, but, in Linux, it's ultimately done somewhere in the
networking stack, either in the driver or in routines the driver calls -
I forget which.
Libpcap receives packets from a socket, just as your application
presumably does; as such, if there's something in the networking stack
causing packets to be delivered to sockets out of order, it might affect
both Ethereal (or tcpdump or some other libpcap-based application) and
your application.
You should probably ask the Linux network stack developers about this.