Frame Arrival Time drift

edit

Does npcap address the issue of arrival time drift?

With Npcap 0.9989 or later, if you set the registry key HKLM\System\CurrentControlSet\Services\NPF\TimestampMode to 4, then:

1. on Windows 8 or later, you will get high-resolution time stamps that are synchronized to the system time;
2. on Windows 7, you will get low-resolution time stamps that are synchronized to the system time.

On Windows 7, due to the lack of a kernel interface to get high-resolution system time (KeQuerySystemTimePrecise()), high-resolution time stamps synchronized to the system time aren't available; you have a choice between high-resolution time stamps not synchronized to the system time (that's the default) or low-resolution time stamps that are synchronized to the system time. KeQuerySystemTimePrecise() was introduced in Windows 8.

(See my comment on Npcap pull request #19 for links to Microsoft documentation telling you more about time stamping on Windows, both in the kernel and in userland, than you probably ever wanted to know.)

I noticed that there is a --time-stamp-type option for dumpcap. I've tried listing supported timestamp types on my Dell XPS running Windows 10 but get nothing listed.

Currently, Linux is the only OS on which time stamp types other than the default "system time, at whatever precision you get" are supported.

I filed an npcap issue suggesting that they support the libpcap time-stamp-type APIs, default to "host time stamp" just as happens with packet capture on UN*Xes, and offer, for what it's worth, a high-resolution time stamp using the system clock on Windows 8. Some of the necessary plumbing is present in Npcap 0.9989, but more is needed - and it's not clear whether Windows 8 and later should offer any choices other than "high-precision time stamps synchronized with the system clock".

Is there a way to force npf to periodically check the system clock and resync its internal timestamp?

No, but there's a way to get WinPcap to use the system time to time stamp packets; the advantage is that the time stamps don't drift relative to the system clock and the disadvantage is that the call the driver makes to get the system clock value (KeQuerySystemTime()) gives system clock interrupt precision (i.e., it fetches a system variable that's updated on every clock interrupt), with clock interrupts happening at intervals in the millisecond range, so packet time stamps aren't very high-resolution.

(Given that the time between the arrival of the last octet of the packet on the network adapter and the time-stamping of the packet in the network stack is variable, high-resolution host time stamps may not be as useful as some might want. This also applies to high-resolution time stamps using the x86 time stamp counter and Windows kernel performance counter. BTW, the x86 time stamp counter is only available on 32-bit x86 - when the code was written, at least, the compiler didn't support in-line assembler for 64-bit x86, so they didn't bother implementing ... (more)