anchor.diff:  
   == Conclusion
   
  -Even consumer-grade Ethernet networks are actually very deterministic. Re-ordering is not an issue on local networks and unless ports get saturated, there is no packet loss.
  -
  -Almost all of the commonly observed jitter is caused by the operating system and it's device drivers. The chart below compares the Linux system communicating (using unicast) with a single device in the same setup as the baseline test.
  +Even consumer-grade Ethernet networks are actually very deterministic. Re-ordering is not an issue on local networks and unless ports get saturated, there should be no packet loss. Almost all of the commonly observed jitter seems to be caused by the operating system and it's device drivers. The chart below compares the Linux system communicating (using unicast) with a single device in the same setup as the baseline test.
   
   image::udp/rtt-linux-1x.png[]
   
   [NOTE]
  -TODO: fix the plot and extend text.
  -
  -I can't recommend using UDP for controlling extremely dangerous industrial robots, but just about everything else should be fine.
  -
  +TODO: fix the plot and extend text. Maybe add another plot testing 4.x kernel in Ubuntu?
  +
  +I still wouldn't recommend using consumer networking equipment for controlling extremely dangerous industrial robots, but for most robotic applications standard UDP is going to be more than sufficient.
  +
  +I realize that this post still leaves many questions, but it's already a bit too long as it is. I may do another post in the future that looks at additional cases such as differences in operating systems, network cards, and performance degradation when sending uncontrolled traffic (e.g. streaming video) through the same network. There may also be a blog post discussing clock drift and clock synchronization using IEEE 1588v2.
  +
  +
  
positive.code: 
  |====================
  
  All of the benchmarks in this post measure the round-trip time for a UDP datagram with a payload of 200 bytes. After including all overhead, the actual frame size on the wire is 266 bytes. For comparison, the feedback packets of HEBI Robotic's X-Series actuators currently require a payload of 185-215 bytes. Requesting the state of all pins of an I/O board currently requires about 300 bytes.
  
  While this size is representative of our standard use case, the round trip times in practice are slightly faster because the outgoing packets (commands) are usually significantly smaller than response packets (feedback).
  
  The theoretical time to send 266 bytes over the wire is 20.3us over 100 Mbit/s Ethernet and 2.03us over 1 Gbit/s Ethernet.
  
  
negative.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 | 2.9 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.6 us
  
  |====
  
  