This is the mail archive of the
mailing list for the eCos project.
Re: [ECOS] posix time functions
David Brennan <eCos@brennanhome.com> writes:
> Nick Garnett wrote:
> >David Brennan <email@example.com> writes:
> >>I was also wavering if the new term needed to be protected by a
> >>semaphore. I decided against it. (Due to the fact that an invalid
> >>gettime would have relatively low risk of creating problems combined
> >>with relative number of times that the time will be set within an
> >>application.) However, if you feel it is necessary, I will add one.
> >This is good as far as it goes. However, you still need to make some
> >changes in timer_settime() and timer_gettime(). These need to add or
> >subtract the real_time_offset as appropriate. Consider the following
> >code for example:
> > clock_gettime(CLOCK_REALTIME, &ts.it_value);
> > ts.it_value.tv_sec += 5;
> > timer_settime( timer, TIMER_ABSTIME, &ts, NULL );
> Hmmm, I did not think of people accessing it that way, I assumed that
> clock_gettime would only be used to get a calendar time. I had assumed
> (probably incorrectly) that to get the current real-time, one would
> use something like cyg_current_time().
No. clock_gettime() is the intended source of timestamps for
generating absolute times in all the POSIX timer functions. It's the
only thing that returns a struct timespec, other functions return
> Solving it like you suggest is
> only going to bring back the problem that I initially had.
I probably misunderstood what problem you were seeing. I was trying to
solve the problem of non-POSIX timeouts (in the netstack for example)
being affected by calls to clock_settime(). It looks like you were
more concerned over its effect on POSIX timeouts.
Strict POSIX conformance requires, when clock_settime() is called, for
all abosolute timeouts to track the change in the time base. Relative
timeouts should not change and remain ready to trigger after the same
> I haven't
> looked at the API closely, would it be safe to assume the code written
> above could be written using timer_gettime first?
That just gets the time until the expiry of an active timer, I don't
think it would make any difference.
> The idea was that
> if you change the calendar time, you do not want all of the absolute
> timers to change their alarm times. In my application, I will set the
> time using a pseudo NTP type function about once an hour. Due to the
> timing resolution of the i386 platform with a base clock frequency of
> 1 kHz, I will set the time backwards about 200 mSec each hour. This
> causes all of my alarms to get delayed by an extra 200
> mSec. Therefore, I want to be able to change the time that posix
> thinks it is without affecting any "real" real-time timers, none of
> which are set from the clock_gettime function.
This seems a somewhat kludgy solution. Exactly where is the inaccuracy
Using the PIT to keep track of real time over a long period is hard
since it runs at a very awkward frequency -- although I believe it is
reasonably accurate at a 200Hz interrupt rate. It is OK for handling
timing requirements of less that a minute or so.
> The more that I think about this, I'm wondering if the right solution
> is to add functions like cyg_gettimeofday and cyg_settimeofday. The
> only reason we were using the Posix function (and in fact, I think the
> only reason we are including the POSIX package), is because it is the
> only public function to adjust the time of day. However, I can see
> where it would lead to confusion. Additionally, we could make these
> functions conditionally (with CDL) set the wall-clock, as some people
> had previously requested.
Does your i386 platform have the standard Dallas RTC device? If so
then you could use that to track real time more accurately. The Dallas
device also provides a 1KHz interrupt which is more accurate than the
PIT, and is synchronized to the real time clock. It may be easier to
add an option to switch the eCos timer over to using that.
Nick Garnett eCos Kernel Architect
http://www.ecoscentric.com/ The eCos and RedBoot experts