Determining avaliable bandwidth with _datagrams only_

I'm currently developing the software for a ROV (remotely
operated vehicle), which has a bunch of sensors and other stuff
on board, everything controlled by a Linux (of course) computer.

By the nature of the project the network connection must be
considered unreliable. Thus the protocols to be used are of
the "fire and forget" nature. If packages arrive it's good, if
they're lost it's noting bad either, as long as some get
through. So datagrams are used (a stream might easyly timeout).

However the avaliable bandwidth may (will?) vary over a wide
range (from a few 10kBit/s up to 5MBit/s), and since there is no
stream connection I don't see an easy way to determine the
actual time a package of given length takes to be transmitted.
There shall also be no ACK datagrams be sent. If the ROV doesn't
recieve control packages within a given time it will simply stop
and wait.

Knowing the actual avaliable bandwidth, remaining after error
correction and stuff, is important, as there are also a few
cameras on board and the amount of compression and framerate
should be dynamically adapted to the avaliavle bandwidth.

Any ideas?

Wolfgang Draxinger
--
E-Mail address works, Jabber: (E-Mail Removed), ICQ: 134682867



Wolfgang Draxinger

"Wolfgang Draxinger" schrieb
>
> [ Re: Determining avaliable bandwidth
> with _datagrams only_ ]
>
If nobody has any idea, I'll throw in some of mine:

- one process regularly transmits the number of bytes
and packets sent. The receiver can determine
what he received and update the sender on how to throttle
bandwidth / chattiness.

- keep at least one TCP communication, observe its
behaviour (on both sides) and update your UDP communication
strategy accordingly.

- read up on how TCP tries to optimize its communication
stuff and try to implement some of it on your platform

FWIW. HTH.
Martin

On Sun, 12 Aug 2007 16:47:21 +0200 Wolfgang Draxinger <(E-Mail Removed)> wrote:

| I'm currently developing the software for a ROV (remotely
| operated vehicle), which has a bunch of sensors and other stuff
| on board, everything controlled by a Linux (of course) computer.
|
| By the nature of the project the network connection must be
| considered unreliable. Thus the protocols to be used are of
| the "fire and forget" nature. If packages arrive it's good, if
| they're lost it's noting bad either, as long as some get
| through. So datagrams are used (a stream might easyly timeout).
|
| However the avaliable bandwidth may (will?) vary over a wide
| range (from a few 10kBit/s up to 5MBit/s), and since there is no
| stream connection I don't see an easy way to determine the
| actual time a package of given length takes to be transmitted.
| There shall also be no ACK datagrams be sent. If the ROV doesn't
| recieve control packages within a given time it will simply stop
| and wait.

That should be a time that is an interval between received packets.
Unless you are hitting the bandwidth so hard as keep it saturated
with datagrams, the bandwidth should not have that much of an effect.


| Knowing the actual avaliable bandwidth, remaining after error
| correction and stuff, is important, as there are also a few
| cameras on board and the amount of compression and framerate
| should be dynamically adapted to the avaliavle bandwidth.

If the bandwidth can change fast, you'll have to handle it dynamically.
Since what is probably importabt is usable bandwidth in terms of how
many datagrams successfully arrive, I suggest simple measures based on
that. Measure what is getting through and keep some short and long
term numbers showing this. It won't show literal bandwidth; it will
show effective bandwidth relative to usage (if you are using it too
lightly, it will "look" relatively higher).

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2007-08-14-(E-Mail Removed) |
|------------------------------------/-------------------------------------|