Re: [Ccrtp-devel] ccRTP and real-time Linux ?

[David Sugar]

Two things a more realtime system may accomplish for ccrtp which,
depending on the application, may be very useful, is higher resolution
scheduling timers, and deterministic scheduling.  Combined these may
allow both for higher packet rates per process and less packet "jitter".
 However, packet jitter, particularly for very high packet rates, may be
less relevant than inconsistent transport latency, even in a local
network, and the streaming client that will be receiving will need to
buffer some data anyway.  Higher resolution scheduling can be achieved
in the Linux kernel by tweaking the tic count and recompiling.

In Bayonne we use the existing soft realtime capabilities of the Linux
kernel to elevate the Bayonne process above other user mode processes
that may be running, and this so far has been adequate.  For telephony
we typically process 20 millisecond audio frames (50 packets per second)
which fits well within the scheduling resolution of most posix kernels
without introducing excessive jitter.  Video can prove more demanding,
at least for scheduling a raw packet rate, however.

Most hard realtime linux kernels, like RTLinux, create an entirely
separate realtime process environment that does not have access to the
regular kernel application services, including network transport, but
offers a fifo or other facility to communicate between the realtime part
and the normal process part.  These are typically used to interface to
hardware which have hard realtime time constraints.  There are
specialized realtime posix systems, like for example QNX, which do offer
hard realtime deterministic scheduling in the native kernel/application
environment, and there may be some more realtime variants of a more
native Linux kernel/process environment as well out there, though I do
not know offhand.

QoS scheduling can have a very useful impact, whether in regard to
overall bandwidth management, or to jitter, as QoS scheduling also
effects packet scheduling, and hence effects when the RTP packet created
by the application are actually transmitted.  This is important when a
lot of mixed traffic is being queued from different processes on the
same machine, for example, when RTP based services are running on a
machine offering web services, or that has network mounted filesystems.

Guillaume Fraysse wrote:
> Hello everyone,
> 
> I've been using ccRTP in my compagny for 2-3 years in my compagny and
> have been quite happy with it. Even if I raised some bugs sometimes :)
> 
> We are currently developping a platform which will be quite RTP
> intensive (lots of simultaneous sessions on a given computer audio for
> a start then , I hope, video too), and as QoS is important I've been
> thinking about using a real-time linux (RTlinux or RTAI) as the OS
> running the platform.
> 
> I've been doing some reading, including this lis's own David Sugar's paper
> "GNU Bayonne: Telephony Services for Freely Licensed Operating
> Systems" (found here :
> http://www.realtimelinuxfoundation.org/events/rtlws-2002/paper.html)
> where he talks about the short-coming of real-time under Linux. But no
> real-time linux get mentionned (I guess back in 2002 neither RTAI nor
> RTlninux were stable enough).
> I also found this paper about a video streaming server qwhere they do
> use rtlinux and do some kind of comparison :
> http://citeseer.ist.psu.edu/gialama01divisor.html.
> 
> It's really an open question. Has anyone been using that kind of
> plat-form ? Has anyone any return on experience to share ?
> 
> To go further into the details, where would it make more sense to
> implement the hard real-time of the platform ? Would it make sense to
> have a rtlinux/RTAI version of ccRTP ? Would if make more sense to do
> that in the client ?
> 
> I hope I don't say anything too foolish as I'm far from being an
> expert  at real-time OSes but I'm really interested by anyone's
> opinion on that subject.
> 
> Best regards,
> Guillaume
> 
> 
> _______________________________________________
> Ccrtp-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/ccrtp-devel

dyfet.vcf
Description: Vcard