Thanks for all your detailed replies! WinPCap´s timestamping method is the best way to do it, because when you are interested on timestamps, then most likely everyone is interested in the relative time between two (consecutive) packets.
If WinPCap would periodically "resync" periodically, it would result in a sudden, absolutely wrong time difference between packets for and after such a resync.
Another thing: if the sending and receiving/capturing systems'
clocks are not synchronized with each other, then how are you measuring the
supposed latency between sending and receiving/capturing?
Of course i don´t measure times between different machines.
Going back to my issue, i discovered that my app itself must produce it. I´m
lucky about it, although i don´t understand it right now:
0) most packets were filtered by a dynamic kernel filter
(just "control frames" and some specific audio frames from hardware reach the user mode)
1) a receiving thread just captures and puts packets into some sort of
pre-allocated ring buffer
2) a analyzing thread gets packets from the buffer, does some processing and puts the rest
into another queue (more or less "control frames")
3) the main thread processes the rest i.e. processes the commands in the "control frames"
and sends out commands
The analyzing thread is able to send audio frames directly to the sound card.
After some days, the main thread receives answers with increasing delay between
sending out commands and receiving the answer from the audio hardware, but
audio frames were /NOT /delayed, therefore it must be some sort of a sync
problem between the analyzing and main thread.
In the main thread a look for packets in the idle phase, but at least every
100ms; i wonder how a increasing time drift can cause a latency of several
seconds.
I don´t expect an answer, because it looks that it´s not a WinPCap problem, i
just write it down to brighten it up for myself a little bit, sorry...
Have a nice day
Helmut
"Fish" (David B. Trout) schrieb:
YET ANOTHER thought (sorry for the sudden flurry of emails!):
WinPCap's timestamp logic starts out as being identical to the system
time but is then incremented based on the high performance (CPU)
clock. Thus, since the high performance clock's frequency /can/ change
over time (due to the CPU being placed into power-saving mode[1]), the
high performance counter technique that WinPCap uses to timestamp its
captured packets with is /_NOT_/ accurate beyond a short period of time.
That is to say, for a capture session lasting only several seconds to
several minutes (several hours might be pushing it), WinPCap's
timestamp /should/ be close enough for most purposes.
But for a capture session lasting /_DAYS?!_/ Forget it!
If WinPCap would periodically "resync" (reinitialize) its starting
base capture time (i.e. its GetSystemTime value), then /perhaps/ the
resulting timestamps might be reasonably accurate for much, much longer.
But when a capture is started, WinPCap obtains the GetSystemTime value
only once at the start of the capture session and then never ever
again retrieves it. Instead, it keeps incrementing it internally (more
or less) based off of the CPU's high performance counter value.
I suppose one /possible/ way of working around this issue would be to
periodically (say, every couple of minutes?) start a new capture
session and then close the original capture session (so as to not lose
any packets). Thus the new capture session would, during its WinPCap
initialization, obtain a new starting/base GetSystemTime value and
thus end up essentially "resyncing" itself with the operating system
clock. That might work.
--
"*Fish*" (David B. Trout)
[email protected]_
*From:* [email protected]
[mailto:[email protected]] *On Behalf Of *Helmut
Vaupotitsch
*Sent:* Tuesday, September 14, 2010 9:18 AM
*To:* [email protected]
*Subject:* [Winpcap-users] timestamping and huge latency
*Importance:* High
Hi Gianluca and all others,
I am facing a major latency problem on *long lasting* capture sessions
which maybe
has to do with timestamping by the driver, every hint to solve it is
appreciated:
We developed a proprietary protocol to configure, manage and monitor
our self-developed hardware, the config software uses WinPCap to
capture and send raw packets.
Everything is working fine, but after some days of continuous
capturing i face:
- On some machines, the latency between sending requests and receiving
the answer
increases to some seconds (can be up to >30 secs after capturing for
a week!)
Closing and re-opening the driver would solve the problem, but i
definitely need to capture
for months and longer without interrupt!
I know that the driver timestamp is drifting apart from the System
Time(which can be
synchronized by e.g. a NTP server), therefore i timestamp the frames
my myself(which
is also important if a use timeouts)
*My question is:**
What could be the reason(s) for huge latency on long lasting captures?
*I know that the latency increases on receiving packets
Currently i don´t know if sending´s latency also increases
Maybe it has something to do with the GetSystemTimeAdjustment setting?
Thanks for reading
Best regards from Austria
Helmut
Gianluca Varenni schrieb:
The return value of QuerySystemTime and QueryPerformanceCounter is
synchronized at the beginning of the capture (to compute the offset between
epoch time and QueryPerformanceCounter), and then the counter and frequency
returned by QPC are used to compute the number of seconds (and microseconds)
and added to the offset.
The timestamping code is available in the source code of WinPcap,
winpcap\packetntx\driver\time_calls.h
Have a nice day
GV
--------------------------------------------------
From: "Jan Martinec" <[email protected]> <mailto:[email protected]>
Sent: Tuesday, September 14, 2010 7:23 AM
To: <[email protected]> <mailto:[email protected]>
Subject: [Winpcap-users] timestamp
Hello!
I've got a question about timestamping method. I know that a timestamp
is got using method QueryPerformanceCounter (resp.
keQueryPerformanceCounter), which is a number of ticks of Performance
counter. But timestamp is by Winpcap returned in "Seconds since Epoch"
format. So how is the recomputation done?
Thank you very much
Best regards,
Jan Martinec
_______________________________________________
Winpcap-users mailing list
[email protected] <mailto:[email protected]>
https://www.winpcap.org/mailman/listinfo/winpcap-users
_______________________________________________
Winpcap-users mailing list
[email protected] <mailto:[email protected]>
https://www.winpcap.org/mailman/listinfo/winpcap-users
------------------------------------------------------------------------
_______________________________________________
Winpcap-users mailing list
[email protected]
https://www.winpcap.org/mailman/listinfo/winpcap-users
_______________________________________________
Winpcap-users mailing list
[email protected]
https://www.winpcap.org/mailman/listinfo/winpcap-users
