[Winpcap-users] Timestamping

Mon Oct 8 07:13:30 PDT 2012

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winpcap.org/pipermail/winpcap-users/attachments/20121008/bca24bd5/attachment-0001.html>