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. 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 -----Original Message----- From: Jaco de Wet [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 07, 2003 3:12 AM To: [EMAIL PROTECTED] Subject: [WinPcap-users] Drifting reference time in WinPcap NPF driver. Hi, We're developing an application that listens for certain packets, and then forwards these on to another system. Accurate timestamping is quite important as the downstream system has to correlate these packets with other data. We suspect that the reference time provided by the WinPcap NPF driver is drifting, possibly due to incorrect usage. Let me explain further: During long-running tests we noticed that the packet delay in our application grows by about 1 sec per hour. We define packet delay as: Time when packet is forwarded to downstream system - Header timestamp as provided by WinPcap. (header->ts.tv_sec and header->ts.tv_usec) Initially the packet delay is about 250 ms, but this deteriorates linearly at a rate of ~ 1000 ms per hour. We did some additional tests where we did not use the header timestamp as provided by WinPcap, but replaced this with a new timestamp immediately after completion of the pcap_read_ex() call. In such cases the packet delay was of course much less, but more importantly it did not increase linearly any more. Some background info on our test setup: WIN2000 Professional SP3 OS on a Pentium III 800 Mhz Dell box, with WinPcap version 3.0 Alpha 4. One NIC card: CNET PRO200 WL PCI network adapter. The application is developed using Windows .NET C++ combined with the WinPcap libraries. We are using pcap_open_live and pcap_read_ex with the following settings: Buffer size: 5000000 bytes Timeout: 250 milliseconds Snaplen: 65536 Filter: Simple filter expression e.g. "port 7000 or port 7002" We simulate traffic on the LAN at about 30 MBit/second, of which less than 0.5% of the packets will satisfy the filter criteria. Even if we stop simulating traffic for a while, and then start sending packets again later, the reference time continues to drift linearly. During this "quiet" time there may still be very low activity on the LAN, which indicates that the drift does not seem to be related to the current throughput. Tests on two other PCs provided similar results, although the drift is much less on a faster PC. Is it possible for the NPF reference time to drift ? Has anyone else seen this and is there anything the user can do to prevent this ? Thanks for any help.... Regards Jaco de Wet ====================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[email protected]/ To unsubscribe use mailto: [EMAIL PROTECTED]?body=subscribe ====================== ================================================================= 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 =================================================================
