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

Reply via email to