Screen freezing and sound errors potentially caused by NTP timing

14 views
Skip to first unread message

Dan Kleinman

unread,
Jun 22, 2021, 2:00:07 PMJun 22
to E-Prime
Hi All,

Since I've seen several reports of E-Prime freezing, I wanted to report what appears to be a rare instance of freezing and crashing issues that (so far) appear to have been solved. I have made this post a little more detailed than necessary in case others find something useful in it, and because my experience suggests that several errors that present differently may have a common cause.

We have an experimental setup in which we are using E-Prime 2.0 to run two EEG experiments using the Net Station package. Both experiments involved presentation of both visual stimuli and auditory stimuli (the latter via Chronos) and ran fine for several months until mid-April, when – possibly after a system update of some sort – both began experiencing multiple kinds of problems. Sometimes, E-Prime simply froze (not at the first screen, but mid-experiment); other times, it threw errors related to sound buffering (errors 18031 and 18032). These crashes did not occur every time the experiments were run, but happened frequently enough that they had to be dealt with. It clearly seemed to be an equipment problem – not only because the scripts had worked fine for months before having issues, but because these they not have problems running on other equipment, and similar experiments that ran without problem on other equipment yielded sound errors on this same computer.

Troubleshooting revealed that the screen freezing always occurred when the next action that E-Prime was supposed to take involved a screen flip. In contrast, the sound errors only occurred when the next action that E-Prime was supposed to take involved presenting a sound. It seemed to me as though there was a low-level problem that occurred randomly, and that depending on what E-Prime was doing this problem could manifest in different ways (freezing or sound errors).

Further troubleshooting revealed the apparent source of the problem: Clock timing. As recommended by PST, I had configured the EEG experiments to use SNTP timing, which improves the precision of event trigger timing by synching with an external clock (specifically, the EEG computer's clock). Setting this to the default – E-Prime Realtime Clock – appears to have fixed the problem: In addition to extensive testing, we have now run 7 subjects in a row without any issues, whereas we were previously experiencing problems for ~50% of subjects.

Of course there is a reason why we prefer NTP timing, so this is not an ideal solution, but we would rather have imperfect timing for an experiment that doesn't crash than the inverse. (In addition, we use external timing equipment (a Cedrus StimTracker) to measure veridical onsets of stimulus presentation, so I am less concerned about clock drift than I would otherwise be.) For anyone else who encounters this problem and considers this as a potential solution, please make sure you understand the tradeoffs involved.

I've noted our E-Prime and system information below in case someone finds it useful (n.b. we are running a very old version of OS X on the computer that controls NTP timing; I don't know whether this is part of the problem). I contacted PST to ask them about this and will update this if I receive a useful response.

Best,
Dan Kleinman


Some relevant system details:
E-Prime 2.0 Professional, v2.0.10.356
E-Prime computer: Windows 10 Home, Version 20H2
Net Station computer [running NTP server]: OS X 10.6.8
Reply all
Reply to author
Forward
0 new messages