saso.piskar at dewesoft.si
Mon Oct 8 06:43:02 PDT 2012
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:
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 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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Winpcap-users