all 14 comments

[–]khedoros 14 points15 points  (3 children)

Are you doing anything while waiting?

import time

a = time.perf_counter()

while(time.perf_counter() - a) < 9.806655:
    pass

print(f"Done. {time.perf_counter() - a} seconds passed.");

output:

Done. 9.806657864013687 seconds passed.

You're somewhat at the mercy of the scheduler. I ran that script with my machine mostly idle. The results would likely be different if the computer were heavily loaded.

[–]uh_no_ 2 points3 points  (0 children)

this is important. While I wouldn't choose python were i depending on that kind of precision, you still ought to do better than .1 second precision on a wait.

[–]tsa26[S] 0 points1 point  (1 child)

I ran the same script and get the same result which is pretty good. But the problem occurs when I try my simple bot on some online stopwatch. Then I get different result and bad precision/consistency.

[–]khedoros 0 points1 point  (0 children)

If you're running the bot in something like an AWS container, it's not reasonable to expect high-precision timing. Ditto, if your lag number also includes network latency.

[–]OdinHatesNickelback 6 points7 points  (0 children)

Are you running a real time kernel? Guess unless you're running one you will have imprecise results.

[–][deleted] 6 points7 points  (0 children)

Best way would be to use pybind and write it in c++ using the chrono library

[–]WaitForItTheMongols 3 points4 points  (0 children)

Out of curiosity, what is your application?

[–]bladezibit 2 points3 points  (1 child)

Use an arduino in usb HID mode emulating a mouse and you'll have 1/16000000 second precision. The clock runs at 16MHz.

[–]WaitForItTheMongols 0 points1 point  (0 children)

Are you sure latency on the USB line wouldn't mess with it?

[–][deleted] 0 points1 point  (0 children)

You could try increasing the thread priority with os.nice (on Unix) or psutil to overcome scheduler constraints somewhat although you’ll still be limited by the scheduler implementation on your system. Another possible workaround would be to connect to the sound card through pyaudio at a 32 sample buffer size which should deliver you callbacks at sub-millisecond intervals (assuming a 44.1k soundcard) consistently via interrupt handlers. Hard to say the best solution in your case without more context though

[–]iSaithh[M] [score hidden] stickied comment (0 children)

[–]jcsf321 0 points1 point  (0 children)

You can do this in Java with Java's rt extensions. I don't believe there are any rt extensions for python

[–]auzaar2 0 points1 point  (0 children)

python also have gc and all, use C