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.'"
I guess that would depend upon where both points are. One has to be on your network. The other
Now, with Ethernet, one machine can hog the switch (I'll guess that they aren't using hubs). What use is shaving a millisecond off the app if you're still vulnerable to someone else hogging the network at the moment that you're trying to complete your transaction?
Or you work for a shitty company (ie: small, unimportant, does nothing) that can't get demo units from other companies.
Electrical impulses propogate much, _much_ slower than the speed of light when run through copper (and perhaps fiber optics since the light beam has to bounce around so much that the path is many times longer?), so your hard limit may be ~143 ms, but only if your signal went through vacuum all the way to the server and back.
The real latency should be actually much higher due to switching or forwarding overhead and any monitoring that the NSA does. 300ms at least.
Hey Khasim. Can I say, I have to disagree. Analysing latency on large networks is incredibly important. There are often so many latency-inducing mechanisms between a packet leaving an application and arriving at the other end (misconfigured stacks, poor cabling, misconfigured routers and switches (#1 cause!), greedy applications, messy applications, multicast floods etc etc), that it is impossible to tell what the problem is. Modern networks are straining with latency problems that added bandwidth doesn't always solve. The problem is that if you have a large number of servers and clients and there's a problem - which codebase or hardware do you upgrade? You can't tell, because you don't know who's causing the problem. Only by analysing the network can you tell. As a developer, I use wireshark for this often to find out what the trouble is - asking other coders doesn't help - only when I look at the network I can pinpoint the problem - if you fail to configure your video service properly, a group of managers having a v-conference can blot out your network. But you won't know its happening because its off in building #5 somewhere - nowhere near your main servers.