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
Currently we use a configurable value for timer resolution which is based on the number of iterations that we run the scheduler. Since our tasks vary in runtime, this is an extremely imprecise way to decide when to check the system time for a timeout.
Proposed Solution
Use rdtsc to estimate a cycle budget that matches how frequently we want to check the time. For example, 1 second = roughly 2.6 million cycles on a 2.6Ghz CPU. Once we run out the budget, we take the system time and figure out how long it actually took for each cycle. Then we adjust the budget for the next iteration based on that.
The text was updated successfully, but these errors were encountered:
Context
Currently we use a configurable value for timer resolution which is based on the number of iterations that we run the scheduler. Since our tasks vary in runtime, this is an extremely imprecise way to decide when to check the system time for a timeout.
Proposed Solution
Use rdtsc to estimate a cycle budget that matches how frequently we want to check the time. For example, 1 second = roughly 2.6 million cycles on a 2.6Ghz CPU. Once we run out the budget, we take the system time and figure out how long it actually took for each cycle. Then we adjust the budget for the next iteration based on that.
The text was updated successfully, but these errors were encountered: