cvs commit: src/etc Makefile sensorsd.conf src/etc/defaults rc.conf src/etc/rc.d Makefile sensorsd src/lib/libc/gen sysctl.3 src/sbin/sysctl sysctl.8 sysctl.c src/share/man/man5 rc.conf.5 src/share/man/man9 Makefile sensor_attach.9 src/sys/conf files ...

[M. Warner Losh]

In message: <20071018091134.jzo7m88374ow00c8 at webmail.leidinger.net>
            Alexander Leidinger <netchild at FreeBSD.org> writes:
: Feel free to start by contributing a  
: text which states that we don't want time sensors and why.

I think he already did that.  The biggest reason is that you do not
want your kernel to run all the ntpd reference clocks.  Sure, you
could move all that code into the kernel, but that violates rule
number 1 about kernel program: don't put stuff in the kernel that
doesn't belong there.  Making them sensors necessarily means doing
this, or coming up with a way for userland to pass time deltas it
computes into the kernel to pass it back to ntpd via the sensor
interface.  That violates rule number 2 of kernel programming: don't
cross domain boundaries needlessly.  It is much easier to have all the
data in ntpd without the extra circumlocutions that the sensor
interface would force.

There are people doing high precision timing applications with FreeBSD
today.  I'm one of them.  Sensors for phase time differences are like
pounding a screw with a hammer.  Sure, it looks like it works and
often time it works well enough for the application.  But closer
inspection shows the item constructed lacks structural integrity.
There's all kinds of different nuances that need to be considered when
doing high precision real-time timing systems.  The current time
difference sensor interface in OpenBSD just doesn't cut it.

The industry standard RFC interfaces that we implement today are
sufficient.  They can handle both phase error measurements, as well as
frequency error measurements.  They can cope with simple timestamping
of events, as well as measurements of the error in time.  I've
deployed about 10 different timing systems that pace system time to a
PPS, sometimes one that isn't exactly on time or on frequency (but
which other parts of the timing system can report the error in both
those domains for).  That would be impossible with the sensor
framework as it currently stands.

So you have three strikes against you with time sensors: they force
kernel complexity or extra context switches, they artificially
segregate data and the data that they can represent is insufficiently
expressive for the demands of a real timing system.  How can one
objectively say that they are useful when they have so many problems?
They flat out can't work for anything serious, and even if you tried,
you'd find the extra complexity the design forces to be a bigger
liability than the gain from having them be shoe-horned into a regular
system.

I do timing systems for a living: as an example, my timing systems are
deployed at NIST and USNO to monitor the ensembles of clocks that go
into the UTC time scale.  This is only one of about a dozen different
systems we've sold over the years.  Phk does timing systems for a
living too: he's built timing systems used for navigation at Danish
airports.

Warner