Stopwatch Bandwidth

The 1’s and 0’s of data fly through the air on our WiFi as the presence and absence of pings from our wireless hubs and devices. A message ‘1001101’ would need four of these pings, one for each ‘1’ in the data. Sending every ‘1’ makes our bandwidth cluttered. When our bandwidth is cluttered, each signal needs to be stronger, to shout over all the others. This crimps battery life, and WiFi range. We have an alternative: the stopwatch.

“Huh?”

A stopwatch, in contrast, lets you send as much data as you want with only two pings. Here is how: when I want to send you a message, I ping once, and start my stopwatch. When you hear that ping, you start your stopwatch, also. As soon as my stopwatch displays the time (in binary) that matches my data, I send the second ping. You stop your stopwatch when you receive that ping, and your stopwatch has the entire message on it, represented by the time elapsed. You got the message, by reading your stopwatch!

For example: I want to send the message (in binary) ‘1001101’. I send a ping, and the stopwatch begins counting, ‘0’, ‘1’, ‘10’, ‘11’, … eventually reaching ‘1001101’ after 77 (micro)seconds. When that count is on my stopwatch, I send the second ping, telling you to stop your stopwatch. Your stopwatch, counting the same increments, would read the same time: ‘1001101’. Instead of sending four pings, for each ‘1’, I’ve only sent two… albeit, in a longer stretch of time (77 microseconds, instead of 8 microseconds). This means that the network is not as noisy, both because of fewer pings, and because of a longer time between pings.

“Then bandwidth is slowed, waiting for your stopwatch, right?”

Not necessarily! If we only have one frequency that we share, true, we must wait longer for our messages. However, if our devices can listen to a few different frequencies, then we can dramatically increase bandwidth with another neat trick: frequency signatures.

Suppose our devices can listen to different frequencies called ‘A’, ‘B’, ‘C’, and ‘D’ — these would be slightly different wavelengths of radio signal, in our WiFi example, but they can also be different frequencies of visible light in a fiber optic channel, as well. Normally, to avoid cluttering the bandwidth (and confusing other peoples’ devices), you would send and receive data along only one of those frequencies, and someone else would need to use a different frequency for their communications. That’s why each radio broadcast has its own station, tuned to its own frequency. With our four example frequencies, we could have four radio broadcasts.

However, we could also organize our devices so that each device only listens to pings that occur on a subset of those frequencies. One device broadcasts on frequencies A and B, another transmits using A and C, another uses A and D… Together, this set of combinations is larger than our original four channels. (AB, AC, AD, BC, BD, CD gives six different channels!) Those frequency-pairs are signatures, and our devices listen only for the signature that matches, while ignoring pings that are only on one or the other frequency.

When you have more frequencies to choose from, the number of combinations grows rapidly: four frequencies becomes six pairs, but ten frequencies becomes forty-five pairs. What’s more, when you have many frequencies, you can use a larger subset: ten frequencies, split into five-frequency subsets, gives 252 subsets! So, our devices might be talking to each other, and only listening when they hear a ping across the five frequencies ‘ACEGI’, while another pair of devices only listen when they hear the five frequencies ‘BDFHJ’. While you previously could only have ten separate conversations, you can now have 252 separate conversations, with each device only listening to the conversation tuned to it’s subset.

“Why couldn’t you just use that combination-trick with existing data-transmission? Why would you need to pair it with the stopwatch-trick?”

If everyone sent a ping for every ‘1’ that appeared in their data, a transmission using these subsets would be even noisier — you are transmitting all the same bits, but along multiple frequencies simultaneously. For the example message ‘1001101’, a five-frequency subset would be sending four pings (for each of the 1’s in your message) over all five frequencies, which would be twenty pings in total. Wasteful!

By relying upon the stopwatch-trick, even a very long message would only send two pings along those five frequencies, for a total of ten pings. As a result, a message with more than ten 1’s would require less energy to transmit!

“That very long message would take a very long time for your stopwatch, right?”

