 | 1 | initial version |
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).
The
| | 2 | No.2 Revision |
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.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).
The
| | 3 | No.3 Revision |
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:
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 that.)
If you set the registry key HKLM\System\CurrentControlSet\Services\NPF\TimestampModeto 2, WinPcap and Npcap will use KeQuerySystemTime() to get time stamp, so you'll get low-resolution time stamps synchronized with the system clock. See There's a global setting in the registry that controls how the time stamps are generateda message about that from the WinPcap mailing list. 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 Note that a value of 3 is supported only on 32-bit x86 machines (not 64-bit machines or Arm machines), and is not supported in Npcap 0.9989 or later. As per the beginning of this answer, on Windows 8 and later and with packet capture on UN*Xes (and offer, Npcap 0.9989 or later, the best choice 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).
| | 4 | No.4 Revision |
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:
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 that.)
If you set the registry key HKLM\System\CurrentControlSet\Services\NPF\TimestampModeto 2, WinPcap and Npcap will use KeQuerySystemTime() to get time stamp, so you'll get low-resolution time stamps synchronized with the system clock. See a message about that from the WinPcap mailing list. Note that a value of 3 is supported only on 32-bit x86 machines (not 64-bit machines or Arm machines), and is not supported in Npcap 0.9989 or later. As per the beginning of this answer, on Windows 8 and later and with Npcap 0.9989 or later, the best choice for the setting, in most if not all cases, is 4.
