Slashdot Mirror
Network Monitoring Appliance Looks Below 1 Microsecond
eweekhickins writes "Corvil has unveiled a new tool to help network managers cope with increasing pressure to improve performance. This appliance, from the Dublin-based company (with backing from Cisco), passively monitors traffic across networks in segments below 1 microsecond in length and correlates monitoring data with remote appliances and gives a complete picture of latency, jitter, packet loss and other phenomena that affect network and application performance. Corvil CEO Donal Byrne noted that 'If you can drop a millisecond [of latency] off, you're a hero.'"
No offense guys, but unless you can make something that cuts the ping time in half, we won't be having any good FPS games against the Americans without increasing the ping from 60ms to 250ms or higher. 249ms won't cut it. It just won't.
Some applications are natively sensitive to latency and jitter. Consider VOIP or teleconferencing, or algorithmic stock trading.
-molo
Using your sig line to advertise for friends is lame.
Now I can get those random stock tips in my email in less milliseconds! I will be rich one day, I will!
Milliseconds count. Maybe not to your stock tips, but trust me as someone who has spent about a decade in this kind of environment now - sub-millisecond latencies certainly count in automated trading between investment banks/hedge funds/whatever. To the point where people are prepared to pay fortunes to have their machines located physically closer to an exchange.
For fun, check out arbitrage, and then ponder again why reducing latency might be important in a competitive environment. Think about highly liquid markets, such as spot foreign exchange.
Cheers,
Ian
The RIPE NCC's Special Projects group have been offering sub-microsecond latency/jitter/analytical services to ISPs for years. Their data is invaluable and unique, since it measures latency, jitter and packetloss in a single direction (unlike ICMP Ping, which is a round-trip measurement over an asymmetric path) and goes back at least to 2000. The paper claims accuracy to 0.0006 ms, which was good for the time when the product was designed.
Read about the project here and the paper on TTM [pdf] that was presented at the PAM2001 conference.
(This isn't what Corvil do.)
The benefit depends on the person using it. Take an investment bank and an algorithmic trading system. Most of your money is made on volume, the faster you reply the more deals you get, the more volume you have, the more money you make. I've seen a lot of presentations at investment banks where every 5 milliseconds they shave off is $50+ million/year more money they make. Keep in mind that most of these companies have gotten to the point where they can do round trip for the whole trade transaction in 5 milliseconds or less. So each millisecond is like a 20% improvement.
What is the buffer capacity of the server's NIC?... How long does it take to empty it?... What was the guy just before you doing? Did he fill it?
Sorry, but do you really think people don't do that level of analysis as well as trying to improve the network speed?
My point is that if you're looking at spending money for a 1 millisecond gain, you've already lost sight of the goal.
The goal in this kind of app is low latency - every millisecond counts. There are other goals of course, throughput, guaranteed maximums as well as low minimums...but in this case we were specifically discussing latency.
And that's not even counting a router or everything that can slow down your Internet connection
Internet connection? Who's talking about an internet connection? Dedicated leased lines direct to the exchange, internal transfer between machines...this kind of stuff isn't One Man And His PC sitting at home trying to day-trade. Yes there's variability, but even so engineering it out as much as possible is certainly an aim.
All the levels of analysis you describe, from the algorithm right through to the NIC, are already being done. At some point they will be done better, because of a change in available tools. This appears to be one of those tools.
Cheers,
Ian
"There is an old network saying: Bandwidth problems can be cured with money. Latency problems are harder because the speed of light is fixed - you can't bribe God."
A beam of light takes roughly 1/7 of a second to travel around the world. That means that if you're playing on a server on the other side of the world, your ping will always be at least 143 ms. That's a hard physical limit: the only way to decrease that time would be to drill a hole through the Earth, or move closer.
It seems quite simple. I took the following from the article:
They timestamp the packet at some point in the network and when it arrives at the other side they timestamp it again to work out the trip time. Not really rocket science, but they seem to have come up with ways of measuring time pretty accurately at two different places and keeping the clocks in sync or working around clock drift in their measurements.
The other part of their system is some algorithmic work that correlates packets and tries to work out a profile of the network to allow better tuning of networking parameters or even modifying applications to perform better.
It's all very useful information to have if you're trying to milk the last bit of performace out of your network. It's useful for single customer applications, but I see ISPs using it to really tune the larger pipes between POPs so that things like VoIP work more efficiently even with lots of customers making and receiving calls in the presence of other traffic. It often isn't enough to say "send these types of packets out first", particularly if one user or application is generating a lot of them and other users are not; you can starve other users or applications of data.
I drink to make other people interesting!
Do not assume that the people interested in this level of performance are idiots. There's always the possibility they know more about what they're doing than you do.
doc
>Actually, that is what QOS is for. Segmenting off everyone that wants to do some transfer makes for a fragmented unsummarized network with stretch VLANS all over god and country. Segmenting in little networks is fine...but a disaster in large ones.
All of which just basically proves how shitty collision-based networking is, especially as network size and speeds increase: You have to throw more and more hardware at it, to preserve performance.
The only thing that switching and VLANs do, is attempt to rectify a fundamentally flawed physical network protocol by hiding its fundamental nature (switching) or reducing the size of the collision domain (VLANs).
Because, when you get right down to it - it's still Ethernet, and so, is still basically CSMA/CA, though the switches, VLANs, etc., hide it for the most part.
But, it raises its ugly head, when you start to scale the network, doesn't it? And, as you do, you have to throw more and more hardware at the problem.
Token-based networks avoid that. BTW, Token-based doesn't necessarily mean Token Ring. I know, that's a concept that is difficult for many of you to grasp, because when you hear the word "Token", it's like a bell "ringing", and you salivate in response.
Also, QoS is easier to implement on a token-passing network, by its nature.