RF channel capacity

[malcolmst]

I might be missing this in the documentation, but I just wanted to confirm if the RF channel capacity is 1 Mbps for all worlds, using an epoch length of 1 s. Meaning, if any robot attempts to transmit, in its aggregate transmissions, over 1 Mbit in the 1 s epoch, the remainder of the data will always be dropped?

Thanks!

[peci1]

We're also unsure whether the RF model behaves as documented. In https://github.com/osrf/subt/wiki/API#communications, there is:

There is a maximum data rate allowed among robots communicating over the same network segment (e.g. 54000 kbps).

And that's the only capacity information we have. But even testing with the communications tutorial, I've seen not much more than the 1 Mbps between two robots even when they were standing next to each other, where the packet loss due to distance should be minimal.

[peci1]

Hmm, this would explain it:

https://github.com/osrf/subt/blob/33eedf292fd47ec24c77f0b780aeb768eab934a8/subt_ign/launch/cloudsim_sim.ign#L654-L655

So the 1 Mbps is probably correct. Would it be possible to update the API page to not mislead to capacities higher by an order of magnitude?

[malcolmst]

Exactly, it also seems to be similarly defined here: https://github.com/osrf/subt/blob/741f130daea3dd0d1d33662be86fac0e5cecdc35/subt_ign/launch/cave_circuit.ign#L613-L614

and in some of the worlds (at least for tunnel circuit, maybe not urban and cave).

There's a bit of documentation here about the behavior https://github.com/osrf/subt/blob/2f63e31e4960e49680d09dd66f7cbea8a122fa07/subt-communication/README.md

The communication model is responsible for managing shared channels and, if requests exceed channel capacity, the associated queues. The simplest approach being: drop all packets that exceed channel capacity. The default implementation does this.

And the epoch length is defined here: https://github.com/osrf/subt/blob/2f63e31e4960e49680d09dd66f7cbea8a122fa07/subt-communication/subt_communication_model/src/subt_communication_model.cpp#L43-L44

I guess it looks like these parameters are part of the launch file and comms model code so they probably won't change per world, which was my main question/concern, but some more documentation about this might be helpful.

[malcolmst]

Just had a couple more thoughts on this comms behavior, maybe for any future feature additions.

The current behavior is basically fine since it kind of models a RF transceiver where there is some buffer which fills as you send packets and empties as they are transmitted on the channel. Then, when the buffer is full, packets are dropped. This does make it kind of hard to avoid burst losses though, unless you’re pretty careful not to overfill the buffer (i.e. send too much data in an epoch).

It would be nice to have some sort of feedback on whether the packet will be dropped due to the capacity limit. In its simplest form this could be just a boolean like buffer_full or capacity_limited to inform the sender that the packet won’t be sent. Even nicer might be something like a buffer_level to indicate how full the buffer is relative to its limit and allow the sender to decide what to prioritize.

[knoedler]

Is the bandwidth limit global or per group of robots within RF range? My reading (which could certainly be wrong!) is that it is global. If robot A and robot B are talking on one side of the cave system and robot C and robot D are talking on the other side of the cave system they still share a total of 1Mbit of bandwidth. If that is the case, could the bandwidth limit be bumped up to be closer to the 54Mbit in the documentation? It would be hard for robot A and B to know to limit their bandwidth if robot C and D are using 1Mbit on the opposite side of the cave.

[peci1]

My reading is that the limit is imposed on network "segments". I always thought of a segment as a point-to-point connection.

[malcolmst]

Reading the code again, I think it’s limited both on the sender and receiver. It is based on the rf_interface::radio_state tx_state and rx_state. If any radio tries to transmit (to any destination, in aggregate) over 1Mbps, it will fail to send any more, then out of any packets successfully received (from any source, in aggregate), if a radio receives over 1Mbps, it will fail to receive any more.

So on the receive end at least, the radios would have to be within communication distance.

Also (if this understanding is correct) communications between robot A and B won’t affect C and D, unless it’s a broadcast/multicast message they can receive.

This also means avoiding burst losses is a bit harder than I was thinking before, because they can occur on the receiver too. Receiver would have to either request data from a transmitter with the limit in mind, or somehow give feedback to the transmitter about the bandwidth limit. Or I guess the transmitter can use a bandwidth limit << 1Mbps then everything is happy!