Delay setting RTEMS clock with TOD_Set.

[Joel Sherrill]

On 4/10/2013 8:21 AM, Gedare Bloom wrote:
> You can control the tick resolution with the configuration option:
> #define CONFIGURE_MICROSECONDS_PER_TICK 1000
> Or some suitable number other than 1000. (The default is 10000.)
> This option affects the granularity of timing and scheduling events.
Your examples did not use any public APIs. What did you use to set the 
clock?
If rtems_clock_set(), then it is specified at a tick granularity. The POSIX
clock_settime() and clock_gettime() use struct timespec to specify the time.
Some commonly used POSIX time related methods are enabled even when
--disable-posix is specified.

If this is simply rounding based on the CONFIGURE_MICROSECONDS_PER_TICK,
then you can configure with CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
and run various values through setting and getting the clock.

The disable/enable dispatch will only have impact if there is a task
readied as a side-effect of changing the time. And this leads to
preemption of the currently executing task.

--joel
> -Gedare
>
> On Wed, Apr 10, 2013 at 9:16 AM, Gedare Bloom <gedare at rtems.org> wrote:
>> I guess this is in the rtems_clock_set routine that the TOD_Set is called? [1]
>>
>> My best guess is that the granularity of the time is quite coarse, so
>> you are seeing some rounding errors based on when in the current
>> "tick" the TOD_Set is called. For example, look at lines 51-53:
>>
>>      newtime.tv_sec = _TOD_To_seconds( time_buffer );
>>      newtime.tv_nsec = time_buffer->ticks *
>>        rtems_configuration_get_nanoseconds_per_tick();
>>
>> The fine-grained resolution of time (nanoseconds) is approximated by
>> the number of ticks times the configured ns per tick. By default this
>> is going to be about 10 milliseconds per tick, so you would expect on
>> average about 5 ms difference between the actual time and the
>> approximated time.
>>
>> [1] http://git.rtems.org/rtems/tree/cpukit/rtems/src/clockset.c?id=4.10.2
>>
>> -Gedare
>>
>> On Wed, Apr 10, 2013 at 6:00 AM, Rafael Morales <rmorales at iaa.es> wrote:
>>> Dear all,
>>>
>>> We are using a development system based on Leon3 at 25MHz clock and RTEMS
>>> 4.10 (Gaisler version 4.10.1.2.8).
>>>
>>> We are experiencing a big delay setting the clock time with TOD. The
>>> sequence is:
>>>
>>>       struct timespec startTimeStamp;
>>>      get_time_stamp(&startTimeStamp);
>>>
>>>      _Thread_Disable_dispatch();
>>>      _TOD_Set( newtime );
>>>      _Thread_Enable_dispatch();
>>>
>>>      struct timespec stopTimeStamp;
>>>      get_time_stamp(&stopTimeStamp);
>>>
>>>
>>> If we get the new time after the _TOD_Set, we see that current time as about
>>> 1-5 milliseconds late. We have try to delete the _Thread_Disable_dispatch
>>> and _Thread_Enable_dispatch with no results. It seems that the call _TOD_Set
>>> is the responsible of the delay
>>>
>>> Any idea about how to manage this situation?
>>>
>>> Thanks in advance.
>>>
>>>> Hi,
>>>>
>>>> here is the proof for the patched hello world on the sis target and the
>>>> patch generated by git. I hope it's okay.
>>>>
>>>> I also got a first draft of the proposal, so the question is: Who wants to
>>>> read it?
>>>>
>>>> Regards,
>>>> Philipp
>>>>
>>>>
>>>> screenshot:
>>>> https://wwwpub.zih.tu-dresden.de/~s8940405/gdb_hello_world.png
>>>>
>>>> patch:
>>>>
>>>> https://wwwpub.zih.tu-dresden.de/~s8940405/0001-hello-world-gsoc-2013-fix.patch
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985