[Winpcap-users] timestamping and huge latency

Helmut Vaupotitsch hv at itec-audio.com
Fri Sep 24 00:09:21 PDT 2010


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)
>     _fish at softdevlabs.com_
>
>  
>
> *From:* winpcap-users-bounces at winpcap.org 
> [mailto:winpcap-users-bounces at winpcap.org] *On Behalf Of *Helmut 
> Vaupotitsch
> *Sent:* Tuesday, September 14, 2010 9:18 AM
> *To:* winpcap-users at winpcap.org
> *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" <martij12 at fel.cvut.cz> <mailto:martij12 at fel.cvut.cz>
> Sent: Tuesday, September 14, 2010 7:23 AM
> To: <winpcap-users at winpcap.org> <mailto:winpcap-users at winpcap.org>
> 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
>
>     Winpcap-users at winpcap.org <mailto:Winpcap-users at winpcap.org>
>
>     https://www.winpcap.org/mailman/listinfo/winpcap-users 
>
>         
>
>  
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org <mailto:Winpcap-users at winpcap.org>
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>  
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-users/attachments/20100924/7fcdf2dd/attachment-0001.htm 


More information about the Winpcap-users mailing list