anchor.diff:  
   There are several competing networking standards that are built on Ethernet and can guarantee enough determinism to be used in industrial automation (https://en.wikipedia.org/wiki/Industrial_Ethernet[Industrial Ethernet]). They achieve this by enforcing tight control over the network layout and by limiting the components that can be connected. However, even cheap consumer grade network equipment can produce very good results if the network is controlled in a similar manner.
   
  + TODO: Add that this insight is not new and that people have been doing this for decades. Find good posts and papers to cite.
  +
  +//  TODO: add that this insight is not new and that people have been doing this in 2001. Link various old posts and papers? Are there good ones?
  +
  +// http://www.embedded.com/design/connectivity/4023291/Real-Time-Ethernet[Joe Kerkes] tried this in 2001 using 10 Mbit Ethernet.
  +
  +// https://www.researchgate.net/publication/4232548_Real-time_performance_measurements_using_UDP_on_Windows_and_Linux[Prytz et al.] did a latency study in 2005. Other potentially useful resources include a list of
  +
  +// http://literature.rockwellautomation.com/idc/groups/literature/documents/wp/enet-wp002_-en-p.pdf[differences between Standard Ethernet and proprietary adaptations].    
  +
  +// http://www.embedded.com/electronics-blogs/cole-bin/4406659/1/Deterministic-networking--from-niches-to-the-mainstream-[Deterministic Networking: from niches to the mainstream? (2013)] 
  +
   == Benchmark Setup
   
   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 https://en.wikipedia.org/wiki/Round-trip_delay_time[round-trip time (RTT)] 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, we decided to setup a benchmark using two embedded devices instead.
  
positive.code: 
  The step by step flow is as follows:
  
  1. Sender wakes up in fixed intervals
  2. Sender measures time ("transmit timestamp") and sends packet to receiver 
  3. Receiver echoes packet back to sender
  4. Sender receives packet and measures time ("receive timestamp")
  
negative.code: .UDP / IPv4 / Ethernet II Frame Structure
  image::udp/ethernet-ip-udp-header.png[link="../images/udp/ethernet-ip-udp-header.png"]
  
  Although this overhead may seem high for traditional automation applications with small payloads (<10 bytes), it quickly amortizes when communicating with smarter devices. For example, each one of our http://hebirobotics.com/products/[X-Series] actuators contains more than 40 sensors (position, velocity, torque, 3-axis gyroscope, 3-axis accelerometer, several temperature sensors, etc.) that get combined into a single packet that uses between 185 and 215 bytes payload. Typical feedback packets from an I/O Board are even larger and require about 300 bytes. When comparing overhead it is also important to consider the available bandwidth, i.e., sending 100 bytes over Gigabit Ethernet (even over 100 Mbit/s) tends to be faster than sending a single byte using traditional non-Ethernet based alternatives such as RS485 or CAN Bus.
  
  For these benchmarks we chose to measure the round-trip time for a payload of 200 bytes. After including all overhead, the actual size on the wire is 266 bytes. The theoretical time it takes to transfer 266 bytes over 100 Mbit/s and 1Gbit/s Ethernet is 20.3us and 2.03us respectively.
  
  