ksmith@jarthur.claremont.edu (Karl J. Smith) (03/27/91)
SUMMARY: If you think your 48 is running at 1/2 speed, you could
be right. An ON-A-F reset can fix it.
At first I thought I was just imagining things; my 48 seemed much slower than
normal. When dividing two numbers on the stack, there was a small but
noticeable pause. That didn't seem quite right, but I wasn't sure that there
was anything really wrong, since there was no quantitative information to
point to and say 'Ahah!' It was just naked-eye perception.
I ignored it for a few days, and decided to look into the matter later.
I assumed that if I did a backup then an ON-A-F reset, then a restore,
the problem (if there really was one, and I wasn't just imagining things)
would go away.
Today during lunch, I was playing around with Mark Adler's TIMR benchmark
program, which has a harcoded value of 86 ticks, and a note that "I'll leave
how to figure out the "86 -" as an exercise for the reader." I'd figured
it out once before (it's not too hard) but was bored so decided to check
to make sure I knew how to do it.
Here's the original TIMR program (posted Wed Apr 11 19:00:31 PDT 1990):
%%HP: T(3)A(R)F(.);
@ TIMR crc #D3C0h length 74
\\<<
MEM DROP @ do garbage collection
TICKS \-> $$$ \<< @ save current tick count
EVAL @ run program with stack contents
TICKS @ get tick count when done
$$$ - B\->R @ compute ticks elapsed
86 - @ adjust for time to assign $$$ and do TICKS
8192 / @ convert to seconds
\>>
\>>
which I modified into this program, SMART, which should produce 86 (or
something close) on the stack:
%%HP: T(3)A(R)F(.);
\\<<
MEM DROP @ do garbage collection
TICKS \-> $$$ \<< @ save current tick count
@ no EVAL here this time
TICKS @ get tick count when done
$$$ - B\->R @ compute ticks elapsed
@ with no EVAL, the actual elapsed
@ time (86) is just the time it takes to assign $$$ and get here
@ if we do nothing at this point, we'll have 86 on the stack
\>>
\>>
I had run this before, and got '86' as expected.
Today, I got 188. 188? Huh? I tried again. 188.
Clear the stack. Try again. 187? This makes no sense. Oh wait! Things
must really be running slower than normal. I'm not imagining it. And it
runs faster on an empty stack.
I tried various things short of ON-A-F, and still got 188 on the stack as a
result. I archived to my Mac, did the ON-A-F reset, then reloaded the
backup, I tried some division...it was faster to the naked eye. "Ahah!"
I thought. Let's try the SMART again....I got 86. Tetris runs faster now.
Everything runs faster now. Much much better.
What caused the problem in the first place?
Some guesses:
1) Cosmic Rays? (doubt it)
2) Lack of RAM? (I have a 128K merged ramcard, with 50K free, so doubt it)
3) Running older tetris versions with STWS not set to 64? (maybe :)
4) Running nrts 0.5 and crashing a lot? (maybe :)
What exactly was going on? I guess maybe memory was weirdly corrupted
somehow, so that it slowed things down by a factor of 2 (188/86). I don't
really know. Does anyone else have a good guess? I haven't yet tried
to reproduce this (I want to run *FASTER*, not slower :), but if anyone
else can reproduce it, I'd be interested in knowing how. Rebooting
from time to time (to flush out gremlins) doesn't seem like such a bad
idea now.
Things to look for if you're trying to reproduce this: If you keep running
the 86 benchmark program (I called mine SMART, since agent 86 was on
Nickelodeon all last week) you'll notice that as the stack gets bigger, the
return value gets bigger, too. If you do this long enough, you can probably
make it return 188 eventually. I was getting 188 with an empty stack, but
who knows what kind of "invisible" junk a crashing ML prgram can dump into
memory? Alternatively, it could be some kind of memory leak bug. The last
time I did an ON-A-F reset before today was some time in january, so that
would be enough for a slow leak to build up over time. (Sorry, I forgot to
check free mem before and after the reset. :( ) Another guess is that things
were internally fragmented enough that it slowed down. Rebooting and
restoring de-fragmented the mess. :) As I said before, these are all just
guesses. I think I'll choose to believe in gremlins. :)
Specifics:
HP48sx, version E
Donnelly's 48 Toolkit libs in port 0
Sparcom PIM in port 0
HP Solve Equation Library ROM in port 2
128K RAM card (HP) in port 1
After the reset, I got the right result (86) with or without any
of the libraries or ROM loaded.
-Karl Smith ksmith@jarthur.claremont.edubill@thd.tv.tek.com (William K. McFadden) (04/02/91)
In article <11402@jarthur.Claremont.EDU> ksmith@jarthur.claremont.edu (Karl J. Smith) writes:
->
->SUMMARY: If you think your 48 is running at 1/2 speed, you could
->be right. An ON-A-F reset can fix it.
->
->At first I thought I was just imagining things; my 48 seemed much slower than
->normal. When dividing two numbers on the stack, there was a small but
->noticeable pause. That didn't seem quite right, but I wasn't sure that there
->was anything really wrong, since there was no quantitative information to
->point to and say 'Ahah!' It was just naked-eye perception.
->
->I ignored it for a few days, and decided to look into the matter later.
->I assumed that if I did a backup then an ON-A-F reset, then a restore,
->the problem (if there really was one, and I wasn't just imagining things)
->would go away.
I noticed mine doing the same thing. I just thought it was because I
didn't have much free memory, but an ON-A-F did indeed restore it to
full speed. It's been okay ever since (a couple of weeks). My 48 is a
rev. E and has about 3K of free memory.
Has anybody else seen this?
--
Bill McFadden Tektronix, Inc. P.O. Box 500 MS 58-639 Beaverton, OR 97077
bill@videovax.tv.tek.com, {hplabs,uw-beaver,decvax}!tektronix!videovax!bill
Phone: (503) 627-6920 "SCUD: Shoots Crooked, Usually Destroyed"