The Reality of Serial Bus Speeds
Serial buses and networks such as Ethernet, CAN, USB, and Firewire are popular.Â Â But you can’t just say “I need to transfer 1Mbps, therefore I can use CAN.”Â You need to understand a bit about the physical layer and your chosen software layers before you can pick a bus that will work.
All serial buses have some protocol overhead, and software layers add even more.
I’ll take a quick look at CAN:
- CAN messages can carry between 8 and 64 bits of data.
- At 1Mbps, the maximum actual throughput is roughly 17543 messages/sec (1 byte data) to 8771 messages/sec (8 byte data) or 140,344 to 561344 bits per second of actual data.
- CAN does have many good features, like extremely fast arbitration (much faster and more predictable than CMSA/CD Ethernet), and producer/consumer messaging.
- So CAN is a good choice for a real time network that isn’t transferring a lot of data.Â It’s even better if many nodes need to consumer data produced by one node (so the data is only sent once, unlike in a master/slave network where the master has to receive the data and then send it out again to each slave node).
- On the other hand, it’s not a good fit for a 1M sample/sec 16-bit ADC; high speed USB 2.0 or 100Mbps/1000Mbps Ethernet would be better choices.
- There’s also a cable length / speed trade off; as the bit rate increases, the maximum cable length (and branch length) decreases.
- The maximum number of messages gives an idea of what kind of update rates you can realistically see.Â For example, a 100 node CAN network could handle a maximum of roughly 175 1-bytes messages or 88 8-byte messages per node per second.Â So a 1 msec update rate for all nodes is impossible, but a 10 msec rate might be achievable.
Ethernet has its own set of considerations.Â Just a few:
- Ethernet has significant protocol overhead, especially for small data sizes.Â (Summation frame systems such as EtherCAT reduce this, but require non-standard hardware).
- If you’re using hubs, you have to take collisions into account.
- If you’re using switches, you have to consider the time the switches add.
- Ethernet and its typical protocols require a lot of resources; if your product uses an underpowered controller, even if it’s physically on 100BaseT, it might only be able to manage 1Mbps or less.
- For long distances, the time traveling between nodes can be significant.
- Higher level protocols such as TCP, ftp, NTFS, etc can add substantial delays and additional overhead along with their added features.
I’m not a USB expert, but I know USB 2.0 can’t deliver actual data at its advertised speed.