Thank you for your comments, This has confirmed my suspicion of the time drift.
Our workaround at present is simply to overwrite the timestamp provided by NPF with a value obtained from the system when the packet is received in our application (after pcap_read_ex). We use .NET DateTime::Now to provide the time, and it is supposed to give 10ms accuracy. We have no option but to disregard any buffer or processing delay in the NPF driver that occurs between the time that the incoming packet is stamped and the time it arrives in our application. Hopefully this will never be substantial :-) Any comments ?? We would have preferred the increased accuracy of using the NPF timestamp, but the drift is unfortunately unacceptable - the application have to run for a loooooong time. Regards Jaco -----Original Message----- From: Loris Degioanni [mailto:[EMAIL PROTECTED]] Sent: 08 January 2003 13:06 To: [EMAIL PROTECTED] Subject: Re: [WinPcap-users] Drifting reference time in WinPcap NPF driver. Hi, ----- Original Message ----- From: "Gisle Vanem" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 08, 2003 1:42 PM Subject: Re: [WinPcap-users] Drifting reference time in WinPcap NPF driver. > "Loris Degioanni" <[EMAIL PROTECTED]> said: > > > Yes, but note that (as far as I know) this is the only way documented by > > Microsoft to obtain microsecond precise timestamps in a Windows NTx kernel. > > Actually, the driver can provide a different method, based on the RDTSC > > instruction that is present on most processors. To enable it, you have to > > compile the driver with the > > > > compile2k RDTSC > > > > command line. However, I suspect that this method will not completely solve > > the drift problem, since in this case the processor frequency is calculated > > manually when the driver starts, which is not very precise. > > Could the values in > HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0 > > be used instead? It includes a "~MHz" value, but don't know how precise it is. The problems are: - the processor frequency is not granted to remain stable for the whole capture, especially if the capture lasts for a long time. The frequency could have small but sensible variations due to temperature changes. Moreover, technologies like Intel speedstep can change the frequency dinamycally during the capture. - most important, as you noted this value a MHz precision, that is insufficient to avoid considerable drifts Loris > Gisle V. > > # rm /bin/laden > /bin/laden: Not found > ================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[email protected]/ To unsubscribe use mailto: [EMAIL PROTECTED]?body=unsubscribe ================================================================== ================================================================= This is the WinPcap users list. It is archived at http://www.mail-archive.com/[email protected]/ To unsubscribe use mailto: [EMAIL PROTECTED]?body=unsubscribe =================================================================
