[j-nsp] Qfabric

[Saku Ytti]

On (2011-02-24 14:59 -0600), Richard A Steenbergen wrote:

> latency in and of itself, just that you are "better than the other guy" 
> so you can out-trade him). When it comes to microseconds of latency in 
> the forwarding plane of a switch/router, I'm far less convinced that 
> this is a real issue.

I've also argued about this, while I have no experience in high frequency
trading networks. So it would be nice to hear from someone more experience
how they capitalize on the low latency switches in high frequency trading.

It takes light about 5ns to travel 1m in fibre. Your average router MX80 is
about 8000ns latency, low latency switch is under 1000ns.
So we're talking for non low-latency run of the mill router introducing
latency matching 1.6km of fibre and low-latency switch introducing 250m
worth of latency.

Now where is this information going? How near physically is the end
consumer of the information in high frequency trading?

What about the final application making trading decision? This is my own high
frequency trading software, it is highly optimized:

[ytti at compasssion ~]% cat >> moi.c
int main(void) {
  return 0;
}
[ytti at compasssion ~]% gcc -o moi moi.c
[ytti at compasssion ~]% time ./moi
./moi  0.00s user 0.00s system 0% cpu 0.001 total
[ytti at compasssion ~]% time ./moi
./moi  0.00s user 0.00s system 0% cpu 0.002 total

I'm running it on 560M at 2.67GHz.

I have jitter of over 1000000ns between trading iterations. I'm guessing that
real-life trading software is slightly more elaborate than this, and thus has
higher jitter.
I wonder how it would be actually possible via this software to experience if
I'm running run of the mill router or if I'm running low latency swicthing? I'm
introducing local jitter orders of magnitude more, masking the performance of
network.
If possible, we can save good dime on testing gear.

-- 
  ++ytti