This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Changing system timer resolution


Jonathan Larmour <jlarmour@redhat.com> writes:

> Nick Garnett wrote:
> > 
> > There are no execution time requirement on gettimeofday(), it is not
> > meant, in UNIX/POSIX, to act as a realtime timer.
> 
> Yes, but it provides an interface we can use to do this. And people do
> assume that gettimeofday() is fast. People use it so much in timing loops
> that it needs to be.

They really shouldn't. But see below.

> > Sub-tick resolution is not something we can address now, I would
> > oppose the incluson of any quick fix to do this. If users want to
> > cobble something together themselves, so be it, but I don't want it in
> > the main sources. The kernel APIs are all designed to work in ticks,
> > adding random bits of API that work in other units is inconsistent and
> > would be incompatible with future plans.
> 
> Then we'd need to have some future plans for them to be incompatible with
> ;).

I do, it involves the substantial rewrite of the whole
timer/clock/alarm system I alluded to earlier. We just don't have the
time/resources to do this just yet. In the meantime I don't want to
see hostages to fortune being smuggled into the sources (or whatever
other metaphor you would like :-)

> A lot of times I see gettimeofday used, it is for when a program to manage
> time-related things itself (although I tend to see this more on *nix
> systems). As such, only relative offsets are frequently required.
> 

In *nix systems this is because this is the only real way of getting
sub-second timings. But even there, just because gettimeofday()
reports times to a resolution of nanoseconds, it does not mean that
the underlying time sources are running at that resolution. Time will
still advance at 10ms granularity.

-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]