Every now and then, I get to thinking about some of the semi-funny things
that have happened to me in the past. I thought that it might be
interesting to write about them. Some of your might be able to relate to
these experiences.
Perhaps one of the more interesting in the league of funny/ridiculous
happened during a benchmarking exercise while I was at Digital Equipment.
I worked in the Adelaide (in Australia) office of Digital equipment, and we
were responsible for the Darwin office (almost 3000 miles to the north).
The Darwin office had sold a second-hand DEC 3000/400 (ie, an ex-demo
machine) to a customer to run an Ingres based student records system on.
The system was developed in Adelaide on an HP box (a 715 or a 735 or
something like that).
The Adelaide crowd did not like the idea of supporting the application on
two platforms, so they pushed back on the customer, who did a benchmark on
the HP box and wanted us to at least meet the performance of the HP box.
If we couldn't (and they expected we would have problems, because those HP
boxes were supposed to run like a cut snake, especially in the floating
point area) then there were hints that we would be asked to take the
machine back.
The customer did the benchmark the 3000/400, and it fell short of the mark.
Since I had done a number of benchmarks before, I was given the job of
improving the results.
At first I focussed on improving the IO performance of a 3000/400 for the
job. I played around with striping the data across multiple disks, and
tried a RAID controller, but nothing would do the job (and I should have
guessed that RAID would not help).
I then looked at memory. I checked with the customer and found that the HP
box had 144MB of main memory (128MB + 16MB on the main board). A-ha! said I.
However, I had a problem. With the memory boards I had, the 3000/400 could
only fit 128MB of memory, and that is what I benchmarked with. This was
because the 3000/400 and the 3000/500 took memory in banks of four boards.
One bank of 16MB boards was 64MB. Two banks of 64MB was 128MB and the
3000/400 was full. However, a 3000/500 could take four banks of 64MB (or
four banks of 256M, allowing for 1GB, which was a lot in those days in a
machine that could be a workstation). So, we found a 3000/500 at a
customer site, which had 128MB in it, and used some cards from the 3000/400
to take it up to 192MB of memory.
Now, the 3000/400 and the 3000/500 were twins, in the same way that Arnold
Schwartzenager and Danny DeVito are. There was much commonality between
them, and in particular, they could use the same memory boards. But, read
on, because there was more that could be exchanged between them.
Anyway, I installed Ingres on this DEC 3000/500 and started doing the
benchmark. The customer ran the benchmark five times, discarded the first
and last result, and averaged the other three. The benchmark was
essentially a report run across all 110,000 students in the TAFE system in
South Australia (and considering that the Northern Territory--the state
containing Darwin--only had 110,000 or so people, the benchmark was
ridiculous).
So, there I was, running the benchmark with 192MB of main memory. I ran
the first run, and about three quarters through, the machine became very
quiet. The disks had stopped rattling. This seemed strange. The first
run was a bit faster this time than ever before. On the second and
subsequent runs the machine ran very quiet, and very fast. It was then
that I realized what had happened, and almost fell on the floor laughing.
The database indices had become memory resident, and the benchmark only had
to go to disk (relatively infrequently) for actual data pages. We've got HP
beat, I thought.
But I still had one more hurdle. I could only fit 128MB of memory in the
customer's machine, and I needed 192MB! So I hatched this crazy plan. We
only had to prove that the DEC 3000/400 could do as well as the HP, and I
could only do it with the resources available. I was not allowed to take
memory from logistics in Sydney for such a benchmark, as I would need a
128MB set (four by 32MB). No one in Digital wanted to pay for the 128MB
module for a benchmark on the sale of a second-hand 3000/400!
Memory in the 3000/400 and 3000/500 came in memory boards, SIMS I recall,
that plugged into memory carriers, that plugged into the system board.
There were two memory carriers in the 3000/400 and 3000/500, and you put
SIMS in each side, giving you a total of 4 SIMS per bank. The only
difference between the 3000/400 and the 3000/500 was that those in the
3000/500 were twice as high as those in the 3000/400. So, I could fit more
memory into a 3000/400 by leaving the skins off of the 3000/400, leaving
the disk shelf (that normally covered the memory in a 3000/400) propped up,
and installing the memory carriers from a 3000/500 in the machine. I
tested this in the Adelaide office, and it worked.
I then went to Darwin, took a 3000/500 from the Darwin office and went to
the customer's site. In their computer room, I built this strange looking
machine, with its skins off, and its disk shelf propped up, and 192MB of
memory in it. I then ran the benchmark, and achieved the desired result.
It was one of the most ridiculous benchmarks I have run.
The customer kept the machine they had purchased because we had achieved
the objective, albeit with a bit more memory than the HP box. DEC OSF/1
(as it was in those days) was a memory hog, as is Digital UNIX, compared
with other boxes. I still marvel at the difference between the less than
500kB kernel on one customer's production Linux machine versus the 9-11 MB
Digital UNIX kernels I have seen.
We sometimes do strange things because the customer wants it that way.
Well, if you have got to the end of this crazy diatribe, you have done
well. Can you empathize with me? Have you done something as crazy with
machines? If so, send me your stories. If I collect enough of them (and I
have more myself), I may publish them on a web page somewhere. All
contributions will be acknowledged.
Regards
-------
Richard Sharpe, sharpe_at_ns.aus.com, NIC-Handle:RJS96
NS Computer Software and Services P/L,
Ph: +61-8-8281-0063, FAX: +61-8-8250-2080,
Samba, Linux, Apache, Digital UNIX, AIX, Netscape, Stronghold, C, ...
Received on Sun Jul 26 1998 - 13:14:14 NZST