I’ve worked with lots of packet capture tools during my career. Some focused on network troubleshooting, some focused on application usage of the network, but on some level all these products (including Corvil) do the same thing. They look at packets, they run algorithms on the packets, they calculate stats, and so on and so forth. But the thing that I needed most as a network engineer, which I could never get back then, was real real-time.
Now some people when they say real-time they mean human timeframes, 1 second, 2 seconds, and that kind of thing. Seconds are a timeframe that we humans can wrap our heads around. I personally have yelled at many quarterbacks for holding on to the ball for more than 4 seconds before throwing it - waiting around much longer without getting sacked is hard to do.
I spent my networking career dealing with network data collected and averaged on human real-time timeframes. Like this graph here, showing the average transmission rate over 5 minute intervals.
The problem is that those averages will always lie. Those averages mask all the details of what is really happening in network real-time. Think about this analogy - a quick Google search finds that the average annual high temperature for Philadelphia is 65°F – but try using that to pack for your trip here in January and you’ll be shivering in your shorts and shirts. The annual timeframe of that average temperature is too wide for trip planning. It is masking all the important details. It is masking the 90°F days in the summer and 40°F days in the winter. The right timeframe would be days, or more specifically the days you plan to visit. Use the right timeframe and you pack a heavy coat for January trips.
It is no different for managing networks. In technical networking terms real-time isn’t measured in seconds. Even 1 second is a lifetime in terms of what servers can process and what networks can transfer between applications. To understand what is happening on a link I need to see what the network is doing in the timeframe that the network operates at. For most people outside of network engineering the world of microseconds is so foreign that it is hard to wrap your head around why it matters – and what it really looks like – and why it is so important to the application performance on the human real-time that we live in.
I’ll tell you why it matters – because it takes microseconds for network buffers to fill up and empty. If your buffers are full, even for microseconds, packets start disappearing. And if this disappearing act happens on a regular basis a chain reaction begins and you start seeing performance issues in human real-time. That’s why this graph, showing the heaviest amount of traffic flowing in an 8 microsecond timeframe, gives me a much better understanding of whether the traffic bursts are going to overwhelm my capacity (the green line).
If I’d had this view earlier in my career, I would have been a rockstar! I’ll tell you why – because I’d have the answer right in front of me when anyone started complaining about application problems. I would have had a real view into my network’s real-time.
So, how about you? How real is your real-time?