Hi, > At 10:35 22-07-02, you wrote: > >Hi Mark. > >A problem similar to your one has been reported by other users: with current > >WinPcap different capture instances are not synchronized and show a delta of > >some microseconds on the same single packet. I worked recently to fix it, > >with a global time reference shared among all the capture instances. I think > >that a similar solution could be adopted in your case: exporting the time > >reference from NPF.sys in order to share it with your application, like > >described in your second proposal. This could be done for example with an > >IOCTL that exports the time reference (Open->StartTime in current version of > >the driver) of WinPcap. > > Sounds good. Realistically, is this a change which is likely to be made to > WinPcap? If it is, what sort of timescale would be involved?
As soon as someone will provide the patch... sources are available :-) > My only concern about this solution is what happens under Win98. WinPcap > doesn't use KeQuerySystemTime and KeQueryPerformanceCounter like the NT > version does. Are the VTD calls accessing the same values just by a > different route? I suppose yes, however I never investigated this issue. Loris > Regards, > > Mark Lamb > > > >Loris > > > >----- Original Message ----- > >From: "Mark Lamb" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Sent: Wednesday, July 17, 2002 3:03 PM > >Subject: [WinPcap-users] Packet timestamps > > > > > > > Hi, > > > > > > I'm using WinPcap in conjunction with a different source of timestamped > > > messages and I need to be able to merge the packets/messages in their > > > correct chronological sequence to microsecond accuracy. > > > > > > WinPcap uses the performance counter as the basic packet timestamp but > >then > > > converts it to seconds + microseconds since Jan 1 1970 by adding a value > >it > > > calculates during initialisation based on the system time > > > (KeQuerySystemTime). This provides a very accurate timestamp of each > >packet > > > relative to other packets but the absolute time value relative to 1970 is > > > determined by the accuracy of the system time. This is about 10ms on NT > >and > > > (I believe) about 55ms on Win98. > > > > > > This would be no problem if my only source of packets/messages was WinPcap > > > - I don't care that the wall clock time may be milliseconds out. However, > >I > > > need to merge these packets with others from a different driver which also > > > have timestamps in terms of s/us from Jan 1 1970. As both of these > > > timestamps are based on a value which only has (at best) 10ms accuracy, I > > > can't reliably merge them into a chronological stream. > > > > > > I can think of two possible solutions, neither of which I like very much. > > > The first is for WinPcap to provide the performance counter value as well > > > as the s/us timestamp. I can already get this count from my other driver > > > and it would allow me to merge them properly and calculate the wall clock > > > time myself (once only). > > > > > > The other possible solution is for WinPcap to make accessible outside the > > > driver the value it calculates on initialisation. I can then apply this to > > > the other messages. I'm not sure if this solves the problem for Win98 as > > > well (I need to support Win98 and Win2k). > > > > > > I'd be grateful for any comments or advice on any other possible solutions > > > to this. > > > > > > Thanks in advance, > > > > > > Mark Lamb > > > > > > -- > Mark Lamb > Schlumberger > Ferndown Industrial Estate > Wimborne > Dorset > BH21 7PP > > +44 (0)1202 850943 > [EMAIL PROTECTED] >
