From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carl-Daniel Hailfinger Date: Mon, 28 Nov 2005 19:54:07 +0000 Subject: Re: [LARTC] Wireless links + Realtime video >= Headache! (long queue Message-Id: <438B605F.3030001@gmx.net> List-Id: References: <00c301c5f451$47f89950$c901a8c0@jtwin> In-Reply-To: <00c301c5f451$47f89950$c901a8c0@jtwin> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org 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