Small deviations in timers

[Alex-1248]

Mc 1.7.10
OpenComputers-MC1.7.10-1.8.2+94f6405-universal

I ran a program that kept repeating os.sleep(0.05) and noticed that at some times it sleeps for 0.05 seconds and at other times the sleep time fluctuates between 0.05 and 0.1 seconds. This happens systematically and predictably, and is related to the current value of computer.uptime(). For example, if you run such a program immediately after starting the computer, then fluctuations in sleep time begin at 8 seconds and end at about 30 seconds, and then start again at 128 seconds. If you assign 0.049 or 0.025 as sleep time, then the fluctuations almost disappear. If you replace os.sleep() with computer.pullSignal(), the results are the same. It seems that the fluctuations are caused by the inability to accurately represent most decimal fractions in the binary system and the resulting errors in arithmetic operations. Because of this, sometimes when a wake-up should occur, the deadline is slightly higher than computer.uptime() and the sleep is extended by 1 game tick. Event.timer() can theoretically also sometimes call a function a little later than it should. And also, if I understand the implementation of event.timer() correctly, it can drift if a number that does not have an exact binary representation is chosen as the interval, although a significant shift requires a large number of cycles and a large computer.uptime() value.

[asiekierka]

Could you please test the proposed fix? Build should be available here in a few minutes: https://github.com/MightyPirates/OpenComputers/actions/runs/5401692819

[Alex-1248]

I tested the os.sleep() and computer.pullSignal() functions. It looks like the issue is still not resolved.

[Alex-1248]

-0.001 should theoretically be enough, but I think -0.025 would be more reliable.
Although the fix most likely does not work for some other reason.

[zeng-github01]

Could you try this?

https://github.com/MightyPirates/OpenComputers/actions/runs/17332280489

Here is another solution that in my testing has improved this problem a bit

[Alex-1248]

Could you try this?

https://github.com/MightyPirates/OpenComputers/actions/runs/17332280489

Here is another solution that in my testing has improved this problem a bit

I tested the os.sleep(0.05) command and did not notice any improvement, the function still systematically sleeps for 0.1 seconds. Although it is possible that I made some mistake, my observations are based solely on the readings of the computer.uptime() function. I tested it on a fresh world, if that matters.

[zeng-github01]

I tested the os.sleep(0.05) command and did not notice any improvement, the function still systematically sleeps for 0.1 seconds. Although it is possible that I made some mistake, my observations are based solely on the readings of the computer.uptime() function. I tested it on a fresh world, if that matters.

This solution is provided by AI, which also provides an additional test script. The test results are fine. It may be that the test method is different from yours.

If it still doesn't work, I suspect it has something to do with Minecraft's tick system. This problem is probably unavoidable.

[Alex-1248]

I tested os.sleep() and event.pull() using a primitive script:

local computer = require("computer")
local event = require("event")
int = 0.05
c = 0
repeat
t = " "
time1 = computer.uptime()
os.sleep(int)
-- event.pull(int)
time2 = computer.uptime()
dif = time2 - time1
if dif < 0.025 or dif > 0.075 then
  c = c + 20
  t = "X"
elseif c > 0 then
  c = c - 1
end
print(c, t, time1, time2, dif)
until c > 80

The script endlessly repeats the pauses of 0.05 seconds and notes when the duration of the pause differs from 0.05 seconds. If this happens too often, the script stops. If you start the script immediately after turning on the computer, then it will work for no more than 8 seconds. If you replace sleep time (3 line) by 0.025, then the script will not stop.

Apparently, the os.sleep() function works more accurately and predictably, if you choose a sleep time that is a multiple of 0.05 (1 tick) and subtract 0.025 (half the tick) from it. Although even if the conditions are met, the function can occasionally oversleep for some reason.

[zeng-github01]

@Alex-1248 My attempt failed. I can't solve this problem in your test script. This problem is almost unsolvable unless there is a way to control the behavior of tick.

This is the test script I used, in which everything is basically normal

local computer = require("computer")

local interval = 0.05   
local rounds = 100      
local epsilon = 0.001 

local last = computer.uptime()
local driftSum = 0
local maxDrift = 0
local overTickCount = 0

for i = 1, rounds do
  os.sleep(interval)
  local now = computer.uptime()
  local delta = now - last
  local drift = delta - interval

  driftSum = driftSum + drift
  if math.abs(drift) > maxDrift then
    maxDrift = math.abs(drift)
  end
  if drift > 0.05 then
    overTickCount = overTickCount + 1
  end

  print(string.format("Round %4d | Δt = %.5f | Drift = %+0.5f", i, delta, drift))
  last = now
end

print("\n--- Summary ---")
print(string.format("Average Drift: %+0.5f", driftSum / rounds))
print(string.format("Max Drift:     %+0.5f", maxDrift))
print(string.format("Overtick Count: %d / %d", overTickCount, rounds))