AFAIK, USB2CAN has the lowest latency: Klipper: communication bus tests
But there is no such thing as the shortest time. Klippy works in the future and schedules commands to the MCU, in the future.
The shortest time what you probably would get:
MCU sends a command to the host: the thread for that MCU gets the command and does some work.
An example is how the ADC + PWM is done. But PWM is scheduled +300ms ahead, you probably could get as low as 100ms in a tight environment.
So, basically, TTC happens, when you schedule cmd too close to the actual MCU time.
So, they are arrived in the past.
This is why, you mostly can’t get away from the time schedule +Nms offset.
IIRC, Reactor uses the host MONOTONIC_RAW for internal scheduling.
And the schedule cmds to the MCU according to the MCU’s expected clock speed.
So the real question is, what sort of accuracy do you want?
With all the scheduling, it should be possible to sync events at sub-millisecond accuracy between MCUs.
On one MCU, all time-critical things are done one by one.
Like, steps for 2-steppers (XY) are interleaved. So, you see them spinning “simultaneously”.
So, those would really depends on what sort of things do you do.
More powerful MCU, just can do more things per time slice. That is it.
Hope that helps.
Ah, yes, if you really want “tight” timings across the board, you probably want to have all MCUs running from the same clock source (and SBC).
I suspect this is a tightest time setup that you could get.