Hi,
assuming you did everything right in reimplementing at least the more
trivial part of PTB's bufferswap timestamping, what you'll see is
regular clock drift, as Xiangrui already suggested. You'll need to
compensate for that manually by estimating the drift and properly
correcting your timestamps. Or synchronize both clocks frequently so
the drift can't accumulate to significant levels.
NTP is meant as a method to roughly synchronize clocks of multiple
computers to some reference, but not really at millisecond
resolution. You'd probably need a local NTP server in your network
and quite careful configuration of all machines involved to get the
kind of drift correction you want without side effects.
Even then it wouldn't help much: mach_absolute_time(), Uptime(),
GetAudioHostClock() etc. are all derived from the same physical clock
on OS/X, with essentially the same resolution. All of them (if i
remember correctly from my last inspection of the OS/X kernel
sourcecode and documentation) are computed basically as time since
system startup and they are all taken *before* NTP time correction,
so they are unaffected by it. I think only the Unix gettimeofday()
syscall would take NTP into account.
Also, can you be certain that the Netstation system is NTP corrected?
Otherwise it will drift as well.
Finally, if you timestamp doublebuffer swaps, then you are in some
sense measuring a timebase that is given by the graphics cards
internal clock. E.g., a display setup to run at 100 Hz won't provide
you with swaptimestamps of exactly 10 msecs distance, because the
clock of the GPU itself will also slightly deviate and drift,
depending on fluctuations in temperature, power supply, manufacturing
deviations etc. And the GPU clock can't by corrected/affected by NTP
or other schemes at all.
I believe the NetStation.m driver in PTB just resync's the clocks of
netstation and host by some simple protocol of sending timestamps or
recording timestamps of an "echo packet", and apparently that's good
enough. Google for "Netstation.m" for that code.
best,
-mario
assuming you did everything right in reimplementing at least the more
trivial part of PTB's bufferswap timestamping, what you'll see is
regular clock drift, as Xiangrui already suggested. You'll need to
compensate for that manually by estimating the drift and properly
correcting your timestamps. Or synchronize both clocks frequently so
the drift can't accumulate to significant levels.
NTP is meant as a method to roughly synchronize clocks of multiple
computers to some reference, but not really at millisecond
resolution. You'd probably need a local NTP server in your network
and quite careful configuration of all machines involved to get the
kind of drift correction you want without side effects.
Even then it wouldn't help much: mach_absolute_time(), Uptime(),
GetAudioHostClock() etc. are all derived from the same physical clock
on OS/X, with essentially the same resolution. All of them (if i
remember correctly from my last inspection of the OS/X kernel
sourcecode and documentation) are computed basically as time since
system startup and they are all taken *before* NTP time correction,
so they are unaffected by it. I think only the Unix gettimeofday()
syscall would take NTP into account.
Also, can you be certain that the Netstation system is NTP corrected?
Otherwise it will drift as well.
Finally, if you timestamp doublebuffer swaps, then you are in some
sense measuring a timebase that is given by the graphics cards
internal clock. E.g., a display setup to run at 100 Hz won't provide
you with swaptimestamps of exactly 10 msecs distance, because the
clock of the GPU itself will also slightly deviate and drift,
depending on fluctuations in temperature, power supply, manufacturing
deviations etc. And the GPU clock can't by corrected/affected by NTP
or other schemes at all.
I believe the NetStation.m driver in PTB just resync's the clocks of
netstation and host by some simple protocol of sending timestamps or
recording timestamps of an "echo packet", and apparently that's good
enough. Google for "Netstation.m" for that code.
best,
-mario
On Jun 4, 2009, at 9:48 PM, harpreet_roohi wrote:
> Hello Mario,
>
> Thanks for the response. I have been using your post given below
>
> https://lists.berlios.de/pipermail/osxptb-dev/2006-January/000032.html
>
> to make stimulus presentation on the screen. I am using another
> open source program names Psycopy which does not have this
> capability. Using the reference link (which is great and very
> informative), I have been exactly able to synchronize my display
> with VBL.
>
> But when I report this time to Net Station, I start to see some
> linear drift over period of time. Instead of using ticks (as used
> in your program), I am relying on mach_absolute_time() and nano
> sleep to control the execution. But after period of time, kernel
> clock drifts from hardware AV tester.
>
> I enabled NTP but that did not help . I am sure you must have faced
> the same issue in Psychtool box as some of your code comments tell
> that you are accounting for drift by going to cpu level and keeping
> it all real time. I have tried all those but see no improvements.
>
> I will appreciate your help.
>
>
> --- In psychtoolbox@yahoogroups.com, "Mario Kleiner"
> <mario.kleiner@...> wrote:
>>
>> What are you talking about? kernel level mac_Absolute_Time ??
>> nanosleep?
>> Where does this come from in Psychtoolbox??
>>
>> -mario
>>
>> --- In psychtoolbox@yahoogroups.com, "harpreet_roohi"
>> <harpreet_roohi@> wrote:
>>>
>>> Hi
>>>
>>> Synchronization with VBL is achieved , but the time which we are
>>> sending to Net Station(EEG recording device) is drifting over
>>> period of time .
>>>
>>> We are using kernel level mac_Absolute_Time to get the current
>>> time and nanosleep to wait during experiment.NTP synchronization
>>> is enabled on my laptop and I have checked in my System
>>> prefrences Set Date& Time automatically is checked .I saw in
>>> Psychtoolbox they are using ticks instead of absolute time.
>>>
>>> Are we missing something ? Does anyone knows if mac_Absolute_time
>>> drifts?.
>>>
>>> It would be helpful if someone send a post on this.
>>>
>>> Regards
>>>
>>> Ravneet
>>>
>>
>
>
*********************************************************************
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany
e-mail: mario.kleiner@...
office: +49 (0)7071/601-1623
fax: +49 (0)7071/601-616
www: http://www.kyb.tuebingen.mpg.de/~kleinerm
*********************************************************************
"For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled."
(Richard Feynman)