<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 20, 2020 at 16:14 Bryan Fields <<a href="mailto:Bryan@bryanfields.net">Bryan@bryanfields.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 6/20/20 1:56 PM, Saku Ytti wrote:<br>
> On Sat, 20 Jun 2020 at 20:52, Wayne Bouchard <<a href="mailto:web@typo.org" target="_blank">web@typo.org</a>> wrote:<br>
> <br>
>> And thus far, no one has mentioned switching speed and other<br>
>> electronic overhead such as the transceivers (that's the big one,<br>
>> IIRC.)<br>
> This will be something from tens of meters (low lat swich), to few<br>
> hundred meters (typical pipeline),  to 2km delay (NPU+FAB+NPU) per<br>
> active IP device. If that is a big one, I guess it depends, cross<br>
> atlantic, no, inside rack, maybe.<br>
<br>
I think he might be referring to the newer modulation types (QAM) on long haul<br>
transport.  There's quite a bit of time in uS that the encoding takes into QAM<br>
and adding FEC.  You typically won't see this at the plug-able level between<br>
switches and stuff.<br>
<br>
60ms is nothing really, and I'm happy I don't need to play in the HFT space<br>
anymore.  I do wish my home connection wasn't 60 ms across town as spectrum<br>
wants takes TPA-ATL-DCA-DEN-NY to get to my rack. :-)</blockquote><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">working on that ...... :-) </div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
-- <br>
Bryan Fields<br>
<br>
727-409-1194 - Voice<br>
<a href="http://bryanfields.net" rel="noreferrer" target="_blank">http://bryanfields.net</a><br>
</blockquote></div></div>