Since the OP compared Internet latencies to the speed of light in glass...look up 802.1CM/IEEE1904.3 or "CPRI over Ethernet"/"Radio over Ethernet"! Those descri

Since the OP compared Internet latencies to the speed of light in glass...look up 802.1CM/IEEE1904.3 or "CPRI over Ethernet"/"Radio over Ethernet"! Those describe techniques for conveying LTE baseband signals (digital I/Q-samples) over Ethernet -- so the radios can live far away from the equipment that speaks the physical / MAC / radio-resource-control layers of LTE. There are strict latency/jitter requirements involved (the phone and the eNB run a very fast automatic-repeat-request protocol between each other, too much latency breaks the loop) -- and large (but predictable) data rates involved. Read https://drive.google.com/file/d/0B6Xurc4m_PVsZ1lzWWoxS0pTNVE/view https://drive.google.com/file/d/0B6Xurc4m_PVsZ1lzWWoxS0pTNVE... for a general introduction about latency in Ethernet/IP networks and http://www.ieee802.org/1/files/public/docs2016/cm-chen-fronthaul-bandwidth-analysis-0716-v01.pdf http://www.ieee802.org/1/files/public/docs2016/cm-chen-front... for an introduction to the "radio over ethernet business" Even if you're not trying to send radio baseband data over ethernet networks -- there's lots of noticeable queuing going on, everywhere. It's not just the unmanaged and pathological "bufferbloat" queues (that occur when a device has a network link much faster than its other network link) -- there's little queues that are used for tasks like: * frame aggregation * holding onto data until a shared medium is idle * for scheduled systems like DOCSIS or LTE, holding onto packets until an uplink grant has been given -- or holding onto packets until a station's downlink grant/timeslot becomes active * inter-device communication (usually with ring buffers or the like) * any processing/forwarding that isn't of the cut-through flavour usually involves queuing at least a single frame * context switching / memory copying / interrupts Retransmission mechanisms can introduce latency as well -- if there's no special channel for acknowledgements, they'll use up airtime, and if data needs to be retransmitted, it might induce delays for never-transmitted data that's waiting for its first transmit opportunity. In general, unless you're actively being paid to stomp out every imaginable source of latency, there'll be little queues living everywhere in your system -- from TCP's queues right on down to the CPU's store buffers-- because queuing is the natural way to cope with subsystems that produce/consume at different rates.