Hm... now I have an idea, how to get current clock, but I am not 100% sure if this is correct... I would only need someones confirmation, that I am thinking in the right direction.
Since winpcap remembers clock on start of acquisition (i.e. pcap_open_live) and then uses keQueryPerformanceCounter function for determining timestamp of packets on arrival, I can do the same (similar) thing on my side. If I remember clock when I call pcap_open_live with QueryPerformanceCounter(StartTime) and than check at some intervals "QueryPerformanceCounter(CurrentTime) - StartTime", I can get current clock of winpcap. Is this correct? I mean - this has to work if keQueryPerformanceCounter and QueryPerformanceCounter are same system functions. Best Regards, Sašo On Mon, Oct 8, 2012 at 4:13 PM, Sašo Piskar <[email protected]> wrote: > Dear Michael, > > I don't need NTP synchronization for my case... That won't do much good... > As I have read how timestamping works in winpcap. > When measurement is started, winpcap reads current systemtime to get start > time. After that it uses queryperformancecounter and does not read computer > RTC anymore. > That is also fine with me, because I don't want it to jump in time when it > synchronizes back to system time, if it was corrected with NTP. I need > winpcap to be running continuously. > > All I need is to get current timestamp of winpcap driver to be able to > synchronize its clock to my other clock. > > Best Regards, > Sašo > > On Mon, Oct 8, 2012 at 4:00 PM, Black, Michael (IS) < > [email protected]> wrote: > >> And see if changing your power management helps. I recently had some >> systems where NTP gave up to due to clock drift from power management and >> changing power management fixed the drift so NTP could synchronize. >> >> >> 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 8:43 AM >> *To:* [email protected] >> *Subject:* EXT :Re: [Winpcap-users] Timestamping >> >> 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 >> >> > > > -- > mail: [email protected] > phone: +386 59 07 16 49 > DEWESoft - www.dewesoft.com > > -- 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
