Home > Articles > Software Development & Management

  • Print
  • + Share This
From the author of

18.3 Overhead and Scaling

We should calculate the overhead of the algorithm. For example, the bandwidth used by source route bridging increases exponentially with the number of ports per bridge and bridges per LAN. It is usually possible to choose an algorithm with less-dramatic growth, but most algorithms have some limit to the size network they can support. Make reasonable bounds on the limits, and publish them in the specification.

Sometimes there is no reason to scale beyond a certain point. For example, a protocol that was n2 or even exponential might be reasonable if it's known that there would never be more than five nodes participating.

Scaling also applies to the low end; it is also good if the technology makes sense with very few nodes. For example, one of the strengths of Ethernet is that if you have only a few nodes, you don't require an expensive specialized box such as a router.

    Real-World-Protocol

    Post-toast wineglass clicking: This is an n2 protocol. And some of us do not have arms long enough to reach across a banquet table to the people on the other side. Surely someone can invent something more efficient. I'd do it if I could figure out what problem is supposed to be solved by that protocol. My son claims the purpose is to make sure everyone drinks at the same time in case the wine is poisoned. Is that a good thing? And does this protocol accomplish that?

  • + Share This
  • 🔖 Save To Your Account