Slashdot Mirror
Australian Company Promises Switching Hardware With Sub-130ns Latency
snowdon writes "The race for low-latency in finance and HPC has taken a major turn. A bunch of engineers from Australia have 'thrown away the air conditioning' in a traditional switch, to get a 10G fibre-to-fibre latency of less than 130ns! Way faster than more traditional offerings. This lady (video) would tell you that it's equivalent to just 26m of optical fibre. Does that mean we just lose money faster?"
The trick was not reading TFA.
This is not good news; it promotes a trend in a technological approach to making money in the stock market that should be flat out illegal.
Why? I know what it is, how it works, how it makes money, and I'm not overly concerned. So they make a market, and they make it really fast. Eh.
All I ever hear as a rationalization for dislike of it is "workers of the world unite" and "1% OWS" and "something bad happened to the markets, I don't like witches, so lets hang the witch because she has property I like that we can take from her" and "I hate the rich" and all that sort of stuff. I never hear a good moral or ethical explanation of why doing what you normally do, but really fast, is so wrong.
Another good question, is assuming you "make it illegal" how in the world would you enforce that? What would the reg look like? Like... your connection to the market must be this far away blah blah even if it means making a 1000 KM coil of fiber on the data center floor, or maybe all traders must connect to "the market" over geosync satellite links so the average latency is both long and more or less equal?
Please don't confuse conventional HFT with "Flash trading" which is basically window dressed up insider trading, corrupt as all heck. If you do insider trading and trade your own book etc thats just illegal, but if you do it really fast people like to pretend its just "flash trading" and not wrong.
The easiest way to "get rid of" HFT is to fix decimalization. Back when we traded on eights thats too wide to make money on a HFT strategy, and if we allowed millionth of a penny trading quotes that would narrow bid/ask resulting in too little money generated by HFT. Decimalization seems to be almost the perfect pricing system to result in massive HFT strategies, so if you really hate HFT (and WHY?) then just fix the pricing structure so its not profitable anymore. Rather than playing games with legal enforcement of favored or disfavored behavior, simply make disfavored behavior unprofitable. I suppose the opposite solution of going big would work just as well, fine we'll only trade stocks on dollar values now no fractions of a dollar.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Even if a lot of research has been put into reducing the latencies of switching technology, the vast majority of real-world deployments are nowhere near where they should be. The result is corporations spending millions upgrading their core switching, and then the result is the same or worse than what they had with ordinary gigabit technology.
I've been to more than half a dozen sites recently with new installations of 10 GbE, but with terrible network performance. All too often, I'm seeing latencies as high as 1.3 milliseconds even for servers on the same switch. Read up on bandwidth-delay product too get an idea of why this would severely nerf throughput. The odd thing is that at a number of these sites, older servers with 1 GbE connected to the same switching infrastructure get 100% of wire speed without issues.
I don't know exactly what the root cause is, but I'm starting to suspect that the extra latency is coming from somewhere that network engineers don't usually test, like CPU power management taking an excessively long time to wake up a core to respond to a packet. What I think happens is something like this:
- The fast network delivers a burst of data very quickly.
- The receiver CPU starts to slowly wake up from sleep mode, while the sender is waiting for an ACK packet, because it has finished sending an entire TCP window.
- The sender CPU goes to sleep, because it still has nothing to do.
- The receiver CPU finally gets around to the packet, which it processes quickly and efficiently, sending the ACK back.
- The receiver OS sees that the CPU is "0.1%" busy, has nothing to do now, so it sends it to back to sleep.
- The sender CPU starts to slowly wake up, while the receiver is also asleep, waiting patiently for more data.
- The cycle repeats, with more waiting at every step.
With slightly slower networks or CPUs, the CPUs never get a chance to be idle long enough to enter a sleep state, so everything is always ready for more data. I've seen 3x improvements in iPerf TCP throughput by simply running a busy-loop in a background process!