NordicPlayground / nRF51-ble-bcast-mesh

Other
323 stars 121 forks source link

What is the hop delays and relevant solutions? #192

Open bayou9 opened 6 years ago

bayou9 commented 6 years ago

Hi, I'm wondering, has it been measured how long does it take for the message to pass 11 nodes, i.e. hops 10 times?

Also, the program will do version checking and discard repetitive messages, how effective is it in tackling "redundant" nodes? In other words, let's say node A can pass messages directly to node D, but the message will inevitably be received by node B and C first, the optimum result clearly is to have a little competition going on with B and C each trying to send their message to D first, what I'm trying to ask is, will this cause unnecessary delay? I understand the nature of trickle would prevent the delay (if I heard the message for twice in a given time period, I'll stop sending), but how well does it work out in practice?

Again, the optimum time would be the same as the time needed for A to pass message directly to D as if B and C doesn't exist, or a slightly (<=10ms) delay, I'm just interest in how well it works in reality.

trond-snekvik commented 6 years ago

Excellent question.

There's no doubt that the rebroadcasting nature of the mesh makes for quite a bit of redundant noise. As you point out, there's always a risk that the topology delays the packet by blocking retransmissions from reaching a specific node or by packet collisions, but in general, this doesn't seem to be an issue. As the redundancy counter must reach 3 in a single trickle interval for the TX in that interval to be cancelled, the originator (node A), must be echoed by 3 nodes before it decides not to do its next TX. If the first TX didn't reach node D, the chances are very small that neither one of the 3 echoes didn't reach node D.

Uninterrupted, a mesh device is in RX-mode >99.9% of the time, and even with the topology described above (device A, 3 other devices + target device D), the RX rate is still >90% in our experiments. In our tests, the RX rate really starts going down at around 15 devices on the same USB hub constantly sending max-length packets on their own handles, and 3-4 retransmissions may be required in some cases. Communication doesn't really break down until we go beyond 50 devices in the same location. At that point, the RX success rate (per retransmission) starts dipping below 30%.

Every topology is different, and all I can really offer is statistics on the general case, and make assumptions on specific topologies based on these statistics. For your case, I think the RX success rate is the determining factor. If D doesn't get A's first message, node B and C is most likely going to improve your situation, as they'll be retransmitting A's message before A repeats it again. In this topology, you're likely to have an RX success rate >95% though, so having to fallback on node C and D's retransmissions is quite unlikely.