Subject: Re: options "BLINK" in config file for kernel?
To: None <email@example.com, firstname.lastname@example.org>
From: Michael C. Richardson <email@example.com>
Date: 01/20/1999 11:03:40
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Kurt" == Kurt J Lidl <firstname.lastname@example.org> writes:
>> Perhaps the reason that some have suggested the lights blink faster as
>> the load gets higher is that the current range is 1s -> 2s -> 3s -> 4s
>> and that people don't percieve phenomenon under 1Hz very well.
>> Perhaps a suggestion would be to start the blink at a faster rate at
>> load=0, like 10 blinks per second, and get slower as load goes up
Kurt> The original hack made to 386bsd (0.0), I remember well.
Kurt> It was a change to the idle loop. Basically, there was a static
Kurt> counter in the idle loop, that was incremented each time the idle
Kurt> loop was entered. Every 4 or 8 (something that is easy to divide
Kurt> via a shift :-) counts, the led output was shifted one position in
Kurt> the direction it was going, or reversed in direction, and also
Kurt> shifted a position. (Otherwise, it would have an annoying "lag" at
Kurt> the end bits in the LED display.)
Kurt> (Of course, it was entirely machine dependent, and just smacked the
Kurt> correct values into the latch on the parallel port.)
Since there seems to be so much memory of this, I extraced my old tar
file and stuck it at:
(give it until noon EST for my web server to do the CVS checkout)
Basically it did:
#endif /* CYLONLED */
hlt # wait for interrupt
[Andrew Low, email@example.com, aka firstname.lastname@example.org hacked this code with me
in... August 1992 after some pizza and a bunch of beer. Soldering drunk...]
And yes, it hacked the port directly.
The theory was that the only time one spends in the idle routine is
when the CPU has some idle time. The clock interrupt breaks the hlt
instruction HZ times per second and this provides the basic "fast" rate
of the movement.
If the CPU is busy, then the clock interrupt won't be interrupting in the
idle routine, so the LED's don't get moved. It worked well. I don't have
this code in any kernels as I don't have systems in places where I can
see them (intentially! since they make noise). I do like mouse's stuff for
Sun 3. Very distinct from the SunOS stuff... At one point very useful in
determine what OS a stack of Sun3s was running.
The problem with this routine is that if you have a system that is low
in CPU load, but *HIGH* in interrupts then the LEDs go *FASTER* even though
the CPU may not be that loaded.
:!mcr!: | Network and security consulting/contract programming
Michael Richardson | Firewalls, TCP/IP and Unix administration
ON HUMILITY: To err is human, to moo bovine.
-----BEGIN PGP SIGNATURE-----
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
-----END PGP SIGNATURE-----