Timing question

[Hank Jedema]

Hi all,

I am a puzzled by looking at the Edat2 output of my E-prime file: In the same inline, I am logging/collecting the timing of a trial start using the "timer" option in E-prime (v 2.0.10.242) as well as the onset of the first (and same) stimulus that shows on the screen at the start of a trial. 

There are a few lines of code in between, in which a few other values are written to the datafile, but basically I have:

c.setAttrib "TrialStart", timer

and 

Stimulus.OnsetSignalEnabled = True

Stimulus.OnsetSignalPort = &H378

Stimulus.OnsetSignalData = 64

Clearly, the "timer" collects values from the onset of the day in seconds and the other sequence collects the time from the onset of the program in msec, but what puzzles me is these times diverge (after subtracting the respective values of trial 1) by as much as 3.5 sec over a ~500 trial period or~36min. In other words, the time elapsed between trial 500 and trial 1 based on "timer" values is 2176.91 sec while the time elapsed between the same trials based on "onset" values is 2173.595 sec !

This discrepancy seems to occur in a very linear fashion over time. I.e. a scatter plot of the "timer" values versus "onset" values shows a nice straight line (with a correlation coefficient of 1.0000, but with a slope of 0.9986.

Is it possible that the increasing size of the datafile during the session causes that much of a delay/divergence in timing ? The sizes of my datafiles are about 2.5MB for the t.xt file and 0.7 MB for the edat2 file at the end of the task. Does anyone have other ideas what might be causing the divergence in these times?

Thanks very much for any suggestions,

Hank P. Jedema

[David McFarlane]

Hank,

It turns out that you can find some discussion of
this in the Knowledge Base article about
Clock.SystemTimeDrift,
http://www.pstnet.com/support/kb.asp?TopicID=2989
. Computers have more than one hardware clock,
and use different clocks for different
purposes. E-Prime strives to use a high
precision clock. Very likely this is a different
clock than the one that the machine uses for less
precise timing, e.g., seconds since midnight. So
when you use the timer function, you are probably
using a different hardware clock from the one
that E-Prime uses for everything else.

With that in mind ...

You should never use timer unless you have a very
specific reason to do so, and know what that
is. Otherwise, use Clock.Read, etc. (see that
and related topics in the E-Basic Help). Those
functions use the same clock as the rest of E-Prime.

Read the KB article referenced above, and look
into Clock.SystemTimeDrift on your own
machine. Although some drift between hardware
clocks may be expected, if they drift too far
apart from each other then at least one of them
is wrong, and you need to find out whether the
wrong one is the timer clock or the E-Prime
clock. Ultimately, you would do well to
calibrate E-Prime times against some external
time standard, e.g., an oscilloscope or a Black Box Toolkit.

-----
David McFarlane
Twitter: @EPrimeMaster (https://twitter.com/EPrimeMaster)

At 8/17/2015 01:48 PM Monday, Hank Jedema wrote:
>I am a puzzled by looking at the Edat2 output of
>my E-prime file: In the same inline, I am
>logging/collecting the timing of a trial start
>using the "timer" option in E-prime (v
>2.0.10.242) as well as the onset of the first

>(and same) stimulus that shows on the screen at the start of a trial.Â

>There are a few lines of code in between, in
>which a few other values are written to the datafile, but basically I have:
>
>c.setAttrib "TrialStart", timer
>

>andÂ

[Hank Jedema]

Thanks David, as always, for your helpful and quick reply. I know your trailer often states that you have no connection to PST/E-Prime, but they really should start paying you. 

Best,

Hank