Wireshark-users: Re: [Wireshark-users] recorded time in pcap file drifts from system time
> -----Original Message-----
> From: wireshark-users-bounces@xxxxxxxxxxxxx [mailto:wireshark-users-
> bounces@xxxxxxxxxxxxx] On Behalf Of Guy Harris
> Sent: 07 April 2012 02:56
> To: Community support list for Wireshark
> Subject: Re: [Wireshark-users] recorded time in pcap file drifts from
system
> time
>
>
> 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.
Registry trivia:
I don't believe that this portion of the registry (HKLM\System) is different
for 32 bit or 64 bit apps on a 64 bit OS, possibly because "system" stuff
has to be 64 bit on a 64 bit OS. AFAIK it's only stuff under HKLM\Software
that changes between 32 bit and 64 bit apps.
There is no regedt64, you use regedit.exe. The default one on a 64 bit OS
(the 64 bit one) will see the 32 bit stuff under the
HKLM\Software\WOW6432Node.
You can run the 32 bit version of the registry editor using
%systemroot%\syswow64\regedit.exe. Regedt32.exe can also be found in the
syswow64 directory.
See the KB article http://support.microsoft.com/kb/305097 for more info.
