Determining avaliable bandwidth with _datagrams only_ - Networking

This is a discussion on Determining avaliable bandwidth with _datagrams only_ - Networking ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Determining avaliable bandwidth with _datagrams only_

  1. 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: hexarith@jabber.org, ICQ: 134682867


  2. Re: Determining avaliable bandwidth with _datagrams only_

    "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


  3. Re: Determining avaliable bandwidth with _datagrams only_

    On Sun, 12 Aug 2007 16:47:21 +0200 Wolfgang Draxinger 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-1146@ipal.net |
    |------------------------------------/-------------------------------------|

+ Reply to Thread