[Winpcap-users] RE: Packet timestamp strangeness (Richard Hansen)

[Ioan Popescu]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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 v1.4.2.2 (MingW32)

iQIVAwUBRKVZMnGK1KGABytRAQoFEA//Wxn1S9tdlhLCeqqHGCSLR6UzMmK8GKDZ
CCiwe9I9OmIydfDK5oUg3VmpoGPN1DnvRa9UQ0RYblOG78DxPBrLcC6XrqKM8kgM
CgyKqquRuiTEPXYdsY6EQfztGqaFY+o/SllQQxgKEYT1iZ9Ywu8Cow/KkxLl/oT/
+hL35tLtLXLC0ORMqvyMP+ciANoHHL4cFmYLd2Ih8wM8L/raH4aUDYJjU8dUBM8c
iKfNpK8bDtXmpPzx1ZHpD7ALUQw5+6/V731S5QT2NHrPAay2Xksx00/jfCeBR6Cx
h/t4D1jkYyFNRz2qg8W21GEe7BvNlcPLJGpPfUtxhjHcHyyZ5+eZrJ4KMnxj8Pw2
V1bo0V/97ju9fTpgyxFDwxtba3rLqdXLIRiVfgzAEvn997vJkGN1JEkYqxjBKyEP
FV+B1bLS9MFIALSOYYAM+obf5pU/vcR2ZUDUxAv/misRyFYDFVLPsEWGtiFzyUo3
zFxbhT4oLDTv4WkrjaJz4oXAmfYkKFug990b97KzjOu65HIC1muNfDEtRRvWHkXk
NDZ5C1RhtiVSA3IisXiW8GDfTEile05xnxoHbYjhZhF/Cno+y1FZDIiVKeyy1tkU
Fanuq2l+9Sl0IsdvzcdraAnuaBrTGNk/9JBhuHYgBTYfKhzX6/gOmAyDRGAwRs2J
hXTEnsQELek=
=rH1l
-----END PGP SIGNATURE-----