What Does It Mean for a Network to be Functional?
When I talk to people outside the computer field (and many inside) it quickly becomes apparent that most people really only think about networks at a very shallow level - basically “my computer connects through <something> to other computers.” It is only a problem when it goes out entirely, or maybe if a movie starts stuttering. Networks have almost become a utility like electricity or water - we only notice it on the rare occasion it fails. There is nothing wrong with this - we all have areas of society we only shallowly understand; I only have a grade school understanding of how our water system works.,
In most of my time as a computer guy, I never really had to worry about networks aside from the occasional loss of connectivity to an Internet destination. The systems I have worked on have never been sensitive to network conditions, but that all changes once we started building Blink Identity. Before I get into this, I have to introduce two important technical terms, but I promise this post will be light on technical geeky stuff. The first terms is bandwidth, which many are familiar with. Bandwidth is basically a measure of how much information you can push down the “pipe” at a time. You may not have enough bandwidth to stream Netflix in 4K, but you may be able to stream in HD. That’s bandwidth. The second term is latency, and it is less well know. Latency is roughly a measure of how long it takes for anything to respond on a network. When you load a webpage, latency would measure the time before it takes for you to see anything.
Latency and bandwidth are both influenced by a lot of factors, but they are independent measurements as well. For example, satellite Internet has high latency because the signal needs to traverse a 26,000 mile round trip to get to the satellite. But it also has high bandwidth. So a page might take several seconds to load, but load fast when it does. Similarly a server in a local network might be overloaded, and have low latency and low bandwidth.
Most people (outside of gaming) likely won’t notice a bit extra latency when doing normal things - if the page or email takes an extra 1/2 second to start loading, or even a full second it probably won’t ever be noticeable. However, people will notice a drop in bandwidth because pages will load slow, or movies will stutter. The key takeaway is that we treat networks as binary - they are functional (up) or non-functional (down). The reality, as always is a lot messier than that. “Functional” is very specific to a particular type of operation, and is very context dependent.
At Blink identity, we originally planned our motion system to use either an on-premises server, or a high-performance server in the cloud. However, we are much more sensitive to latency than we are to bandwidth. The reason for this is that we have to capture and identify a person walking at full speed past our system. The expensive computer part of this task takes about 1/2 a second (500 ms) (also the time it takes you to blink, which is where we got our name). It doesn’t sound like a lot, but in our world 500 ms is a long time. In that time, a person has already traveled 2 feet! We can’t handle any delay from a network if we want to have an answer in time.
A corporate Internet connection could easily have 100-200 ms latency, which is time we don’t have to spare, so very early we dropped the notion of using the cloud. Furthermore, Internet and corporate networks often vary wildly in performance as more users come online. Our fallback option was to have an on-premises server that wasn’t subject to any constraints of the host network. Our thought was that if the on-premises matcher was on our private WiFi network, which we completely control, then the performance would be predictable. And it mostly was ok until it wasn’t.
It turns out that we were subject to some of the same shallow reasoning I have been describing. We wanted to treat a private WiFi network as the same as a private wired network - namely that we control everything. But WiFi isn’t wired of course - it is a radio broadcasting in a noisy environment. We found that some environments had occasional radio-frequency noise that would occasionally add on as much as a full second of latency on our private networks, and some crowded venue environments were so noisy our WiFi couldn’t even find a channel to use. In many of these environments we were assured the network environment was “great,” but we learned that means there weren’t complaints from regular users. Our requirements were quite a bit different than the typical user - we needed guaranteed performance 100.0% of the time.
WiFi noise from a microwave
WiFi is essentially broken for this task. Even in the best environments it can be subject to random noise from a microwave blocks away, or a drone, baby monitor, bluetooth and many other things. Even if it is good enough 99.9% of the time, that isn’t good enough for us.
As an engineer, when faced with a really difficult problem like this, my first tendency is to try and solve it because engineers love hard problems. However, as an entrepreneur-engineer my new desire is to just make the problem go away entirely, so I don’t have to think about it. If I don’t have to solve a problem, I don’t have to worry about whether my solution is correct. And the more outside variables I can remove, the better.
So that’s what we have done - eliminated the network as a consideration. Our current system has no operational network requirements - everything we do that is time sensitive is handled locally on the sensor itself. Because that communication is all “wires” internal to our system, there is no way the performance can be impacted. No matter how overloaded the venue network is, or whether it is operational at all, we will operate exactly the same. We do still use a network to get new records into the system, but that is very lightweight and has no performance requirements.
As an engineer, it is always satisfying to remove something from your system. Assuming everything still works, it is pretty much guaranteed that removing something (anything) is the right decision because it eliminates a potential failure point and complexity. That’s always worth it.