Ask Your Question
0

Frame Arrival Time drift

asked 2018-12-07 17:13:18 +0000

Hi,

We run instances of dumpcap for long periods (weeks or months) on Dell 1U servers with Windows 10 or Windows 10 VMs. We are using WinPcap. Our understanding is that npf grabs the system time when loading and then maintains its own timestamp clock. The result is a steady drift away from the system clock.

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.

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

Does npcap address the issue of arrival time drift?

Thanks and regards...Paul

edit retag flag offensive close merge delete

Comments

Christian_R gravatar imageChristian_R ( 2018-12-07 20:49:04 +0000 )edit

As far as I know the clock isn't updated, and I don't think it can be forced to resync. I also assume that npcap doesn't help much, as it's primary design goal is to replace WinPCAP for nmap, not for high precision packet capture.

But I am sure @Guy Harris knows much more about this than I do :-)

Jasper gravatar imageJasper ( 2018-12-07 21:03:55 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2018-12-08 05:14:49 +0000

Guy Harris gravatar image

updated 2018-12-08 05:16:50 +0000

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.

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

There's a global setting in the registry that controls how the time stamps are generated. Set it to 2 to get time stamps from the system clock.

Does npcap address the issue of arrival time drift?

No, it behaves just like WinPcap, including the registry setting. I've filed an npcap issue suggesting that they support the libpcap time-stamp-type APIs and 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 and later - the kernel interface for that isn't available prior to Windows 8).

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2018-12-07 17:13:18 +0000

Seen: 43 times

Last updated: Dec 08