> The other replies are assuming networking in a big network is inherently slower than in a small network.
well yes, not true with modern switches that support cut-through forwarding
it's super-common in our space to bypass the kernel entirely, writing into the NIC buffers directly with prepared packet headers, and the card has pushed part of the packet out onto the wire, through switches and into the target machine's NIC buffers before it's even finished being written
typical "SLA"s are 0 packets dropped during a session, where a single drop raises an alert that is then investigated
> You will never be able to replicate the performance of Google's network by buying some rackmounted servers from Dell and plumbing them together with Cisco switches.
and yet, somehow we do quite a bit better (admittedly they are very, very expensive switches)
I get that people that work at Google like to think they're working on problems more advanced than those of mere mortals, but with the latencies you've described we'd be out of business several times over
(not to mention none of the clouds support multicast)
That's just different niche. I assume that you work in trading based on the word "multicast".
What Google needs is "Big+Cheaper" datacenters, and it has to work with codes written by 100000 different mere morals. What you described is in the "Small+Expensive" field, but with extreme worst-case performance demand.
"Big+Expensive" = Supercomputer
"Small+Cheaper" = ??? (Note that the Big+Cheaper solutions not necessarily work for this, as you can't amortize and ignore one-time R&D/ops cost anymore)
The other replies are accepting multi-millisecond latencies as a given, and think that Google's network must be slower than even a basic copper-wired LAN because it's bigger.
My response is something like "just because the network's bigger doesn't mean it's slower".
>> You will never be able to replicate the performance of Google's network
>> by buying some rackmounted servers from Dell and plumbing them together
>> with Cisco switches.
>
> and yet, somehow we do quite a bit better (admittedly they are very,
> very expensive switches)
With respect, if you're in the trading business, your network almost certainly contains custom hardware. I bet it looks a lot closer to Google's than it does to the guy plugging cat5e into a Dell.
well yes, not true with modern switches that support cut-through forwarding
it's super-common in our space to bypass the kernel entirely, writing into the NIC buffers directly with prepared packet headers, and the card has pushed part of the packet out onto the wire, through switches and into the target machine's NIC buffers before it's even finished being written
typical "SLA"s are 0 packets dropped during a session, where a single drop raises an alert that is then investigated
> You will never be able to replicate the performance of Google's network by buying some rackmounted servers from Dell and plumbing them together with Cisco switches.
and yet, somehow we do quite a bit better (admittedly they are very, very expensive switches)
I get that people that work at Google like to think they're working on problems more advanced than those of mere mortals, but with the latencies you've described we'd be out of business several times over
(not to mention none of the clouds support multicast)