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 > [email protected] > http://lists.gnu.org/mailman/listinfo/ccrtp-devel
begin:vcard fn:David Sugar n:Sugar;David org:GNU Telephony email;internet:[EMAIL PROTECTED] tel;work:+1 201 215 2609 url:http://www.gnutelephony.org version:2.1 end:vcard
_______________________________________________ Ccrtp-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/ccrtp-devel
