Slashdot Mirror

← Back to Stories (view on slashdot.org)

Network Monitoring Appliance Looks Below 1 Microsecond

Posted by ScuttleMonkey on from the bofh-to-heroe-in-no-time-flat dept.

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.'"

5 of 78 comments (clear)

  1. Re:Drop a millisecond by BSAtHome · · Score: 2, Interesting

    However, it might be more effective to make your application more tolerant to latency (and fix your TCP window first).

  2. buffering ......... by khasim · · Score: 2, Interesting

    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.

    A more logical reason would be to reduce the possible traffic issues.

    If I'm sitting on the network with a 100Mb/s connection straight to the server ... that's an entirely different scenario than sitting on the other side of the world hooked in through the Internet.

    First off, the chance of a dropped packet (and delay in re-transmitting) is a magnitude smaller when I'm on the network.

    So looking to shave a micro-second/milli-second off of a packet isn't that important or realistic. Humans do NOT make decisions that fast. You'd do better improving the speed of your code or throwing faster hardware at it.
    1. Re:buffering ......... by mccalli · · Score: 2, Interesting

      So looking to shave a micro-second/milli-second off of a packet isn't that important or realistic. Humans do NOT make decisions that fast. You'd do better improving the speed of your code or throwing faster hardware at it.

      Humans make decisions at a minimum of around 200ms I think - that's from memory, so I expect someone to be along and give the real figure soon. But I'm not speaking about humans, I'm speaking about algorithmic trading in a competitive environment. It truly is that significant to remove certainly a millisecond, and why stop there. Think about clustered pricing engines and similar, all trying to price as fast as possible to both a) capture business and b) avoid arbitrage. There definitely is a market for this level of network analysis. I'm on the code-side myself, so I agree that getting your code right is the most important. Throwing faster hardware at it helps however, depending on design, and in some circumstances you take all the speed you can get no matter which source it comes from.

      Not every financial system needs this level of performance, but there are a significant number that do.
      Cheers,
      Ian

  3. Re:Time for token ring? by morgan_greywolf · · Score: 2, Interesting

    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?


    That's what proper network segmenting is for. The guy that hogs the bandwidth usually has some business need to do so (but not always ;). Anyway, say the CAD guys do large file transfers multiple times a day. Well, you segment them off. That way they can't dominate the switch for that all-important transaction network, which would, of course, have its own segment different from the one where your office clients sit.
    --
    My blog
  4. Re:Time for token ring? by smellotron · · Score: 2, Interesting

    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.

    You're missing where one of the parents commented about cases where speed matters. If you're doing algorithmic trading and you're using software QoS, and your competitor is using physical hardware segmentation, your competitor wins (all other things being equal).