[Winpcap-users] RE: Packet timestamp strangeness (Richard Hansen)
ipopescu at dataq.com
Fri Jun 30 17:02:43 GMT 2006
-----BEGIN PGP SIGNED MESSAGE-----
Gianluca Varenni wrote:
>> First of all, "real time priority" doesn't mean at all that the thread
>> is running real time, because Windows NT is NOT a real time OS. And
>> please be careful before raising a thread priority to real time (raising
>> the thread priority sometimes just hides the source of problem).
It's misleading terminology. But there are cases where it makes a
difference. Those cases usually involve your application taking over the
computer to perform its time-relevant function. Other than those few cases,
I find it's not necessary and generally "locks" up the computer.
>> Second, the problem of the "delay" of 7-15ms is perfectly normal. 15ms
>> is the scheduling time slice on NT SMP. The timestamp that you obtain
>> from GetSystemTime or GetSystemTimeAsFileTime is updated every time
>> slice, so every 10 or 15ms (depending on the kernel you are using).
>> WinPcap instead uses KeQueryPerformanceCounter to obtain the timestamps
>> (usually). Moreover, consider that there's a delay between when we
>> timetag the packets and put in the buffer, and when the app receives
>> them. This behavior is controlled by the timeout you set in
>> pcap_open_live and by the mintocopy parameter that you can set with
>> pcap_setmintocopy(). Please be careful modifying these parameters, as
>> they can affect a lot the CPU load. I suggest you to search through the
>> winpcap-users archives for more details on mintocopy.
"Ke" prefixed APIs are only callable from drivers. You can, however, use the
"user mode" equivalent of those calls. There are two APIs you'll need to use
in order to make use of the high resolution time.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v18.104.22.168 (MingW32)
-----END PGP SIGNATURE-----
More information about the Winpcap-users