On Sun, Jan 04, 2009 at 11:46:25AM -0500, Jim Young wrote:
> >>> Ivan Heninger <ivanh@xxxxxxxxxx> 1/4/2009 9:39 AM >>>
> > Is your the platform Linux on multi-core CPU ? I think negative time is
> > possible on some multi-core CPUs depending on the hardware source for the
> > precision software timer. Use of the TSC source, rather than the linux
> > default pmtimer, can yield better software performance but can also lead to
> > a time offset between to cores in the same CPU.
>
> Fascinating comment!
Interesting Indeed :-)
Although I'm not sure if I have enough background to understand it
correctly. Does each core have it's own wall-clock? What are the TSC
source and the pmtimer source? I guess I have to read into the internals
of the linux clock a little :-)
However, AFAIK the capturing of packets is done by a single process that
does not use threads, am I wrong in assuming that then all timestamps
are generated on one core? So even if both cores have a difference in
their clocks, it would nog yield to this difference being propagated to
the timestamps in the tracefile?
> >>>> From: Sake Blok <sake@xxxxxxxxxx>
> >> Now... the main problem is why wireshark thinks these requests and
> >> responses belong together, although they bend the nature of time ;-)
>
> I too have some tracefiles (in my case "normal" IP traces) where
> the some packets appear "to bend the nature of time". In this case
> the absolute timestamps of the pcap file are NOT in strictly chronological
> order.
>
> The initial time-bending packets can be easily found with the display
> filter 'frame.time_delta < 0': e.g.
>
> tshark -R 'frame.time_delta < 0' -r MYTRACEFILE
>
> My tracefiles with the occasional time-bending packets were captured
> from different systems. One system is a multi-core RH Linux system
> with a 10Gb interface, the other is a dual core Windows XP SP2
> system with a 1Gb interface. The "time-bending" packets do NOT
> appear very often but they do happen.
>
> I had suspected that these "time bends" were possibly due to the
> capturing system's real-time clock being concurrently updated via
> some other task (e.g.ntp) while there was an ongoing libpcap/winpcap
> capture in progress.
Hmmm... I like that explanation of small negative delta times.
All in all I think both explanations do not match the effect that was
seen in the capture by the original poster where the FC response was
seen in frame 16 and the request in frame 254270 which came ~69 seconds
after the response. In this case I think there might have been a
mismatch between request and response (overlapping ID's maybe?).
Cheers,
Sake