Yes, and that’s okay: your device can send a packet of information along one signature, and another packet of information along another signature. Because there are many signatures to choose from, your device sends all packets simultaneously. Each packet might take 100,000 microseconds to transmit by stopwatch, but the entire file still arrives in 1/10th of a second. Another concrete example: a binary message that is 16 bits long, using a microsecond stopwatch, would take about .065 seconds to transmit. If you have 252 signatures to choose from, you could send over a hundred of these messages concurrently, for a file that is >1,600 bits. (In reality, data is sent at intervals much faster than a microsecond, so you could send larger packets over a real WiFi network.)

Key to this concept: while the stopwatch slows down the bit-rate for each packet of data, it also frees the bandwidth to transmit over many more signatures, sending many more packets at the same time. Stopwatches would slow each packet exponentially, in fact. But, the number of signatures available grows combinatorially, which is faster than the exponential slowdown! On balance, a file sent using many signatures for many ‘stopwatched’ packets can be received a little bit faster than a file sent as one long string of 1’s and 0’s. Thankfully, a modest increase in speed is NOT the only benefit of these two tricks!

Noise:

When your wireless connection misses some of its data, that data is corrupted, and the network has to send the whole message again. And, when many people are using the same network, it becomes very likely that your message became garbled alongside someone else’s message. That’s why your cell phone won’t download apps at a concert. Everyone’s device is talking at once, which causes their messages to fail. Because the transmissions were corrupted, every device talks again, trying to get their message right — and no one gets to talk. The effect is similar to a traffic jam: if everyone’s car is slowed even a little, that means you all spend more time on the road. If everyone is spending more time on the road, then traffic gets worse!

By using a stopwatch and frequency signature, you avoid the traffic jam of noise. There is only a minuscule chance that other peoples’ signatures will ping at the same time as your stopwatch, and the chance that their signatures will completely overlap yours is almost zero. Some fancy-looking equations demonstrate this, but if you have the background to understand them, then I’m sure you can check for yourself. [:

Identity:

This part is really cool. When your laptop tries to talk to a WiFi hub, it has to signal its identity… with every single message. Essentially, there is a load of identification data that must be sent, along with your message: “Hi, this is Jill’s laptop, and I’m trying to send a message to GroundDownCoffee’s wireless… my message is…” These identifiers are a large part of the data that’s passed back and forth. With frequency signatures, that data is no longer expressed by extra 1’s and 0’s — it’s expressed by the combination of frequencies your device uses!

So, your laptop would select a set of frequencies, and agree upon those frequencies with the WiFi hub — just once. Then, any messages it sends are automatically seen by that hub, and visa versa, without padding the data with extraneous bits. That lets the network transmit even more data per second, and allows it to handle many more users simultaneously.

This becomes more interesting when we look at massive asynchronous servers. With a stopwatch and frequency signature, two nodes of a giant network can talk to only each other, without including routing data. If that doesn’t sound like a big deal, consider: in an array of 1,000+ cores (each its own little processor), you normally must send a message UP to a governing and routing hub, which reads the address you came from and the address you’re sending to, and then re-directs the message back DOWN to the appropriate core. When a lot is happening, that UP/DOWN routing becomes a bottleneck (and a pain in the neck, too). Signatures, meanwhile, can be chosen for each core-to-core dialogue; when one core wants to talk to another core, it transmits along their shared signature. Everyone else diligently ignores that message. Done.

Party Lines and Functional Routing:

Massive asynchronous servers can make full use of these tricks, by allowing party lines and functional lines. By ‘party line’, I don’t mean the screed of a particular political group — I am referring to the old telephone option for multiple callers on the same call. If a dozen cores are all working together on a certain task, they can share a frequency signature, to stay updated on each others’ progress. No need to disturb the governor! And, cores in a massive array can also have dedicated functions that they serve: “Every time I hear data along the signature ‘ACDFG’, I know that they are asking me to multiply the first half of that data by the second half, and I should send the answer back along the response-signature…” By eliminating the bits used to route that data between cores, messages can travel at much higher bit-rates, and more of the chip can be invested in real computing power, instead of routing.

So, do fewer dropped packets, lower noise, lower power requirements, elimination of routing data & extraneous chip-space all sound like good things? Just ping me at ‘ACDFJ’ — I’ve already started my stopwatch.