LARTC - Nov 2005 - Optimizing linux for the routing of realtime video

I''m currently trying to optimize a linux machine which acts as a Layer
3
router of RTP H.263 video.  Occassionally I''ll get delays related to
layer 2
wireless retries, thus rendering the video on the recieving end 
stale/useless.

Is there way to optimize a linux machine to route realtime video? In my 
case, losing a few frames of H.263 is better than having the video delayed 
for 5 seconds (H.263 has its own methods for error concealing which work 
pretty good).

As far as I know, there are a few things I could do:

- Sysctl options allow for some minimal TCP/IP stack configuration
- iptables?
- tc?

Basically, I need some way to discard old data thats sitting in the transmit 
queue.

Regards,

Justin 

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Justin Todd wrote:
> I''m currently trying to optimize a linux machine which acts as a
Layer 3
> router of RTP H.263 video.  Occassionally I''ll get delays related
to
> layer 2
> wireless retries, thus rendering the video on the recieving end
> stale/useless.
Maintaining QoS over wireless links, especially in the presence of 
interference
is tricky, perhaps impossible. My gut feel is that your problems are 
likely all
wireless-related and the solution will lie there too. Perhaps the radios are
queuing subsequent packets behind the one they attempt to re-transmit ?
Often there are tweakable parameters in the radios that you can try to play
with (enable RTS for example).

Good luck !




_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

I saw a wireless qos package. Don''t remember the name. But it exists.
I think there are standards about it, and an implementation in linux.
But you must have an internal wireless pci card I think, or an openwrt 
based wifi router.

David Boreham wrote:
> Justin Todd wrote:
>
>> I''m currently trying to optimize a linux machine which acts as
a Layer 3
>> router of RTP H.263 video.  Occassionally I''ll get delays
related to
>> layer 2
>> wireless retries, thus rendering the video on the recieving end
>> stale/useless.
>
> Maintaining QoS over wireless links, especially in the presence of 
> interference
> is tricky, perhaps impossible. My gut feel is that your problems are 
> likely all
> wireless-related and the solution will lie there too. Perhaps the 
> radios are
> queuing subsequent packets behind the one they attempt to re-transmit ?
> Often there are tweakable parameters in the radios that you can try to 
> play
> with (enable RTS for example).
>
> Good luck !
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>LARTC mailing list
>LARTC@mailman.ds9a.nl
>http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
>  
>

> >> I''m currently trying to optimize a linux machine which
acts as a Layer 3
> >> router of RTP H.263 video.  Occassionally I''ll get delays
related to
> >> layer 2
> >> wireless retries, thus rendering the video on the recieving end
> >> stale/useless.
> >
> > Maintaining QoS over wireless links, especially in the presence of
> > interference
> > is tricky, perhaps impossible. My gut feel is that your problems are
> > likely all
> > wireless-related and the solution will lie there too. Perhaps the
> > radios are
> > queuing subsequent packets behind the one they attempt to re-transmit
?
> > Often there are tweakable parameters in the radios that you can try to
> > play
> > with (enable RTS for example).
The real problem here is that even though the video can handle packet
loss, the wireless link prevents it.  Video is sent w/ UDP packets
thus giving the application control of what to do with packet loss.
However, the wireless link is guaranteeing delivery of those UDP
packets. Thus I agree that the solution will have to be with the
wireless link itself.

If it were me, I would look into providing dedicated APs for the
wireless video. Or maybe go with an AP that supports multiple
channels, and keep the video on a dedicated channel, so you don''t get
interference from other devices. Also make sure you aren''t overloading
the AP (for example, 54 megabit G radio is the total throughput for
_all_ clients talking to it) and make sure there aren''t other APs
around causing interference. A rogue AP set up can cause real havoc,
and newer APs even support ''countermeasures'' to watch for
these APs.

HTH

Dnia środa, 30 listopada 2005 02:37, sophana napisał:
> I saw a wireless qos package. Don''t remember the name. 
Do you mean http://frottle.sf.net/ ?

-- 
Jakub Wartak
-vnull
FreeBSD/OpenBSD/Linux/Solaris/Network Administrator
http://vnull.pcnet.com.pl/

Are you sending anything else besides the H.263 stream over that
wireless link?   As an earlier reply mentioned, your problem could be
related to radio issues - and if so, nothing you can do about it.  Well
maybe there is.  You would need something that would watch the queue of
outbound H.263 packets and get rid of anything older than (some number)
of milliseconds.  I don''t know of any packages that do this.
 
If the issue is contention with other packet streams from other apps
inside your network, then you can prioritize the H.263 stuff so that
these packets tend to the top of the outbound queue.
 
- Greg Scott
 

	-----Original Message-----
	From: lartc-bounces@mailman.ds9a.nl
[mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Justin Todd
	Sent: Tuesday, November 29, 2005 1:03 PM
	To: lartc@mailman.ds9a.nl
	Subject: [LARTC] Optimizing linux for the routing of realtime
video
	
	
	I''m currently trying to optimize a linux machine which acts as a
Layer 3 
	router of RTP H.263 video.  Occassionally I''ll get delays
related to layer 2 
	wireless retries, thus rendering the video on the recieving end 
	stale/useless.
	
	Is there way to optimize a linux machine to route realtime
video? In my 
	case, losing a few frames of H.263 is better than having the
video delayed 
	for 5 seconds (H.263 has its own methods for error concealing
which work 
	pretty good).
	
	As far as I know, there are a few things I could do:
	
	- Sysctl options allow for some minimal TCP/IP stack
configuration
	- iptables?
	- tc?
	
	Basically, I need some way to discard old data thats sitting in
the transmit 
	queue.
	
	Regards,
	
	Justin 



_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc