anchor.diff:  
   A common way to benchmark networks is to setup two computers and have a sender transmit a message to a receiver that echoes it back. That way the sender can measure the round trip time and gather statistics of the network. This generally works well, but large operating system stacks and device drivers can potentially add a lot of variation. In an attempt to reduce unwanted jitter, I decided to setup a benchmark using two embedded devices instead.
   
  -As the sender and receiver devices I chose two HEBI Robotics I/O Boards. It's a product that we typically don't advertise, but customers often use it to integrate actuators with external devices or to get various sensor input into MATLAB. It has 48 pins that serve a variety of functions (analog/digitial I/O, PWM, Encoder input, etc.) that can be accessed remotely via network. It contains a 168MHz ARM microcontroller (STM32f407) and a 100 Mbit network port.
  +As the sender and receiver devices I chose two HEBI Robotics I/O Boards.  We use it in conjunction with our actuators to interface with external devices, such as a gripper or pneumatic valve, or to get various sensor input into MATLAB. It has 48 pins that serve a variety of functions (analog/digitial I/O, PWM, Encoder input, etc.) that can be accessed remotely via network. It contains a 168MHz ARM microcontroller (STM32f407) and a 100 Mbit network port.
   
   [.text-center]
   .HEBI Robotics IO Board
   image::udp/io-board.jpg[link="../images/udp/io-board.jpg"]
   
  -[NOTE]
  -TODO: Replace with 'whitewashed' product picture?
   
   In order to isolate the network stack I wrote and programmed custom firmware based on http://www.chibios.org/[ChibiOS 2.6.8] and http://savannah.nongnu.org/projects/lwip/[lwIP 1.4.1]. The relevant code pieces can be found https://gist.github.com/ennerf/36a57d432bcff20a58efcdee10f91bd9[here]. The elapsed time was measured using a hardware counter with a resolution of 250ns. Since there was no way to store multiple Gigabytes of data on the devices, I needed a different solution for data logging.
   
  
positive.code: So far I have not been successful in determining the root cause of these modes. All three modes seem to be related to actual time and independent of rate and packet count. However, after several tests, I strongly suspect that all of them occur on the firmware side rather than being tied to the switch or the protocol itself. Below is a zoomed in view of a 10 minute time span that better shows Modes 1 and 2.
  
  [.text-center]
  .Round Trip Time for 200 byte payload (10min)
  image::udp/rtt-baseline-zoomed.png[link="../images/udp/rtt-baseline-zoomed.png"]
  
  Overall this initial data looks very promising for being able to use UDP for many real-time control tasks. With more tuning and a better implementation (e.g. lwip with zero copy and tuned options) it seems likely that the maximum jitter could go down to below 6us and potentially even 1us.
  
negative.code: | image:udp/io-boards-100mbit-switch.jpg[link="../images/udp/io-boards-100mbit-switch.jpg"] | image:udp/io-boards-gbit-switch.jpg[link="../images/udp/io-boards-gbit-switch.jpg"]
  |====
  
  
  
  [.text-center]
  .Comparison of round trip time through different switches (35min)
  