Re: [LARTC] Wireless links + Realtime video >= Headache! (long queue

[Carl-Daniel Hailfinger <c-d.hailfinger.devel.2005@gmx.net>]

Hi,

Justin Todd schrieb:
> Realtime H.263 Video (UDP) flows from the encoder to the DVR at
> 500kbit/sec peak. (avg is about 275-300). There is also a bit of
> sporatic 2-way TCP communication.
> 
> ***Problem: When bit errors on the wireless link occur, video will
> get jerky and get behind (sometimes as much as 20 seconds!) and then
> suddenly the video will appear to go in fast foward and catch up
> again! This is clearly unacceptable for realtime video! We would
> rather lose the occassional packet then have it get behind.
> 
> QUESTIONS:
> 
> 1) will doing SNAT twice on a UDP video stream cause considerable or
> negligable delay?

Should not be measurable unless the Linux machines are totally 
overloaded. For a reasonably fast machine, 100 MBit/s wirespeed SNAT is 
possible, so you should be fine.

> 2) Is there a way to tell the kernel to drop a packet if its not
> delievered within an acceptable period of time?

You could try to tune the TX timeout, but I have no idea whether there 
is a sysctl for that.

> 3) How can you optimize your TCP stack for realtime video?

TCP stack? I thought you were doing video over UDP. Sending video over 
TCP would indeed explain your problems.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc