anchor.diff:  .Baseline setup on embedded device vs Linux computer (10min)
   image::udp/rtt-linux-1x-comparison-10m.png[link="../images/udp/rtt-linux-1x-comparison-10m.png"]
   
  -I realize that there is a lot that isn't covered by this blog post, so I'm considering doing another one in the future that looks at different network interfaces and potential ways to reduce latency. There may also be blog posts on clock drift and clock synchronization using IEEE 1588v2, as well the performance impact of sending uncontrolled traffic (e.g. streaming video) through the same network.
  -
  -
  +We realize that there is a lot that isn't covered by this blog post, so we're considering doing another one in the future that looks at different network interfaces and potential ways to reduce latency. There may also be blog posts on clock drift and clock synchronization using IEEE 1588v2, as well the performance impact of sending uncontrolled traffic (e.g. streaming video) through the same network.
  +
  +
  
positive.code: In order to test the actual behavior we put together a test setup consisting of 40 HEBI Robotics I/O boards that are connected to a  http://www.downloads.netgear.com/files/GDC/GS748Tv1/GS748T_ds_03Feb05.pdf[GS748T] 48-port Ethernet switch. Each board runs the 'receiver' firmware. Sending a single broadcast message to all receiver devices triggers 40x266 byte (>10KB total) return packets that can arrive at the switch within less than 250 nanoseconds. This https://en.wikipedia.org/wiki/Micro-bursting_(networking)[Microburst] traffic pattern is representative of a high degree of freedom system such as a full body humanoid robot without doing any daisy-chaining.
  
  [.text-center]
  .Network test setup with 40 HEBI Robotics IO Boards
  image::udp/multiple-boards.jpg[link="../images/udp/multiple-boards.jpg"]
  
  [NOTE]
  
negative.code: 
  In a process that started in https://en.wikipedia.org/wiki/Kalpana_(company)[1990], Hubs have been fully replaced with https://en.wikipedia.org/wiki/Network_switch[Switches]. They have dedicated full-duplex (separate lines for transmitting and receiving data) connections for each port in order to separate segments and isolate collision domains, which gets rid of any collisions that were happening on the physical (wire) level. CSMA/CD is still supported for backwards compatibility and half-duplex connections, but it is largely obsolete.
  
  Using dedicated lines introduces additional 'switching' overhead for forwarding Frames to intended receivers. As of 2016, virtually all Switches implement the https://en.wikipedia.org/wiki/Store_and_forward[Store-and-Forward] switching architecture in which Switches fully receive packets, store them in an internal buffer, and then forward them 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.
  
  In the alternative https://en.wikipedia.org/wiki/Cut-through_switching[Cut-through] approach Switches can forward packets immediately after receiving the target address, potentially resulting in lower latency. While this is sometimes used in latency sensitive applications, such as financial trading applications, it generally can't be found in consumer grade hardware. It is more difficult to implement, only works well if both ports negotiate the same speed, and requires the receiving port to be idle. There is also the requirement to buffer enough data to evaluate the target address, so the benefits primarily effect larger packets.
  
  // Ethercat has solved this in a somewhat elegant way by not using device addresses and by limiting each wire to a single writer. 
  
  