[Winpcap-users] Timestamp accuracy question

Gianluca Varenni gianluca.varenni at cacetech.com
Tue Apr 22 15:44:55 GMT 2008

In this case I would probably modify the WinPcap driver to return the original timestamps returned by QueryPerformanceCounter so that computing such difference gives meaningful results. 
Recompiling the driver is not too difficult, what you need is the windows driver kit (WDK) available at connect.microsoft.com. The only problem you might encounter is if you need to run your custom compiled driver on Vista x64 or Win2008 x64 (in this case the driver must be signed in order for the OS to load it).

Have a nice day

PS: please always reply to the mailing list alias, and not to me directly, thanks.

  ----- Original Message ----- 
  From: Alex Foygel (TT) 
  To: Gianluca Varenni 
  Sent: Tuesday, April 22, 2008 6:15 AM
  Subject: RE: [Winpcap-users] Timestamp accuracy question

  The transmitter and the receiver are on the same box; the transmitter can imbed high-resolution timestamps (based on QueryPerformanceCounter) into the messages.

  So, if I were able to extract timestamps (set by the driver) from pcap raw file, which are also based on the values returned by QueryPerformanceCounter, I would be able to calculate the time difference (propagation delay that I'm looking at). In that case, the clock drift or clock adjustments would not matter.



  Alex Foygel


  From: winpcap-users-bounces at winpcap.org [mailto:winpcap-users-bounces at winpcap.org] On Behalf Of Gianluca Varenni
  Sent: Monday, April 21, 2008 7:56 PM
  To: winpcap-users at winpcap.org
  Subject: Re: [Winpcap-users] Timestamp accuracy question



    ----- Original Message ----- 

    From: Alex Foygel (TT) 

    To: winpcap-users at winpcap.org 

    Sent: Monday, April 21, 2008 8:02 AM

    Subject: [Winpcap-users] Timestamp accuracy question


    What is the absolute accuracy of the individual packets' timestamps? As far as I understand, the relative accuracy (one packet relative to another packet captured within the same capture session) is 1 microsecond (aside from the issues with SMP, etc.).


    But the absolute accuracy, if I understand the code correctly, seems to be in the order of milliseconds. The code (time_calls.h) uses KeQuerySystemTime() to get the system time and to calculate the offset between the system time and the high-resolution values returned by KeQueryPerformanceCounter().


    According to the documentation, even though KeQuerySystemTime() returns the timestamps in 100 nanoseconds units, it's being updated once every 10 milliseconds. Thus, depending on when during the 10 ms cycle the Synchronize code ran, the offset calculated by the above mentioned code can be up to 10 ms off.


    Is my interpretation of the code correct?




    A simple way of fixing this problem (if it's a problem at all) seems to be to run KeQuerySystemTime() in a tight loop until the value returned changes (this should take at most 10 ms because that's how often the system time is updated) and then use the new value to calculate the offset. Am I oversimplifying the problem?


  It could work. Please consider that this is just the top of an iceberg. This would fix the 10ms issue, but there are other factors that influence the absolute accuracy of timestamps. In particular, KeQueryPerformanceTimer is not influenced by any time adjustment made on the system clock (e.g. from an NTP server), it's a sort of free running counter.


    The reason I'm asking the question is because I'm trying to understand whether I can compare the timestamps imbedded by my application in my messages  with the timestamps captured by winpcap, to check the time it takes for my packets to get from the application code (through all the layers, including the network stack) to the NDIS layer when it gets captured by winpcap.


  That can be a tough problem. What is the exact scenario you are using? Are the transmitter and the receiver on the same machine?


  Have a nice day



    Thank you for your help,

    Alex Foygel


    Winpcap-users mailing list
    Winpcap-users at winpcap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-users/attachments/20080422/5819490e/attachment.htm

More information about the Winpcap-users mailing list