Re: [PATCH 0/2] [RFC] posix clock tuning

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> > 1. character device (like hpet)
> > 2. posix clock api
> > 3. sysfs
> > 
> > Or possibly some combination of the three.
> 
> I fail to see the requirement for any of those. Either the hardware
> clock is suitable as a clocksource for general consumption, then it
> should just be used as a clock source. If it's not - e.g. because it's
> too slow to access - then it just should serve as a reference in the
> NTP style and steer the timekeeping into sync.

I think you are confusing clocks, time stamps and the system time.

System time is a single default reference source defined by POSIX in
terms of sort of UTC.

There are lots of other time sources which don't necessarily tally with
oen another and there are times you have to respect more than one of them
because you are not the master clock nor can you dictate synchronization
between the two pieces of infrastructure you span

Consider a large rock gig - your control systems for the speakers and PA
are tightly synchronized and delivering audio with very precise delays to
different amp/speaker combinations. At the same time if you are managing
effects and the like then the instrument timings for those will be coming
off another clock, which is also very precise and differently sourced.

So what we actually have is

- multiple input devices that report timestamps (the PC clock, GPS, PTP,
  time synchronized busses, synchronous ethernet, network provided reports
  etc)

- some of those inputs get turned into clocks with varying degrees of
  hardware and software processing which are consumed by various bits of
  software and drivers

- a subset of those clocks in some form are algmated into a generic
  system time. which provides a meaningful representation of general time
  to the majority of apps that simple can't care less

Apps and drivers need access to all three layers.