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? 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? 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]
