[ECOS] posix time functions

[David Brennan]

Nick Garnett wrote:

>David Brennan <eCos@brennanhome.com> writes:
>
>  
>
>>Nick Garnett wrote:
>>
>>    
>>
>>>David Brennan <david@brennanhome.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
>different things.
>
>  
>
>>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
>interval.
>
>  
>
You are correct, my particular problem is setting the clock with the 
POSIX function, then causing issues with non-POSIX timers. But I was 
thinking that it would make sense for the same change to apply to the 
POSIX timers also. That was when I checked the POSIX specifications and 
decided that perhaps this isn't the right way to fix this.

>>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
>coming from?
>
>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.
>  
>
Yes the problem is with that awkward frequency. I don't have the math 
handy, but we calculated that if we set the PIT to an interrupt rate of 
1kHz, we would end up off by about 180 mSec per hour. Our system 
actually has multiple computers which generate messages with "real-time" 
time stamps which are often compared with each other for diagnostic 
purposes. So we need mSec accuracy on those messages.

>  
>
>>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.
>
>
>  
>
Really? I did not think the Dallas chip could interrupt that quickly. (I 
thought it was on the order of 1 Hz). However, I will still need to be 
able to set the clock without affecting any of the OS timers.

David

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