OK.. you are probably right - "time when packet came to winpcap". However - that should not make much difference. If packets are queued prior - I cannot affect that, and I will have to accept that jitter in timestamping process.
What I would want to achieve is to get minimum offset/jitter from there on. I am trying to fix drift of two clocks... As you might have seen - many user complained about drifting of the packets compared to systemtime: for example: http://www.wireshark.org/lists/wireshark-users/201204/msg00038.html http://ask.wireshark.org/questions/3893/timestamps-drift-from-real-time Now I have external hadrware (lets say some AD time), which has its own clock source, which is totally independant from computer. That means that I always have clock drift. I use some procedure to synchronize both clock (basically that means to put both clocks on same time axis), but for that to work perfect, I need to read current time from device. In this case from AD card and from winpcap driver. Currently I use timestamp of packet that I read for synchronizing clocks, but that gives me additional offset (queue from winpcap driver to my reading of packets), which is not perfect and of course increases jitter... If I would have some mechanism to get current clock from winpcap driver (I would need to read same counter that is used for timestamping packets, but I would need to read that counter on demand) I would be able to synchronize both clocks very precisely and would avoid longterm drift. Best Regards, Sašo Piskar On Mon, Oct 8, 2012 at 2:46 PM, Black, Michael (IS) <[email protected]>wrote: > Somebody correct me if I'm wrong here.... > > But I do believe your statement "time when packet came to computer" is > wrong. It's tagged with "time when packet came to winpcap". > > Most OS's (all that I know of) have a TCP queue in the OS. Winpcap > retrieves from that and then tags. So packets can queue up without being > time tagged for a short while. > > What time drift are you trying to fix? Does the computer you're running > winpcap on have a problem? Can't you just run NTP to fix that? It > automatically adjusts for drift on your computer clock. > http://www.meinberg.de/english/sw/ntp.htm#ntp_nt_stable > > NTP can usually achieve 1ms accuracy so you'll be left with some jitter > for "time to winpcap" which should be notably sub 1ms but at least that > jitter will not be drifiting on you. > > > Michael D. Black > Senior Scientist > Advanced Analytics Directorate > Advanced GEOINT Solutions Operating Unit > Northrop Grumman Information Systems > ------------------------------ > *From:* [email protected] [ > [email protected]] on behalf of Sašo Piskar [ > [email protected]] > *Sent:* Monday, October 08, 2012 5:20 AM > *To:* [email protected] > *Subject:* EXT :[Winpcap-users] Timestamping > > Hello, > > I am writing program to sniff ethernet packets. > With "pcap_next_ex" I nomally get the timestamp of the packet. > As I understand, timestamps are calculated with queryperformancecounter in > the winpcap driver. > > I need to synchronize those packets to some other clock (external > device) to fix time drift problem. > If I just use timestamp of received packet, this is actually time when > packet came to computer. I would also need to get current time (as precise > as possible) in order to be able to synchronize packet timestamp with > external clock. > > Is there any way to get current clock from winpcap driver? > > Best Regards, > Sašo > > > > > _______________________________________________ > Winpcap-users mailing list > [email protected] > https://www.winpcap.org/mailman/listinfo/winpcap-users > > -- mail: [email protected] phone: +386 59 07 16 49 DEWESoft - www.dewesoft.com
_______________________________________________ Winpcap-users mailing list [email protected] https://www.winpcap.org/mailman/listinfo/winpcap-users
