Where can I upload a 70MB trace?
Regards
Alex
Sake Blok schrieb:
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
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe