anchor.diff:  
   [.text-center]
   .Baseline setup using single Switch
  -image::udp/setup-baseline.png[link="../images/udp/setup-baseline.png"]
  +image::udp/setup-baseline.png[link="../images/udp/setup-baseline.png", width="100%"]
   
   We set the frequency to 100Hz and logged data for ~24 hours. We chose this frequency because it is a common control rate for sending high-level trajectories, and because 10ms is a safe deadline in case there are large outliers. During normal operations we typically used rates between 100-200Hz for updating set targets of controllers that get executed on-board each device (e.g. position/velocity/torque), and rates of up to 1KHz when bypassing local controllers and remotely controlling the output (e.g. PWM). The network would technically support even higher rates, but there are usually other limitations that come in at around 1KHz (e.g. OS scheduler and limited sensor polling rates).
   
  
positive.code: 
  [.text-center]
  .Baseline RTT comparing RTOS vs RT-Linux vs Windows (10h)
  image::udp/rtt-linux-1x-comparison-10h.png[link="../images/udp/rtt-linux-1x-comparison-10h.png"]
  
  [.text-center]
  .Zoomed in baseline RTT comparing RTOS vs RT-Linux vs Windows (10min)
  image::udp/rtt-linux-1x-comparison-10m.png[link="../images/udp/rtt-linux-1x-comparison-10m.png"]
  
  We realize that there are many more interesting questions that were beyond the scope of this work. We are currently considering the following networking-related topics for future blog posts:
  
  
negative.code: 
  [.text-center]
  .Zoomed in RTT for 40 devices
  image::udp/rtt-linux-40x-zoomed.png[link="../images/udp/rtt-linux-40x-zoomed.png", width="100%"]
  
  [.text-center]
  .RTT for 40 devices (90 min)
  image::udp/rtt-linux-40x.png[link="../images/udp/rtt-linux-40x.png", width="100%"]
  
  However, the amount of latency and jitter turned out to be worse than we anticipated. We expected most columns to start at around ~180us and end at ~280us. While this was sometimes the case, the majority of columns started above 300 us. After some initial research we suspected that this delay was mostly caused by the Linux https://en.wikipedia.org/wiki/New_API[NAPI] using polling mode rather than interrupts, and by using a low-cost network interface paired with suboptimal device drivers. While we expected the OS and driver stack to introduce additional latency and jitter, we were surprised by the order of magnitude.
  
  