anchor.diff:  
   // Ethercat has solved this in a somewhat elegant way by not using device addresses and by limiting each wire to a single writer. 
   
  -
   // Depending on the use case this can have positive impacts on latency. However, it still requires enough buffering to evaluate the header address and only works well if both sender and receiver ports negotiate the same speed and the sender port isn't already being used.
   
   // In the common https://en.wikipedia.org/wiki/Store_and_forward[Store-and-Forward] switching architecture all packets get buffered by the Switch and are then forwarded to the appropriate receiver port. This adds a latency cost that scales linearly with the number of switches that a packet has to go through. The alternative https://en.wikipedia.org/wiki/Cut-through_switching[Cut-through] switching approach can forward packets before they are fully received, which can have positive impacts on latency especially with very large packets.
   
  -<TODO: combine these concepts somehow>
  +[NOTE]
  +TODO: improve the flow of this section
   
   //When more than one component try to communicate, there may be a collision that causes packets to be dropped. Modern networks use 'Switches' that have dedicated connections for each port to isolate collision domains. Additionally, connections tend to be full-duplex, so there are dedicated lines for transmitting and receiving data. Depending on the architecture, packets get buffered and sent to the appropriate port (Store-and-Forward) or directly passed through without evaluation (Cut-Through). Thus, switched networks should never have any packets that get dropped due to collisions. Note that packets can still be lost due to buffer overflows and/or too much load on a system. There is also a latency cost associated with each 'hop' (or buffer) that a packet has to go through.
   
   // re-read
   // http://www.cisco.com/c/en/us/products/collateral/switches/nexus-5020-switch/white_paper_c11-465436.html
   // https://www.lantronix.com/resources/networking-tutorials/network-switching-tutorial/
  +// http://www.embedded.com/design/connectivity/4023291/Real-Time-Ethernet
   
   Similarly, reordering (in the sense that a stream of packets coming from a single source can arrive out of order) may be relevant for internet communications, but generally does not apply to local networks without redundant routes. Depending on the driver implementation it can theoretically happen on a local network, but I have yet to observe a single case.
   
  
positive.code: | Baseline | - | 193.8 us | -
  
  | http://ww1.microchip.com/downloads/en/DeviceDoc/KSZ8863MLL_FLL_RLL_DS.pdf[MICREL KSZ8863] (embedded in X5 actuator)
  | 100 Mbit/s | +43.5 us | 3.4 us
  
  | http://www.downloads.netgear.com/files/GDC/GS105/GS105_datasheet_04Sept03.pdf[NETGEAR ProSAFE GS105]
  | 1 Gbit/s | +51.0 us | 47 us
  
  | https://routerboard.com/RB750Gr2[MikroTik RB750Gr2 (RouterBOARD hEX)]
  | 1 Gbit/s | +7.7 us | 3.7 us
  
  |====
  
  
negative.code: 
  image::udp/rtt-switch-comparison.png[]
  
  Both KSZ8863 and the RB750Gr2 add a constant switching latency of 2.9 us and 3.6 us in addition to the wire time of 40.6 us and 4.06 us respectively to the RTT. The added jitter seems to be negligible at well below 1us.
  
  [width="100%",options="header",cols="3a,1a,1a,1a"]
  |====
  