Wireshark · Wireshark-users: Re: [Wireshark-users] Negative Fibre Channel scsi_time values

[Ivan Heninger <ivanh@xxxxxxxxxx>]

Certainly an external update of the system clock between 2 operations that mark a time stamp could bend time. This seems like it would be a rare event since realtime clock updates via NTP would typically run once a day or maybe once a week.

The hardware clock selection in Linux is done in the grub.conf file, clock=[tsc|pmtimer|hpet] You can verify which time source in in use by issuing

cat /var/log/dmesg | grep timesource

There is lots of web noise about high resolution time sources some of which points out the potential pitfalls of tsc.

Ivan Heninger


IBM Software Group

"Jim Young" ---01/04/2009 11:48:42 AM---Hello Ivan,

From:	"Jim Young" <sysjhy@xxxxxxxxxxxxxxx>
To:	"Community support list for Wireshark" <wireshark-users@xxxxxxxxxxxxx>
Date:	01/04/2009 11:48 AM
Subject:	Re: [Wireshark-users] Negative Fibre Channel scsi_time values

---

Hello Ivan,

Fascinating comment!

>>> 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.

>>>>  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.

Comments?

Thanks,

Jim Y.


___________________________________________________________________________
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