[Winpcap-users] Timestamping

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.

Best Regards,
Sašo

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,
> Sašo
>
> 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
>> 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) <
>> 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.
>>> 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:* 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
>>>
>>>   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
>>> Winpcap-users at winpcap.org
>>> https://www.winpcap.org/mailman/listinfo/winpcap-users
>>>
>>>
>>
>>
>>  --
>> 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
>> https://www.winpcap.org/mailman/listinfo/winpcap-users
>>
>>
>
>
> --
> 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...
URL: <http://www.winpcap.org/pipermail/winpcap-users/attachments/20121009/e044d687/attachment.html>