Yup. Pretty much any CAN performance testing can be thrown completely out the window for 2020. The entire CAN subsystem has changed, which is going to change how the vendors write their CAN code as well. So things done in the past to not lag out user code are not necessary anymore, which means performance rewrites at pretty much all levels.
There’s not really much to elaborate on, but there will be a node.
Basically, all CAN messages sent and received on the rio went through the netcomm daemon in the past. This meant any send or receive went over an IPC pipe. For 2020, CAN has been moved entirely into the robot process, which means the robot process now has direct access to the CAN subsystem. The IPC is what was causing all the direct call latency, and all of the vendors had chosen different ways to make these latencies less visible to users. For 2020 however, none of these workarounds are necessary, as direct calls are not fast enough to not affect user code.
These are reads off of the 2019 image. Best case is about 75us, worst case is about 200us. Also, something interesting to note is how much longer the DIO line is low. That whole time, your robot code is run running, and is instead just waiting for the CAN IPC call to return. That is the reason many of the vendors were handling workarounds, because a single CAN call would take up almost 10% of your robot loop time.
However, it looks like even the latency in 2019 WPILib was much lower than the numbers I observed measuring total latency from DIO set to SPARK output, indicating most of this latency is a problem in REV’s firmware (70+ ms!)
Thanks for the detailed analysis. We’ve been looking at this issue closely and confirmed that it is on the API side, and not at all related to the firmware. Now that the latency for the CAN calls is so much quicker for 2020 as verified by @Thad_House we will be removing our own workaround for the issue.