You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 19, 2024. It is now read-only.
Currently, the only way to get accurate sub-second timing information is through the uptime interface, which is disturbingly wrong (though slightly interesting from a plan9 perspective...)
There are several places where sub-second timing information would be useful:
Ensuring smooth animations in the compositor.
Support double clicks properly.
Video playback.
One of the POSIX timing APIs should be fully implemented with at least millisecond accuracy, but preferably microsecond accuracy (which is currently lacking). May require general upgrades to timekeeping.
The text was updated successfully, but these errors were encountered:
Note gettimeofday is obsolete. The modern (and superior) interface is clock_gettime, which supports multiple clocks in nanosecond precision (which should prove sufficient for everything, struct timespec is the standard super timestamp format having replaced struct timeval). Monotonic time is nice for games and other applications where elapsed time is more important than clock time, which might not be continuous.
The internal clock is now used for gettimeofday. The resolution has been increased to milliseconds (I also kept the PIT bound to issuing a preemptive task switch, so the preemptive quanta is now one millisecond instead of 10). In the future, I'd like to add more precision with the TSC or another such clock source, but this is a good middle ground for the interim.
I'd like to add more precision with the TSC or another such clock source
This Issue is ancient, so has that happened yet? If not it sounds neat and I might try to make it happen. Either way I guess I'll be poking through the code today so I'll probably know before you read this.
The tough thing about actually use the TSC usefully is that it needs calibration since it's linked to clock speed rather than wallclock. Perhaps, moving forward, TSC would be useful as the timing source for wallclock information and we can keep using the PIT as the main preemption source... A lot of the problems with this ticket were fixed by increasing the PIT rate.
klange
added
the
legacy
An issue reported from ToaruOS 1.2.x which has been closed.
label
Oct 6, 2018
Currently, the only way to get accurate sub-second timing information is through the uptime interface, which is disturbingly wrong (though slightly interesting from a plan9 perspective...)
There are several places where sub-second timing information would be useful:
One of the POSIX timing APIs should be fully implemented with at least millisecond accuracy, but preferably microsecond accuracy (which is currently lacking). May require general upgrades to timekeeping.
The text was updated successfully, but these errors were encountered: