Re: Determining if it is "safe" to send UDP packets

From: gregory_may (None)
Date: 02/07/05 

Date: Mon, 7 Feb 2005 11:48:35 -0800

I am currently developing an application that uses UDP for broadcasting
images. I have parameters that let me "Tune" how long I must wait before
the next packet hits the wire. In my application, a 50 ms delay between
sends has proved to be the best compromize between speed & reliability.

In my testing, going below this threashold actually can blow up the network
driver on the receiving machine!

So, you might try just to add a basic delay to make sure the next paket
doesnt go out too soon.

Good Luck!

g.

"Spiro Trikaliotis" <news-200501@trikaliotis.net> wrote in message
news:slrncvpg5a.8uh.news-200501@news.trikaliotis.net...
> Hello Roger,
>
> thank you for your answer.
>
> Roger Levy <rhl@i3e.org> wrote:
>
>> I could be glib and say the answer is TCP but I assume you have good
>> reasons for using UDP.
>
> Yes, we have. We want to transfer images obtained from a camera as fast
> as possible over a wireless link. The protocol used is tolerant of
> packet losses, thus, it is not a big problem if the one or the other
> packet does not get received.
>
> Every image is packed. Unfortunately, the packed images appear almost
> all at the same time. That's the reason why we have to send them out in
> bursts.
>
> As we are sending on a (direct) wireless link (but assuming we are the
> only one sending anything), we do not need to take into account any
> potential problem like congestion, routers that add processing delay, or
> the like.
>
> For testing purposes, we tried to connect two machines via fast
> ethernet, utilizing a cross-connect cable. Thus, we are sure that it is
> the sender's OS that is throwing the UDP packets away.
>
>> I think a possible answer to determining when it is "safe" to send is
>> to automate the process that you have described as a "training"
>> process that takes place before sending important data. Training is
>> essentially what modems do to determine the highest reliable data
>> rate. Training would require you to define a message protocol that
>> enables the destination machine to detect when training is is being
>> executed and how to respond to it. The complexity of such a scheme
>> would probably lead me back to TCP.
>
> As real-time is a major issue, TCP or a similar approach is obviously
> out of scope. Furthermore, as I told before, we do not need each and
> every packets. Anyway, getting only the first 10%, and nothing
> aftermore, is *not* enough for us.
>
> It is very interesting to see the scheme of the packet losses if you
> just send out a burst: The first x% of packets are all send. Then, the
> next 100%-x% are not send, they are almost all completely lost. After
> this, again x% are send, and so on. It really looks like a full buffer
> on the sender's site.
>
>
> Another problem with TCP is its assumption that a lost packet is due to
> a congestion (which is not true in our case, as we do not have
> congestions), but lost packets are rather frequent on the wireless link.
>
>
>> Another approach is to make your UDP path more reliable but you
>> haven't given enough network topology for anyone to tell you where to
>> start.
>
> Well, we have A, and we have B, connected directly via the wireless
> link. It cannot be more simple, can it? ;-) BTW: We need a datarate of
> not more then 150 KB/s on the wireless link - a data rate which it can
> surely handle. Furthermore, our protocol is not allowed to perform any
> handshaking. The receiver is fast enough (this is know before-hand).
>
>
>> Recently I shifted to Linux for this problem because I felt there was
>> more tunability available.
>
> BTW: We have exactly the same problem with Linux. ;-) Only our own
> drivers in RT-Linux give us full control, and there, it works.
>
>
>> My belief is that you are tackling a problem that is ripe for
>> optimization but you need to understand that the potential for errors
>> or lost data will always exist with UDP.
>
> Yes, we are fully aware that the potential for errors or lost data is
> always there with UDP. In fact, that's exactly what we want. ;-)
>
> Anyway, we do not want the kernel to "unnecessarily" throw away some
> packets on its own. At least, we want to be informed of this process, so
> we can react.
>
> Thank you for your input,
> Spiro.
>
> --
> Spiro R. Trikaliotis
> http://www.trikaliotis.net/

Relevant Pages

  • Re: Determining if it is "safe" to send UDP packets
    ... for receiving Udp data. ... I'm receiving from a camera lines of data at 55 Hz. ... the next packet hits the wire. ... Another problem with TCP is its assumption that a lost packet is due to ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Determining if it is "safe" to send UDP packets
    ... >>reasons for using UDP. ... We want to transfer images obtained from a camera as fast ... > packet does not get received. ... I don't know if it will help in your UDP case, ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Sockets best for real-time?
    ... The disadvantage of UDP is that there's no guarantee that a packet ... Where UDP and TCP differ is their approach to packet loss: ... data delivery by retransmitting lost packets, ...
    (borland.public.delphi.non-technical)
  • Re: Incoherent E-mails
    ... The Novell crap was originally run on IPX ... The term in the early-mid nineties was "packet storm". ... The original advantage of UDP was ... > 60 bytes for TCP. ...
    (alt.computer.security)
  • Re: Linux equivalent for ioctlsocket(FIONREAD) on datagram sockets
    ... blocking and non-blocking UDP sends are essentially the same. ... UDP is defined us unreliable. ... achieves packet error rate of ~1E-7 but hits the wall when we try to ... shouldn't want:(to receive UDP datagrams at low error rate. ...
    (comp.os.linux.development.apps)