The problem was that two consequtive reads of the RTC in quick
succession within the compiler was used to validate the
results in the buffer filled by the mtimes syscall.
This syscall buffer is potentially filled by another processor
or by the same one, so the programmers decided to use two
techniques to decide if the results are reliable:
1. Read the buffer twice and compare
2. Make sure that the two reads happened within 200 clock-cycles
from one another.
Since our RTC is based on the host clock, the actual time
passed between those two instructions depends on the host
speed.
This fix allows for a - programmable - interval within which
if two RTC queries are made, we return an artificially low
delta time. This makes cc happy, while doesn't interfere
with normal OS operation and scheduling.
The setting (RealTimeClockChunkLimit, which defaults to 5000)
might need to be adjusted for slow machines, such as the
RaspberryPi4 or similar.
