Re: Socket recv behaviour in real-time context
Re: Socket recv behaviour in real-time context
- Subject: Re: Socket recv behaviour in real-time context
- From: Stéphane Letz <email@hidden>
- Date: Mon, 16 Mar 2009 23:11:58 +0100
Le 16 mars 09 à 21:50, Jens Alfke a écrit :
On Mar 16, 2009, at 10:23 AM, Stéphane Letz wrote:
Well the RT thread is not disturbed by other RT threads! The high
latencies I can see occurs already when a *compilation* is done.
I could record several latencies peaks (like 9,2 ms or 18.4 ms)
using Shark with an audio network process that runs at 256
frames / 44.1 (so a period that should be about 5 ms.) The system
call that has the long wait time is "recvfrom_nocancel" and is
interleaved with system calls related to the compilation.
Is it possible your buffer is getting paged out during the
compilation, so you get hit with a page-fault when the kernel tries
to fill it in with the received data? Compilation is pretty memory-
intensive.
Do you mean the buffer associated with the socket? or audio buffers
used in the process? Maybe. I'll check.
(And forgive me for not remembering the earlier messages in the
thread, but you did set the socket to nonblocking, right?)
No, the socket is in blocking mode. The "master" is synchronized on
it's real audio callback and send/recv audio paket to the slave. The
idea is that the reception of the audio packet trigger the audio
cycle on the "slave" machine.
But I don't see how to get a trace of what happens in the kernel
at that time...
I am pretty sure Shark can get samples within the kernel threads,
but IIRC you have to use a special mode to do that, and I don't
know how to set that up.
—Jens
Thanks
Stephane Letz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden