I am running an experiment where there is a 10 second routine followed by a loop of 5 second trials. After running the experiment, I go look at the data from the experiment(Log File) to see exactly when a new trial is starting. My expectation is that a new trial starts exactly 5 seconds after the previous trial starts but that is not the case. The time at which the first trial starts is at 16.2646 seconds, but the time at which the second trial starts is at 21.2674 seconds which is 5.0028 seconds. The third trial starts at 26.2658 seconds which is 4.9951 seconds after the second trial started. I am trying to get my experiment to start the next trial exactly 5.000 seconds(or at least within a millisecond) after the previous trial has started.
The time-jitter you describe is at most 5 ms and it doesn’t seem to accumulate. Am I right that trial #20 is still only off by a few milliseconds compared to when it was supposed to start (800 seconds after trial 1 start)?
Given that you probably use visual stimulation on a less-than-200Hz-monitor (most are 60 Hz), you can only show stuff every 16.667 ms because of hardware. So think of time as discrete and everything that happens in code is “rounded off” to the nearest frame. If it’s pure sound and keyboard/mouse logging, then this timing is probably representative of what’s actually going on. There’s a great deal of information and tricks about timing in PsychoPy here in the documentation.
There could be a real problem (if single frames matter) that a trial that starts after 4.999 ms will arrive a frame before a trial that starts after 5.001 ms. I don’t know enough about the internals of Builder to confirm this, but perhaps @jon can.
Screens typically update at a very regular rate indeed (variability in microseconds) although I’ve seen some that some screens have a refresh that isn’t exactly 60Hz (e.g. 59.8Hz but still consistent).
Anyway, there’s nothing you can do about that and whatever variability you’re seeing is more likely to be variability in the clock measurement than variability in actual stimulus presentation. With variability of this order the key is shutting down all other processes and making sure you’re on a decent computer. What is your machine?
Could you run the timeByFrames demo and send the image of the timing plot at the end? To reiterate, that isn’t showing you variability in the screen but, rather, it’s indicating variability in your cpu timing things (e.g. its busy doing something else while it should be checking the clock).
Anyway, all this is academic. If it’s stimulus presentation time that you care about I’m sure you’re spot on. Jonas’s concern isn’t one to worry about either; the Builder “decides” to present one more frame if there’s more than half a frame to the target time (at 4.99s it won’t try to squeeze in another)