Network Test Saturday, October 30th

As an AREDN network grows in size and/or complexity, it will eventually encounter a packet storm that would pretty much cripple its traffic-carrying capabilities until the storm fades out, which could be hours.  (The writers of the OLSR mobile routing protocol probably never envisioned it having to handle networks of the size amateurs are creating.)  This is significantly limiting the growth and performance of our networks.

Recently released nightly build 571 provides a substantial amount of resistance to these storms.  As a test of the network's robustness (or not) Saturday October 30th at 9 a.m. local we'll attempt to link as many AREDN networks together as possible.  

We did a 'test test' earlier in the week on the West Coast when the Southern California and Bay area networks were linked.  Node counts got up to a bit over 800 and few reports were received, so we're ready for Saturday!

Test preparation

Prior to Saturday's test, it's recommended that in order to protect your node(s) that you upgrade them to the latest nightly build (599 as of this writing).  This is especially important on nodes that pass data through (as opposed to being an end-point on a network).  

Also prior to Saturday, establish some baseline performance measurements on your network.  Suggestions are:

• Quality of VOIP phone calls
• iperf throughput measurements
• Network response times

During the peak of node count in your area, even if there's no packet storm detected, repeat the tests and report significant differences.  If significant, screenshots may be helpful.

Symptoms of a packet storm will be noticeably lower than normal values of LQ/NLQ and node counts, higher ETX values to remote nodes, and in extreme cases inability to reach all but the closest nodes.

Note - over time the OpenWrt software builds have grown in size.  As a result the AREDN builds, which are based on OpenWrt, grow also.  It's become a bit of a challenge to install current nightly builds in older gear with lesser amounts of RAM and flash (most of the devices in the "no longer recommended for new deployments" category in AREDN's Supported Platform Matrix.)   But if you persist you'll eventually be successful.  Rebooting immediately prior to doing the upgrade is recommended to free up RAM necessary for the it to succeed.

Note # 2.  The older products have slower CPUs and less RAM.  It's possible that during the test as routing tables grow, these older nodes may not be able to keep up with table updates, or they might run out of RAM to store it (or both...).    If you see an older device faltering during the test, consider eventually upgrading it to something newer.

We'll test for 12 hours.  Feel free to unlink prior to the end of your test period if things really go south on your part of the network.  But record findings before unlinking.  If you find things are stable and you don't mind being part of a larger network, feel free to stay linked.