> "der Mouse" <mouse@Rodents.Montreal.QC.CA> wrote:

> > Turning off the oscillator hardly seems worthwhile -- unless you have
> > an excess of spare time available  :>  I believe the devices are
> > guaranteed to operate for 10 years IN THE ABSENCE OF POWER.
>
> Sure.  But that's no reason to push it.  The 10-year lifetime is
> running out on many of them, and every drain the battery doesn't have
> is that much more life that it has before it needs attention.

I guess it's a philosophical issue... I figure if it's *going* to run out
(sooner vs. later) then I should just *plan* on replacing it -- or living
without that capability (or discarding the SPARC).  Sort of like
*knowing* the car is going to "wear out" sooner or later and not
opting to "keep it up on blocks" just to maximize the available
useful life remaining (though my *sole* 17 year old vehicle still
has less than 60,000mi on it...)

I am constantly moving machines around and often leave them
unattended for long periods of time (powered off).  And, very few have
heads on them so dragging out a keyboard/monitor just to preserve
a dying (and REPLACEABLE!) resource seems too much effort for me...

YMMV, of course.

> > Even with the oscillator disabled, the BBSRAM still draws power
>
> It does?  Maintaining static RAM contents requires approximately no
> power, just voltage - CMOS devices draw extremely low currents when no
> switching is taking place, current in the nanoamp range as I recall,
> on the order of the leakage current through the insulators that make up
> the chip packaging. :-)

You can get very low quiescent currents for CMOS SRAM.  But, they
are quiescent currents, nonetheless.  Recall that there is also some
steering
logic, comparators, etc. to tell the device that it is write protected, etc.

I figure the top hat has room for a very *small* cell.  Probably on the
order
of 30mAH (volume).  Given that this needs to run for 10 years WITH THE
CLOCK POWERED UP (though at "room temperature"), that's probably
around 0.5uA quiescent current for the clock + SRAM. (someone with a
calculator handy can do the math...  :>)  So, even *tiny*/insignificant
leakage
currents, self discharge, etc. look *big* in that ballpark...

> > and the "battery" still has self-discharge characteristics.
>
> Certainly.  The chip datasheets claim that that is the major discharge
> mode with the clock stopped, but not with the clock running; I find
> these claims plausible.
>
> > Personally, I find it annoying to have to remember to reset the clock
> > if I take a machine out of storage...
>
> I don't have a problem with that, as I always have ntpdate and ntpd
> turned on. :-)

Some of my machines don't talk to others.  And, still other machines
aren't SPARCs (yet *still* have BBSRAM/clock "issues" to address)

> > and, the battery is *still* going to fail at *some* point  (i.e. just
> > attach a whopping BIG battery to the device and forget about it...)
>
> Sure; if I had several hundred 3V battery packs to spare I might feel
> the same. :-)  (Were you the person who got tons of them for
> approximately free?  I don't recall.)

Yes.  But you would be amazed at how quickly they "disappear"!
I guess it's the equivalent of having surplus disk capacity... it doesn't
last long!!  :>  (like using 10 of them just to rebuild the battery pack in
one of the notebooks, a few dozen for cell phone battery packs, etc.)

But, you don't need to use rechargeable battery packs (like mine).
Even a battery made up of 3 AA nonrechargeable cells (i.e. "penlight
cells" from your local hardware/grocery store) will last "an eternity".
And, once you have converted the machines to a more conventional battery
backup source, you can thereafter just swap batteries at your leisure...

> > I have found that chosing MAC addresses of the form  x:x:x:a:x:!a (et
> > al.) makes it easier to program the BBSRAM -- since the checksum
> > doesn't change from one machine to the next (one less byte that has
> > to be computed!)
>
> mkpl recomputes the checksum for you...or at least it does for me.  (I

Yes, but I just hammer the bytes in manually -- from a handwritten
cheat sheet so I know each machine is set up "the same".  By picking
that octet to be something "convenient" -- e.g., 0x1, 0x2, 0x4 -- I
can quickly sort out what it's "partner" should be -- 0xFE, 0xFD,
0xFB -- without having to resort to any head scratching *or*
remembering more than one OpenBoot command...

> also think you probably mean ~a rather than !a, to be nitpicky.)