Hello Loris,

You are correct. I did not mean to suggest that the code is bad. There
is no other way that I have seen to get microsecond granularity in
timestamps. 

I guess the driver could get the tick frequency at somewhat regular
intervals (every 10 or 20 seconds) and either use the new value or use
an average of all the values it has seen. But this can still lead to
goofy behavior if the frequency values vary by much. We might see
timestamps that jump forward, or more importantly, jump backward in
time! Calling the KeQueryPerformanceCounter() too often in the driver
can also cause interference with other drivers and applications, so that
is not recommended by Microsoft.

I don't know what the answer is to this issue.



Thank you,

(The information contained in this document is considered proprietary to
Spanlink Communications.  Use of this document is restricted pursuant to
Spanlink instructions.)


David Barnish
Senior Software Engineer
Research And Development
[EMAIL PROTECTED]
(763) 971-2175
Fax: (763) 971-2375

Spanlink Communications
7125 Northland Terrace, Suite 100
Brooklyn Park, Minnesota 55428
(763) 971-2000
 

-----Original Message-----
From: Loris Degioanni [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 08, 2003 6:16 AM
To: [EMAIL PROTECTED]
Subject: Re: [WinPcap-users] Drifting reference time in WinPcap NPF
driver.


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
==================================================================


================================================================= 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
=================================================================

Reply via email to