[ECOS] Adjustable wallclock (get/settimeofday, adjtimex)?

[ECOS] Adjustable wallclock (get/settimeofday, adjtimex)?

[Stanislav Meduna]

Hi,

the gettimeofday method in compat/posix is currently implemented
based on cyg_current_time(), settimeofday is missing.

If I understand it correctly the cyg_current_time() is also
used for timeout processing all over the code so messing
with its base is not a good idea.

There is also an io/wallclock, but this provides only a 1-second
resolution and warns of up to one second delay when reading/writing.


I need to implement a NTP-like model soon, which means:

- gettimeofday with best possible resolution and negligible
  call delay
- settimeofday
- the ability to speed up or slow the clock (adjtime/adjtimex
  or similar), both permanently or until the requested offset
  is compensated for; the clock must not go backward
- the ability to initialize from / store the current time to
  a battery-backed device


What is the best way to approach it? Should I modify the
Cyg_RealTimeClock? Should I attach an alarm there on each tick
and do my stuff there? How to make gettimeofday use the 'new'
clock so it does not look like an ugly hack?

Anyone already approached this?

Thanks
-- 
                                   Stano

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Adjustable wallclock (get/settimeofday, adjtimex)?

[Daniel Néri]

  Hello,

Stanislav Meduna <stano@meduna.org> writes:

> I need to implement a NTP-like model soon, which means:
>
> - gettimeofday with best possible resolution and negligible
>   call delay
> - settimeofday
> - the ability to speed up or slow the clock (adjtime/adjtimex
>   or similar), both permanently or until the requested offset
>   is compensated for; the clock must not go backward

I've described my approach in an older thread on this list:

  http://thread.gmane.org/gmane.os.ecos.general/25842/

I never bothered with sub-second resolution for setting time
(settimeofday), so I just use cyg_libc_time_settime.

> - the ability to initialize from / store the current time to
>   a battery-backed device

I've used a hybrid between the emulated wallclock and a "real" wallclock
device driver -- it only reads absolute time from the h/w via
Cyg_WallClock::init_hw_seconds and writes via
Cyg_WallClock::set_hw_seconds. Otherwise, it works like the emulated
wallclock driver.


Best regards,
Daniel



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Adjustable wallclock (get/settimeofday, adjtimex)?

[Grant Edwards]

On 2011-06-26, Stanislav Meduna <stano@meduna.org> wrote:
> Hi,
>
> the gettimeofday method in compat/posix is currently implemented
> based on cyg_current_time(), settimeofday is missing.
>
> If I understand it correctly the cyg_current_time() is also
> used for timeout processing all over the code so messing
> with its base is not a good idea.

When I needed to adjust the time to keep it in sync with a real-time
clock, I did it at a lower level by adding hooks into the target's HAL
code that allowed me to gradually slew the cyg_current_time() value by
adjusting the length of a system tick by small amounts.

-- 
Grant Edwards               grant.b.edwards        Yow! I request a weekend in
                                  at               Havana with Phil Silvers!
                              gmail.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Adjustable wallclock (get/settimeofday, adjtimex)?

[Stanislav Meduna]

On 27.06.2011 16:16, Grant Edwards wrote:

> When I needed to adjust the time to keep it in sync with a real-time
> clock, I did it at a lower level by adding hooks into the target's HAL
> code that allowed me to gradually slew the cyg_current_time() value by
> adjusting the length of a system tick by small amounts.

Could you elaborate a bit? Did you change the hardware's interrupt
frequency? This would be the best solution, but it depends on how
easy the frequency can be adjusted without disturbing the current
running interval, if at all (e.g. on some hardware the counter
reload value can't be accessed atomically and hitting the wrong
values at wrong time could produce unacceptable clock interrupt
jitter).

Regards
-- 
                                         Stano

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Adjustable wallclock (get/settimeofday, adjtimex)?

[Grant Edwards]

On 2011-06-27, Stanislav Meduna <stano@meduna.org> wrote:
> On 27.06.2011 16:16, Grant Edwards wrote:
>
>> When I needed to adjust the time to keep it in sync with a real-time
>> clock, I did it at a lower level by adding hooks into the target's HAL
>> code that allowed me to gradually slew the cyg_current_time() value by
>> adjusting the length of a system tick by small amounts.
>
> Could you elaborate a bit? Did you change the hardware's interrupt
> frequency?

Yes.

> This would be the best solution, but it depends on how easy the
> frequency can be adjusted without disturbing the current running
> interval, if at all (e.g. on some hardware the counter reload value
> can't be accessed atomically and hitting the wrong values at wrong
> time could produce unacceptable clock interrupt jitter).

In my case, I was able to change the system tick timer reload value
without causing problems.  That might be difficult to do on some
hardware.  For example, you might have to do one (or both) of a couple
different "tricks":

 1) Stop the timer, change the reload value, then restart the timer
    with a new value that takes into account the time it was stopped.

 2) Check the timer to make sure it's not about to reload.  If it's
    not about to reload, change the reload value.  If it is about to
    reload, wait a bit and try again later.

Both of these generally need to be done with interrupts disabled, and
are probably best done in assembly language.
    
-- 
Grant Edwards               grant.b.edwards        Yow! Where's SANDY DUNCAN?
                                  at               
                              gmail.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss