[Python-Dev] (time) PEP 418 glossary V2

[Nick Coghlan]

I like the updated glossary - very good summary of the relevant
terminology and common points of confusion. One minor gripe below (and
it *is* minor, despite the amount of text explaining my point of
view...)

On Tue, Apr 24, 2012 at 11:58 AM, Jim Jewett <jimjjewett at gmail.com> wrote:
> Real Time
> ---------
>
> Time in the real world.  This differs from `Civil time`_ in that it is
> not `Adjusted`_, but they should otherwise advance in lockstep.
>
> It is not related to the "real time" of "Real Time [Operating]
> Systems".  It is sometimes called "wall clock time" to avoid that
> ambiguity; unfortunately, that introduces different ambiguities.

"Not related" is simply not true, as this is the exact meaning of
"Real Time" in the term "Real Time Operating System". In the PEP's
terms, a Real Time OS is simply an operating system specifically
designed to allow developers to meet deadlines expressed as the
maximum permitted Real Time Duration between an event occurring and
the system responding to that event.

The power an RTOS gives you over an ordinary OS is sufficiently low
level control over the scheduler (if there's even an entity worth of
the name "scheduler" at all) such that you can *demonstrably* meet
hard real time deadlines (down to a certain lower limit, generally
constrained by hardware). It's a pain to program that way though (and
adequately demonstrating correctness gets harder as the code gets more
complicated), so you often want to use a dedicated processor for the
RTOS bits and a separate processor (with an ordinary OS) for
everything else. (There's a good explanation of many of these
concepts, include separating the hard realtime parts from everything
else, in the Giant Robots of Doom talk from PyCon AU 2010:
http://pyvideo.org/video/481/pyconau-2010--hard-real-time-python--or--giant-ro)

One interesting aspect of using a normal OS is that you can *never*
reliably read a Real Time clock in user level code - the scheduler
doesn't provide adequate guarantees of responsiveness, so there's
always going to be some scheduling jitter in the results. This
generally doesn't matter for measuring durations within a machine
(since the jitter will, with a sufficiently large number of samples,
cancel out between the two measurements), but can be a problem for
absolute time measurements that are intended to be compared with high
precision across different machines.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia