<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 16, 2019, at 6:48 PM, Grant Taylor <<a href="mailto:internet-history@gtaylor.tnetconsulting.net" class="">internet-history@gtaylor.tnetconsulting.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 2/16/19 7:16 PM, Joe Touch wrote:<br class=""><blockquote type="cite" class="">Message transfer latency (the only one that matters, IMO), is a <br class="">combination of:<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- generation latency<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- propagation latency<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- computational latency<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- aggregation latency<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- multiplexing latency<br class=""><br class="">(I recently gave a tutorial on this at Sigcomm, and it was the focus of <br class="">my thesis 25+ yrs ago)<br class=""></blockquote><br class="">Is there a recording? }:-)<br class=""></div></div></blockquote><div><br class=""></div><div>Sorry - neither one.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">These contribute to the overall latency of different communication <br class="">technologies in various ways. I’m glad that you noticed that such <br class="">latency is *of a message* (of size X), rather than an independent property <br class="">(i.e., just asking “what’s the latency?” cannot be answered).<br class=""></blockquote><br class="">:-)<br class=""><br class=""><blockquote type="cite" class="">It also takes longer than it looks like it should across modems and RF <br class="">links, sometimes because of coding delays (aggregation latency above) <br class="">and channel access latencies.<br class=""></blockquote><br class="">Agreed.<br class=""><br class="">Assuming that some of the coding delays are related to serial data going <br class="">into a buffer but not filling it, so the modem times out and sends a <br class="">partial buffer. I wonder if different designs with different buffering <br class="">or some sort of push / flush signal might help things. But that's more <br class="">complexity which drives price up.<br class=""></div></div></blockquote><div><br class=""></div><div>That sort of timeout isn’t as much the issue as the block coding that helps reduce the impact of burst errors. It’s the size of the block that often drives large delays in modems, even if they don’t “wait” to be filled up with data (I am not aware that they do or would - the blocks go out on schedule, filled or not).</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class="">FWIW, propagation delay has gone up (from coax LANs @0.8c to twisted <br class="">pair @0.6c) then down (newer twisted pair approaches 0.8c again) and <br class="">fiber is 0.65c. WiFi is very close to 0.99c<br class=""></blockquote><br class="">I think that's signal in medium.</div></div></blockquote><div><br class=""></div><div>Yes.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> If I'm reading your statement <br class="">correctly, the number closer to 1.0c is better.<br class=""></div></div></blockquote><div><br class=""></div><div>Yes.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Is that 0.8c 10Base2 or 10Base5?<br class=""></div></div></blockquote><div><br class=""></div><div>Both are coax - although they vary, they’re both in that range.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">The 0.8c for coax vs 0.6c for twisted pair matches experiences that I <br class="">remember.</div></div></blockquote><div><br class=""></div><div><a href="https://en.wikipedia.org/wiki/Velocity_factor" class="">https://en.wikipedia.org/wiki/Velocity_factor</a></div><div><br class=""></div><div>TP varies - see the Cat 3, 5, 6, and 7 values.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""> Coax seemed slightly faster than twisted pair. </div></div></blockquote><div><br class=""></div><div>Generally, yes. Open-ladder is the fastest for metal.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">People <br class="">thought I was crazy seeing as how both were 10Base<something> and 10 Mbps.</div></div></blockquote><br class=""></div><div>The 10 of 10base<something> **is** the 10 Mbps . Higher rates means shorter bits; shorter bits means the *end* of the message arrives more quickly, not the front of the first bit.</div><div><br class=""></div><div>The shortest Ethernet message (including preamble and SOF) totals 54 bytes, i.e., a transmission delay of 43.2 microseconds at 10 Mbps. The propagation delay, even in a 1500ft cable (the longest possible), is 1.875 microseconds (at 0.8c). In twisted pair the propagation delay is 2.5 microseconds. The difference would be only 0.625 microseconds - or about 1.4% of the transmission delay, not to mention other system delays.</div><div><br class=""></div><div>That would show up on a scope, but I doubt it would have been noticeable within an operating system, e.g., due to scheduler granularity, etc.</div><div><br class=""></div><div>Joe</div></body></html>