[En-Nut-Discussion] Time handling functions

[Ole Reinhardt]

Hi Harald,

> Oh, already another year is over? Just wondering, because this has been
> discussed and reportedly fixed in regular time intervals. I hardly
> remember a similar thread with BTNut, many years ago, where it had been
> reported as fixed, wasn't it. ;-)

Yes, I remember too :) Could this be the reason for several other bugs
reported in the past, which use kind of timeout calculations? Perhaps
also DHCP?

>> But this also means, that the calculation of time() results in an error
>> after 49,x days. Right?
> 
> Following your post: Yes, looks like. Probably most applications dealing
> with calendar dates make use of RTC hardware, where this problem never
> appears. Anyway, yes, this bug must be fixed.

;-)


>> What I really need is a second counter, startet at system startup and
>> increment at each 1000 system ticks (if we have 1ms system tick
>> interrupt) and also a milliseconds counter, which is incremented by 1
>> each millisecond (timer tick) and wrapped to 0 after 1000 increments.
> 
> Not sure, if I understood. IMHO, clearing the millisecond counter on
> each full second would break timeout handling in the wait queues,
> wouldn't it? That needs to be changed as well, doesn't it?

Little misunderstanding. I'd like to implement some kind of software
clock, which counts seconds and ms. I do not want to remove or change
the old tick counter but add an additional ms counter, which wraps
around after 1000ms and then increments the seconds counter.

What I really want is a reliable "gettimeofday()" implementation with at
least ms resolution.

Currently we don't have a way to correctly measure the time with a
resolution of less than 1s and can not correct it with a better
resolution (using ntp for example).

Why I can't use the NutGetMillis():

NutGetMillis() and also the timer ticks do not correspond to the seconds
value returned by time() / NetGetSeonds(). Further more it wraps around
at a value which is not aligned to a full second (1000). Therefor you
can have a NutGetMillis() % 1000 value which is not necessarily 0 at the
start of a second.

So when implementing gettimeofday() we would finally need a correct
seconds and ms counter where we could apply an epoch offset (for both:
seconds and ms) to get the current "real" time.

> These "few more" instructions will increase the global interrupt
> latency. If an application uses a specific Nut/OS driver with long
> interrupt handling, it's its own decision. Lengthening the timer
> interrupt would apply to all applications, without any chance to fix this.

Yes, I understand.

> And yes, there are applications with 100ms system tick, which was the
> standard in early Nut/OS days.

Ok, in this case we could increment the ms counter by 10 at each timer
tick. However the tick timer should run at an even multiple of a
millisecond.

> So far, I never used Nut/OS on battery driven system. But if, then being
> woken up every millisecond may significantly increase power consumption.

Shure.

I could also live with a ms counter resolution much less than 1ms, but
at least is should be correct and alligned to the starting of a full second.

> My conclusion: Do not add to the timer handling without offering a
> chance to switch back the old behavior via configuration.

Ok

> My idea: May be there is a possibility to fix this in NetGetSeconds() only.

This would not help to implement the time keeping correctly. See above
comments.


Btw: Adding a software clock to the tick counter would

- increase interrupt latency / add a few more instructions to the
  system tick interrupt

- Speed up NutGetSeconds() / time() etc. significantly.

I would also vote to remove the RTC query from the time() implementation
and rely on the software clock, but add a new NutRtcSync)() routine to
sync the software clock with the hardware clock.
Next we could improve the sntp implementation to correctly sync the
system time up to a ms accuracy.

Regards,

Ole

-- 
kernel concepts GmbH            Tel: +49-271-771091-14
Sieghuetter Hauptweg 48         Mob: +49-177-7420433
D-57072 Siegen
http://www.embedded-it.de
http://www.kernelconcepts.de