What is the cycle speed limitation of a Duet3D setup?

[qurt]

I know this question is a bit vague and also maybe more than just one question... and I am mainly interesting of the future direction.
So I know that it is possible to run Klipper on the Duet Firmware and I know that Klipper seems to be often more Bleeding edge while Duet is more polished 1.

From my instinct and understanding: Klipper is doing all the calculation on the Computer (e.g. the Raspberry Pi).
A) Is this also true for the Duet?
What I tried out is: using a Raspberry Pi 4 and a Raspberry Pi 5 with Duet and run a speed test gcode up to a limit/problem: and starting with a speed of S25000 I run on both units into Hiccups.
(Note: There is a claim that it doesn't matter to much for steppers - but well I want to use servos... 2).
B) Are the Hiccups an issue?
C) Are they maybe caused the DuetBoard or the bus system and not the Compute unit?
D) are there any performance improvements from switch to Klipper (and a powerful computer)?

[dc42]

@qurt we occasionally measure the maximum step rates supported by Duet main and expansion boards and publish them at https://docs.google.com/spreadsheets/d/1AWA1wLbOaYzxzdQa5LRZvn9rgEk2BuluHy6-_OnD6FY/edit?usp=sharing.

In RRF all motion calculations are done on the Duet. Motion control and communication with expansoio boards are real-time task once the moves have been melded and finalised, and is therefore best done by a real-time processor running a real-time operating system. When Duet+RRF are used in SBC mode, the parsing of GCode commands is done on the SBC so that that Duet is relieved of some non-real-time tasks.