[Winpcap-users] Timestamping

[Sašo Piskar]

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