ARTIQ/RTIO-performance-and-optimizations.md

@@ -8,7 +8,7 @@ This page lists various observations, optimizations, and recommendations regardi
 1. Object attributes that are modified once or more during kernel execution are updated on the host once after the core device returns.
 1. We observed that the core device performance is very sensitive to changes in the program. Adding minor complexity (e.g. adding one local variable) might already measurable influence RTIO performance.
 1. Device initialization (e.g. for a 9912) can be very slow (i.e. > 1 ms) and such calls should be scheduled accordingly.
-1. Using `delay_mu(1)` seems to have no effect on the timeline and does not result in serializing events. For minimal delays required for event serialization we recommend to use `delay_mu(10)`. This behaviour is probably caused by the coarse reference clock which by default is a factor 8 slower than the RTIO reference clock.
+1. Using `delay_mu(1)` seems to have no effect on the timeline and does not result in serializing events. For minimal delays required for event serialization, use `delay_mu(self.core.ref_multiplier)`. We expect this behaviour is caused by the coarse reference clock which by default is a factor 8 slower than the RTIO reference clock.
 1. Consecutive calls to `gate_*()` functions (`TTLInOut` and `EdgeCounter`) on the same device need to have minimal delays between them. Without a delay, the gateware is not able to distinguish separate gate periods and fuses them into one larger gate period.
 
 ## Data types