Hi,
So 0 is best (32 and 64 bit) as in precision, therefore default, but may/will
deviate in the long run.
2 is better for the long run captures, but (much) less precision.
"Choose wisely gentlemen"
Thanks,
Jaap
On 04/07/2012 03:55 AM, Guy Harris wrote:
On Apr 6, 2012, at 8:06 PM, Stuart Kendrick wrote:
Perhaps there is no fix for this ... but I figured I'd ask.
Absolute time, as recorded in the .pcap file, tends to drift from system
time.
Or, more generally and accurately, "packet timestamp times, as supplied by WinPcap, may drift from the system time". Those are the time stamps that get written to pcap and pcap-ng files by tcpdump/WinDump, dumpcap, etc..
This is, I think, not true on UN*Xes (with libpcap) when the time stamps are supplied by the system (rather than by the network adapter, as can be the case with some adapters, some OSes, and newer versions of libpcap; the default is to use system time stamps, though), as packet time stamps come from the same clock that supplies time()/gettimeofday()/etc. values.
On Windows, however, the WinPcap driver, on x86 machines can run in one of three modes:
http://www.winpcap.org/misc/changelog.htm
"The method used by the driver to timestamp packets can now be changed without recompiling the driver, modifying a registry key:
HKLM\System\CurrentControlSet\Services\NPF\TimestampMode
Possible values are
� 0 (default) -> Timestamps generated through KeQueryPerformanceCounter, less reliable on SMP/HyperThreading machines, precision = some microseconds
� 2 -> Timestamps generated through KeQuerySystemTime, more reliable on SMP/HyperThreading machines, precision = scheduling quantum (10/15 ms)
� 3 -> Timestamps generated through the i386 instruction RDTSC, less reliable on SMP/HyperThreading/SpeedStep machines, precision = some microseconds"
In modes 0 and 3, the time stamps don't come from the same source as the system time, and can drift apart.
On x86-64 machines, mode 3 isn't supported (because generating an in-line RDTSC instruction is a pain, according to a comment in time_calls.h in the source for the NT flavor of the driver, "inline assembler is not supported with the current AMD64 compilers" - "NT" here includes Windows NT 5.x, i.e. W2K AND XP, and 6.x, i.e. Vista, 7, etc.), but it looks as if modes 0 and 2 are.
Mode 0 is the default, so the time stamps can drift.
Is there a way around this? I suppose I could stop and restart my capture every few hours, to give Wireshark a chance to grab Real Time. Other thoughts?
Fire up Your Friend Mr. Regedt32 (or Regedt64 if there is one - somebody claimed either in a WS bug or a WS mailing list that there are separate 32-bit and 64-bit registries, and I suspect the driver, being 64-bit on 64-bit Windows, uses the 64-bit registry) and set the registry key in question to 2.
