Delay setting RTEMS clock with TOD_Set.

[Gedare Bloom]

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.

-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