Hi, ----- Original Message ----- From: "David Barnish" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 07, 2003 6:39 PM Subject: RE: [WinPcap-users] Drifting reference time in WinPcap NPF driver. >
> Here is how the driver creates the timestamp for the accepted packets: > > 1. When a driver instance is opened by an application, it calculates an > absolute start time value for the system (boot time) which is the number > of ticks since 1/1/1970. > 2. It calls KeQueryPerformanceCounter() to get the tick frequency for > the system (number of ticks per second). > 3. When a packet is accepted by the driver, it gets the current tick > count (ticks since boot) and adds this to the start time value. This > give us the number of ticks since 1/1/1970. This value is divided by the > tick frequency to get the number of seconds and microseconds to use in > the packet header for the timestamp values. > > The code itself looks fine. > I suspect that the frequency value, obtained from the system, and used > for the time calculations, is to blame. I have seen some information on > the net that suggests that the values returned from > KeQueryPerformanceCounter() are not 100% accurate. If the frequency > reported by the system was 1000 ticks per second, but the system was > really running at 900 ticks per second, you would expect to see > timestamps calculated with the innaccurate frequency to drift over time > as you are seeing. > > If this is indeed the case, the method used by the driver is flawed by > relying on an unreliable value to use in its timestamp calculations. 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. Loris > Unless you want to dig into the driver code, there is not a lot you can > do with the packet timestamp values. If you can get the granularity you > need at the application level, you can use that method. > > Hope this helps. > > > David Barnish > Senior Software Engineer > Research And Development > [EMAIL PROTECTED] > Spanlink Communications ================================================================== 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 ==================================================================
