I hope you are well. I am troubleshooting a problem with our system that involves the precise timing of events in Mworks. I’ve narrowed it down to a one-time suspected “jump” in a clock time (by an order of ~10ms). Does the mworks clock write event times in an mwk file based on its own internal clock (and is there anything you can think of that could make that clock jump, or any way to test post-hoc if this occurred?) Or does the time an event is written depend on the mac OS clock, and would it be subject to something like the computer synchronizing its clock with the Apple servers?
MWorks’ clock is based on mach_absolute_time, which is the highest-precision clock available on macOS and iOS. The values returned by mach_absolute_time aren’t tied to wall-clock time in any way, so they aren’t affected by wall-clock time adjustments.
A standard MWorks time stamp is computed by obtaining the current value of mach_absolute_time, subtracting the value of mach_absolute_time recorded when MWServer started, and converting the resulting interval to microseconds. However, there are situations where events are not time stamped with their creation time, but instead are given times that are best estimates of when the real-world event to which they correspond actually happened (or will happen). For example, the time stamps on ITC-18 analog input samples reflect MWorks’ best estimate of when the sample was actually acquired, as described in Time stamping, and the time stamps on #stimDisplayUpdate events indicate the operating systems’s best guess as to when the corresponding display update will start appearing onscreen.
Can I ask what type of event you’re seeing the 10ms jump in? Is it just normal variable assignments, or is it related to stimulus display updates or an I/O device?
Thanks Chris for the detailed answer! t’s a bit convoluted, but the event we’re potentially seeing the jump in is a variable changing value. It is a variable that, when changed, causes the ITC-18 to send an output pulse to activate our recording setup. I found an old forum post you wrote about inferred time and ITC-18 inputs. Are ITC-18 outputs also subject to this kind of timing inference?
If your experiment is assigning a value to the variable, then the time stamp on the associated event is just the time of the assignment. (The ITC-18 device responds to the assignment, but it can’t influence the time stamp.) So now the question is: How do you know that the assignment is happening 10ms later than you expect? That is, with what other time are you comparing it? Does the recording system feed back a signal in to MWorks, so that you’re seeing a delay in that? Or are you comparing with the time stamp of a prior variable assignment, e.g. one immediately before the problematic one, and seeing an unexpected 10ms between them?