I'm not out to start any kind of OS war here, I'm simply curious
as to alternatives.

On Fri, May 15, 2009 at 12:02 PM, Poul-Henning Kamp phk@phk.freebsd.dk wrote:

Anyone know how NetBSD stands in regard to time services?
http://www.netbsd.org/

Anyone ever look at Minix-III (Minix-I was the progenitor to Linux)?
Seems like it would be easy to make a decent time server, on
embedded hardware with it.  Past iterations of the Minix-III website
gave a "watch" as an example small embedded system it was meant to power.

http://en.wikipedia.org/wiki/MINIX_3
http://www.minix3.org/

--
http://www.wearablesmartsensors.com/
http://www.softwaresafety.net/
http://www.designer-iii.com/
http://www.unusualresearch.com/

Bob Paddock wrote:

Why do you think Minix-III would be a good candidate for a time server?

A "watch" isn't exactly a challenge to an operating system.

-Chuck Harris

On Sat, May 16, 2009 at 9:21 AM, Chuck Harris cfharris@erols.com wrote:

Minix-III is based on the microkernel approach of keeping things small and fast.
Take a look at the web site.  http://www.minix3.org/

True.  The challenge is putting the OS in the Watch,
as the Embedded System that runs it.

Bob Paddock wrote:

I spent an extensive amount of time writing system features for
Minix, back in the day, and even though it was a microkernel,
it was anything but fast.

The good thing about microkernels is they have a very small section
of "trusted" code in the kernel.  Everything else is in user space.
This has nothing to do with speed; it has to do with where the work
gets done.  Ultimately the work has to be done, and that is what causes
bloat and slow operation.  In microkernel systems, the kernel operates
as a task starter, arbiter, allocator of system resources and messaging
system.  Everything is done by passing messages.  The problem with the
microkernel system is your messaging system has to copy tons of data
to do even trivial things.  Another problem is the kernel has to read
the message, interpret what the message means, and check it for validity
before it can do the bidding of the user level task.

In academia, everyone talks of microkernel systems as being the
wave of the future, but in the real world, things end up more in
the monolithic kernel model... linux and BSD are both monolithic
kernels.

Nobody with any sense would even try.

A watch is such a closed system that it is easy to verify all
parts of it, and there is no need for the frills an OS
provides.

-Chuck Harris

In message 4A0EBDEE.2020703@erols.com, Chuck Harris writes:

Well, no.

But figuring out correct handling of time is a challenge for operating
system programmers.

I have no idea how the timing code is in minix3, but I do know
how much time it took me and subsequently Warner to get it right
and good in FreeBSD.

I'll still claim that FreeBSD is a generation ahead of all other
operating systems with respect to timekeeping, if for no other
reason, because FreeBSD is the only OS that truly splits the
nanosecond.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Poul-Henning Kamp wrote:

Very true...

Given that minix was written by a CS professor who has no apparent
experience with real time operations, and has never been heard from
on timenuts, I would guess it will be primitive.

I don't believe that will be happening in a message passing microkernel
(like minix) anytime soon... unless you build all of the timekeeping
software into the kernel, and then you are in the process of becoming
a monolithic kernel ;-)

-Chuck Harris

On 5/16/09 8:04 AM, "Chuck Harris" cfharris@erols.com wrote:

I think there is more use of microkernels (eCos, RTEMS, Erlang, etc.) in the
embedded world. The environment is more constrained, so reducing the
footprint is useful.

On 5/16/09 1:43 PM, "Chuck Harris" cfharris@erols.com wrote:

Or, do what I'm doing for a software radio that uses RTEMS, do the critical
timing stuff in hardware, and the software just manages the hardware.

In message 4A0F2581.7000303@erols.com, Chuck Harris writes:

Well, this brings us into a philosophical area.

If a piece of code calls a function to figure out what time it is,
the tacit assumption is that the function takes zero time to execute
and returns the timestamp of the time where it didn't take any time.

In practice, the call will always occupy some duration of time, and
the timestamp returned represents some instant during that interval.

Depending on the function called, and the CPU hardware we execute
it on, the timestamp returned may have more or less jitter relative
to the call instruction and the first instrucation executed upon
return.

I call this jitter the "software-jitter" because it has nothing to
do with the time keeping hardware, it is jitter introduced because
we operate in software.

In addition to the software jitte, we have whatever jitter the
function runs into, trying to actually produce the timestamp: Bus
contentions, hardware locking, page faults etc. etc.

On the other side, if a piece of hardware yanks a signal line to
record a timestamp, we can reasonably expect the timestamp will
be the exact time of the signals reception +/-1 count on whatever
hardware counter is used to keep track of time.

These observations hold in general, even for the case where you
have no operating system of any kind.

If you look at this prism with your MACH-coloured glasses, what you
see is that the access to the timekeeping hardware counter is likely
to be restricted to one semi-priviledged process.  Otherwise,
why bother with microkernels in the first place ?

It follows that all software calls to get a timestamp consequently
becomes IPC calls.

And we have 30 years experience telling us, that IPC calls are
even more smeared out over time than direct calls and therefore
the software jitter becomes worse.

But other than that, and that is bad enough because of the scheduling
latency/jitter typically present, there are no ill effects from
running on a microkernel.

If you feed your PPS signal in and do hardware timestamps like we
FreeBSD's timecounters allows you to, for instance on the Soekris
net4501[1], then your basic clock can be precise, but your microkernel
will only allow your software to read fuzzy timestamps from it.

If you hook the PPS signal to an interrupt line, and timestamp it
in software, then your basic clock can never be precise, because
your PPS timestamps are fuzzed by the microkernel.

Poul-Henning

[1] This is why I say that FreeBSD is a generation ahead, I have
yet to see any other operating system support PPS-API on hardware
captured signals.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.