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
As evidenced by #17, the act of using the Time Stamp Counter can be rife with corner cases that make it hard to reason about how intended behavior will diverge from actual behavior. As well, we lack a consistent way to attempt to validate the information we do find: if the Intel SDM tells us something should function a certain way, how do we try and verify that in practice?
Given the overarching goal of quanta to provide a safe and fast interface to TSC/RDTSC, we should create a torture test application that can be used to attempt to surface bugs and inconsistencies.
Specifically, given the concern about TSC synchronization between cores, and how that would affect timekeeping math, a good variant of this hypothetical torture test app would be one where multiple threads are taking measurements, yielding, doing something that hopefully gets them rescheduled on different cores, and taking a follow up measurement, looking for warps in time. Potentially even some sort of Dining Philosophers type of thing where values are sent between threads specifically to attempt to exacerbate being scheduled on another core, or another socket.
The text was updated successfully, but these errors were encountered:
As evidenced by #17, the act of using the Time Stamp Counter can be rife with corner cases that make it hard to reason about how intended behavior will diverge from actual behavior. As well, we lack a consistent way to attempt to validate the information we do find: if the Intel SDM tells us something should function a certain way, how do we try and verify that in practice?
Given the overarching goal of
quanta
to provide a safe and fast interface to TSC/RDTSC
, we should create a torture test application that can be used to attempt to surface bugs and inconsistencies.Specifically, given the concern about TSC synchronization between cores, and how that would affect timekeeping math, a good variant of this hypothetical torture test app would be one where multiple threads are taking measurements, yielding, doing something that hopefully gets them rescheduled on different cores, and taking a follow up measurement, looking for warps in time. Potentially even some sort of Dining Philosophers type of thing where values are sent between threads specifically to attempt to exacerbate being scheduled on another core, or another socket.
The text was updated successfully, but these errors were encountered: