saso.piskar at dewesoft.si
Tue Oct 9 00:17:16 PDT 2012
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.
On Mon, Oct 8, 2012 at 4:13 PM, Sašo Piskar <saso.piskar at dewesoft.si> 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,
> On Mon, Oct 8, 2012 at 4:00 PM, Black, Michael (IS) <
> Michael.Black2 at ngc.com> 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:* winpcap-users-bounces at winpcap.org [
>> winpcap-users-bounces at winpcap.org] on behalf of Sašo Piskar [
>> saso.piskar at dewesoft.si]
>> *Sent:* Monday, October 08, 2012 8:43 AM
>> *To:* winpcap-users at winpcap.org
>> *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
>> 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:
>> 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
>> 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
>> 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) <
>> Michael.Black2 at ngc.com> 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.
>>> 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:* winpcap-users-bounces at winpcap.org [
>>> winpcap-users-bounces at winpcap.org] on behalf of Sašo Piskar [
>>> saso.piskar at dewesoft.si]
>>> *Sent:* Monday, October 08, 2012 5:20 AM
>>> *To:* winpcap-users at winpcap.org
>>> *Subject:* EXT :[Winpcap-users] Timestamping
>>> 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,
>>> Winpcap-users mailing list
>>> Winpcap-users at winpcap.org
>> mail: saso.piskar at dewesoft.si
>> phone: +386 59 07 16 49
>> DEWESoft - www.dewesoft.com
>> Winpcap-users mailing list
>> Winpcap-users at winpcap.org
> mail: saso.piskar at dewesoft.si
> phone: +386 59 07 16 49
> DEWESoft - www.dewesoft.com
mail: saso.piskar at dewesoft.si
phone: +386 59 07 16 49
DEWESoft - www.dewesoft.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Winpcap-users