Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Oct 95 00:07 WET DST
From:      uhclem%nemesis@fw.ast.com (Frank Durda IV)
To:        wollman@lcs.mit.edu, joerg_wunsch@uriah.heep.sax.de, freebsd-current@FreeBSD.org
Subject:   Re: clock running faster?
Message-ID:  <m0t6W9B-000IxkC@nemesis.lonestar.org>

next in thread | raw e-mail | index | archive | help
[0]As Bruce Evans wrote:
[0]The changes have the effect of making the Pentium clock the reference.

[1]On Thu, 19 Oct 1995 23:57:17 +0100 (MET), J Wunsch <j@uriah.heep.sax.de>
[1]said:
[1]I don't think this has been a good idea.

[2]"Garrett A. Wollman" <wollman@lcs.mit.edu> then wrote:
[2]Please explain your reason for believing this, keeping in mind that a
[2]similar technique was used on MicroVAXen in 4.3 (except using
[2]microtime() rather than a purpose-built function).

Yes, and the VAX 11/780 did this too.  But all you had to do was walk
up to the console, halt the KL (or whatever the main processor
designation was), and type SET CLOCK FAST, and then let the processor
continue.  Now the 780 is executing instructions about 20% faster than
normal, but guess what?  Despite having that nice TOD hardware down there,
the BSD 4.x system wall time clocks is now running fast, gaining a lot per
hour.  (VMS used the TOD hardware so this didn't happen when running VMS.)

We used to use this extra burst of speed when we really needed some
big system build to get done faster.  Just halt, change speeds and
resume, no need to reboot BSD!  Just a slight pause.  Of course, everybody
would complain about the uptime and TOD clocks not agreeing with wall
clocks or with each other so we didn't do it very often.

Granted the SET CLOCK FAST command mechanism on the VAX was meant to be
used by CEs to detect flaky components that were on the edge of failing,
but guess what?  Modern PC makers "cheat" on the processor clock too,
and don't always advertise the fact.

In fact, in this day of one-main-logic-board-fits-all, the processor clock
is probably generated by a clock synth chip, that may be allowed to
be as much as 5% fast or slow on a given machine AND on a given boot cycle,
as the synth speed always starts up at a very slow speed (8 to 20MHz).
Crystals are usually a lot tighter on deviation from the marked frequencu,
and they hold the same value from one boot to the next, but crystals are
becoming far less common on motherboards.

Further, I can name several major PC vendors who deliberately program
"high" settings into the synth chips so that their machines will perform
better in benchmarks, and the systems are sold with these faster values.
These values are loaded by the BIOS after POST is complete.  Since Intel
(and other processor makers) have tested their components clocked
at up to 10% faster than the listed value, this 5% increase isn't a
problem, particularly if the cooling of the processor is under control.
The chip makers don't like it when computer makers do this, and the chip
makers will use it an excuse if the computer manufacturer runs into
reliability trouble, but this rarely happens.

I can even name a couple of Triton-based Intel-built boards out there
in the market right now where this trick is done so that Vendor A can say
their system is faster than Vendor P, even though they both have the exact
same Intel motherboard inside.

But this "bit of extra speed" can really mess up time-keeping that
is based on processor speed, particularly if events skew the routine
or routines that estimate processor speed.  This gets worse if the
timing routine tries to rationalize its results to "known" processor
speeds, such as 33, 50, 66, 75, 90, 100, 120, 133, etc.  If the number
comes up as 92, the code might simply report 90, and do all the clock
math based on 90, which will be wrong.  But there are other
things that can mess up the estimate.

Note that like VMS, DOS and Windows don't do this - they use the system
timers and the CMOS clock for TOD duties.

Now I will be the first to admit that the 14.31818MHz (4 x NTSC color burst
frequency - what a choice) clock that the traditional PC system clock is
based from (although a multiple of this is used frequently in newer machines)
isn't that easy to work with, at least it is consistent on all PCs, and
even a 200ppm error in a given crystal will still be a pretty small drift
in the system clock, once you get down to ~18.2/sec or ~100/sec or whatever
you have it programmed to.  (This clock has to be reasonably accurate or
else RS-232 operations will suffer from bit errors.)

If a processor "tight loop" with interrupts disabled is used to determine
the processor clock speed (I suspect this is the case), such a routine can
be fooled by the methods some chipsets use for performing refresh, which
instead of being spaced at nice even intervals like was done years ago,
now the refresh cycles may come in groups, or are eliminated based on recent
Read/Write accesses.  These so-called "Smart" refresh managers will
completely fool a timing routine, producing one set of values on one
motherboard brand machine and a different set of values on a different
motherboard model.   The results can also vary depending on what memory
locations the loop resides in.

Keep in mind that nearly 100% of the DRAM out there simply requires that
each of the 256 rows be refreshed once every 16msec.   There is
nothing that says the processor must take that 16msec and divide it by
256, and then refresh one row at even intervals.  All 256 rows can
be done at once, or at irregular intervals.

Since a refresh cycle is simply an incomplete memory read cycle
(RAS but no CAS), the act of fetching instructions, reading and
writing memory all effectively perform refreshes, but not in a uniform
fashion.  Old systems made no attempt to take advantage of the fact
the processor had accessed given memory rows recently, but many bus control
chipsets made since 1990 do, keeping "decay" counters that alert it to
when a row needs refreshing, and these counter are reset by the processor
accessing that row as part of one of its memory operations, a DMA cycle,
or a genuine refresh cycle.

This somewhat unpredictable refresh activity could probably explain 
systems that people boot ten times get ten different processor speed
ratings for code that should be running "uninterruptable".  

This type of computation error could be reduced by greatly increasing the
duration of the timing test, but that may not be desirable.

Even if you argue that the complete timing test should end up being
executed from the processor cache and pipeline, since the full internal
workings of the Pentium (or its Pro buddy) are not public, we can't be
sure that residual memory writes from earlier operations aren't performed
during the actual timing test, or that memory reads for pipeline and
cache fills aren't occurring during the test.  There isn't any good
way to control this without a full internal knowledge of how and
when the processor tries to access memory, and what impact DMA
and refresh bus grants have on the processor when it is running
code already in the processor.  And of course, not everybody has Pentiums,
and no one except knows if all versions of the Pentium behave the
same in this area.

Then you have the situation where the CPU clock is not symmetrical and/or
a multiple of the ISA bus clock, or of the clock that is used within
the ISA chipset for things like timers, interrupt controllers, etc.
This difference in timing can cause variable length of wait states to appear
when attempting to access hardware registers that are not actually
running at the full 66, 90 or whatever MHz speed the CPU is running at.
These speed differences can also induce variable latencies in reporting
interrupts to the CPU, particularly in systems that serialize IRQs to
save on pins on the package.


Bottom line, I also agree that estimating CPU speed and using that as
the TOD clock is a bad idea.  There are just too many variables to
make this work well on all of the systems out there.


						(Ask before SGMLing)
Frank Durda IV <uhclem@nemesis.lonestar.org>|"The Knights who say "LETNi"
or uhclem%nemesis@fw.ast.com (Fastest Route)| demand...  A SEGMENT REGISTER!!!"
...letni!rwsys!nemesis!uhclem               |"A what?"
...decvax!fw.ast.com!nemesis!uhclem         |"LETNi! LETNi! LETNi!"  - 1983
Microsoft, you can add this to your Developer Network CD in exchange for a
three-year Level 2 license. 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0t6W9B-000IxkC>