Stephen Hemminger wrote:
On Sat, 05 Aug 2006 03:28:38 -0400
Alan Shieh <[EMAIL PROTECTED]> wrote:
Hi everyone,
I sometimes see packets stored out of order in pcap files that generated
by "tcpdump -i any" on kernel 2.4.26 with all packets arriving and
departing on an e1000 NIC. That is, the ordering by receive timestamp on
the packets is not the same as the ordering of the packets within the file.
In my precise scenario, packets of RX packets show up in the log 230 ms
later than they ought to based on the receive timestamp. The kernel
behavior (e.g., the packets that are sent by this node) seems to reflect
the arrival of the Rx packet at the position in the logfile, rather than
the arrival time according to the timestamp.
What are some of the known causes of this behavior? I'd like to know
what locks, etc. might be causing this processing / capture delay.
SMP or single CPU? What is the clock source being used?
If you had a CPU like dual-core AMD that doesn't sync TSC's and
that was the clock source, the timestamps could be wrong.
Single CPU, using TSC. The behavior of the system is as if the RTT is
230ms, so I think a queue is building up somewhere within the kernel. I
am trying to narrow down the possible ways my experimental code could
have caused such a queue backlog. I've tried setting netdev->quota in
the e1000 module to a much larger value, thus forcing the backlog to be
processed faster, but that does not help.
Alan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
