I was wondering if there is something that can be improved to address these? I am using an Eyelink 1000 (but would get these with a 1000 plus too), and have the data_interval in the eye_tracker device set to 1ms, if that’s relevant.
Those warnings indicate that the MWorks thread that receives data from the EyeLink is falling behind its intended schedule (e.g. failing to read every 1ms as requested).
The most likely reason for this is that the CPU load on the Mac running MWorks is heavy (possibly sporadically), and the thread’s execution is being delayed by the operating system. In that case, decreasing the CPU load could help, e.g. by closing unneeded applications and avoiding CPU-intensive tasks like data analysis. It’s also possible that the Mac’s CPU just doesn’t have enough cores to do all that’s being asked of it in a timely fashion, in which case you might need to use a different Mac with more or faster cores.
Another possibility is that the thread is being delayed because reads from the EyeLink are blocking. To see if that’s happening, I would need to make a custom MWorks build for you that includes some debugging code. This seems much less likely to me, but we can investigate if you want.
I will try decreasing the CPU load outside of MWorks first. So what exactly does “dropping 26 scheduled executions” mean- that 26ms of eyelink data is dropped, but then the rest is on time? Or would there be a lag?
“Dropping 26 scheduled executions” means that, although the MWorks thread has been delayed for approximately 26ms, it isn’t going to try to “make up” the missed executions, i.e. by reading from the EyeLink 26 times as rapidly as possible. Instead, it’s just going to continue trying to read every 1ms. What this means for the EyeLink data depends on why the delays are happening.
MWorks uses a software library provided by EyeLink to interact with the hardware. I assume (but don’t know) that this library buffers incoming eye data internally. If this is true, then if, due to CPU load on your Mac, MWorks stops reading for 26ms and then resumes, it will read out all the data from the library buffer (unless the buffer ran out of space and the library had to start dropping samples). Hence, you’ll still get all the eye positions reported by the tracker, but the samples from the 26ms delay interval will have time stamps that are all very close to each other on MWorks’ clock. If you’re using the eye_time parameter to record the sample times on the EyeLink’s clock, those values should still be evenly spaced according to the tracker’s acquisition rate.
Alternatively, if the delays are due to reads from the EyeLink blocking, then I don’t know what will happen to the eye data. However, you should be able to use eye_time to see if any samples are missing. Actually, that might be a way to distinguish between the two delay causes, without any need for a custom MWorks build.