TimestampMode

[fwf02]

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\npcap\Parameters

TimestampMode 1 what is it ?

i know 0 is the default and uses KeQueryPerformanceCounter. This provides great precision (some microseconds) but is less reliable on SMP/HyperThreading machines since it doesn't return monotonic values across multiple CPUs. 2 uses KeQuerySystemTime instead, which is more reliable on SMP/HyperThreading machines, with a precision of a scheduling quantum (10/15 milliseconds) 3 uses the i386 RDTSC instruction. This is also less reliable on SMP/HyperThreading/SpeedStep machines and has a precision of some microseconds.

[guyharris]

1 is an undocumented, deprecated, and supported-only-in-WinPcap-not-in-Npcap mode.

0, as it uses the performance counter of the CPU on which it's running, is not guaranteed to be synchronized with the counter on other CPUs; it's also not guaranteed to be synchronized with the KeQuerySystemTime() counter that's also used for most system time stamps.

1 has the internal #define name of TIMESTAMPMODE_SYNCHRONIZATION_ON_CPU_WITH_FIXUP, which is similar to 0 except that, in WinPcap but not Npcap, the time stamp is calculated based on a per-CPU time base and the performance counter, rather than on CPU 0's time base and the performance counter. The WinPcap developers may have considered this an interesting but failed experiment and never bothered to document or support it; the Npcap developers dropped it.

2, as it uses KeQuerySystemTime(), is obviously guaranteed to be synchronized with the times from KeQuerySystemTime(), but doesn't have a resolution as high as that of the performance counter.

3 directly reads the time stamp counter, and has problems similar to those of 0.

In newer versions of Npcap, there's also 4, which, on Windows 8 and later, uses KeQuerySystemTimePrecise(). It has the "synchronized with the system clock" and "synchronized between CPUs" advantage of KeQuerySystemTime(), but gives high-precision time stamps - the best of both worlds. It has the disadvantage of not being available prior to Windows 8; on systems prior to Windows 8, time stamp mode 4 falls back on KeQuerySystemTime().

For more than you ever wanted to know about getting time stamps in Windows, see Acquiring high-resolution time stamps.

[matman13]

@guyharris, we are using '4' for our purposes. When this time is reported back through the timeval struct in the pcap_pkthdr struct of pcap_next_ex(), is it still broken out into seconds and microseconds? Or is the value returned by KeQuerySystemTimePrecise() returned as a single number "as is," i.e., the 32 high bits in tv_sec and the 32 low bits in tv_usec (or vice versa)?

[guyharris]

When this time is reported back through the timeval struct in the pcap_pkthdr struct of pcap_next_ex(), is it still broken out into seconds and microseconds?

Yes. Any behavior other than, by default, providing them as seconds and microseconds or, if pcap_set_tstamp_precision() has been called with PCAP_TSTAMP_PRECISION_NANO and that call has succeeded, providing them as seconds and nanoseconds, would be a libpcap/Npcap bug.

Currently, calling pcap_set_tstamp_precision() with PCAP_TSTAMP_PRECISION_NANO is not supported in Npcap. That could be changed, although it would require changes both to the Npcap driver/library and to libpcap.

[matman13]

Roger that. And thanks for the clarification. Hopefully others will find the question/answer useful.

[ValeZAA]

Currently, calling pcap_set_tstamp_precision() with PCAP_TSTAMP_PRECISION_NANO is not supported in Npcap.

Is there any chance that will be fixed to get 100 ns precision? Finally windows will have nanoseconds like Linux. I do not know any way to get nanoseconds on Windows.