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 18:23:29 +0100
------------------------------
Message: 2
Date: Sun, 15 Mar 2009 12:28:59 -0700
From: Jeff Moore <email@hidden>
Subject: Re: Socket recv behaviour in real-time context
To: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes
Basically, 50 milliseconds of latency means that your thread is not
running when you think it should be running. You'll want to use tools
that let you take a look at the scheduler activity. This means using
tools like the system trace profile in Shark or just plain old kernel
tracing.
You'll probably also want to find tools that can help you correlate
the thread activity with what's going on with the networking side of
things. Shark may help you a bit with that, since I'm sure there are
probably a few system calls involved with networking.
On Mar 15, 2009, at 12:16 PM, Stéphane Letz wrote:
Message: 1
Date: Sat, 14 Mar 2009 17:45:46 -0700
From: Jeff Moore <email@hidden>
Subject: Re: Socket recv behaviour in real-time context
To: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=iso-8859-1; format=flowed;
delsp=yes
I don't really know a whole lot about sockets or our network stack.
But, your description of the problem sounds like there could be a
priority inversion problem on your slave machine. Even though the
thread you have servicing the socket is a real time thread, I'd bet
good money that the thread in the kernel that feeds the socket is
not.
This means that the more activity you have in your real time threads
(including the HAL's IO thread or any MIDI threads) will cause
scheduling latency for lower priority threads.
That said, 50 milliseconds seems completely crazy. You'd have to
have
an awful lot of real time threads doing work to get that kind of
scheduling latency. Have you gotten any kernel traces?
On Mar 13, 2009, at 10:30 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.
But I don't see how to get a trace of what happens in the kernel at
that time... Should the /Developer/Examples/CoreAudio/PublicUtility/
CALatencyLog.cpp tools be used then ?
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