Delay setting RTEMS clock with TOD_Set.

[Joel Sherrill]

On 4/10/2013 12:47 PM, Rafael Morales wrote:
> Thank you for your responses.
>
> I will play with different "CONFIGURE_MICROSECONDS_PER_TICK" values
> configuring "CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER" and
> setting the clock.
FYI without checking the code, the sparc's may all be programmed where there
is only a microsecond (not nanosecond) of granularity from the 
timer/counter.
> I expect to find the right values.
>
> Best regards.
>
>> 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