HP3000-L Archives

March 2001, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
RJ Keefer <[log in to unmask]>
Reply To:
RJ Keefer <[log in to unmask]>
Date:
Fri, 9 Mar 2001 14:39:50 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (43 lines)
I beg to differ.  The default settings were developed in 1973 on the Series
II and have never been changed.  they were okay on that machine.  They were
designed for a machine that was terribly I/O bound and constantly waiting
for data from disk.  The machines today and rarely, if ever, I/O bound.
They are almost always CPU or Memory starved.  The default TUNE settings
are about as bad as they can be for today's machines.

Randy Keefer

On Fri, 9 Mar 2001 11:17:04 -0800, Gavin Scott <[log in to unmask]> wrote:

>Paul writes:
>> We currently have out job queues set to decay but are considering
>> modifying some/all to oscillate.
>
>If you have a string on a violin (or similar instrument) which is properly
>tuned, then there are an infinite number of adjustments you can make, none
>of which will be an improvement.
>
>Even if your string is determined to be out of tune, you may be stuck with
>the fact that the rest of the orchestra has "tuned up" to match your
>out-of-tune string, so "fixing" it may simply introduce a more troublesome
>dissonance between the parts of the whole, and it may be better to stick
>with what you have.
>
>By all means play with the :TUNE command if you like, but keep in mind that
>the default settings are what MPE is developed and tested against, and the
>same is probably true for most applications that run on MPE.
>
>More than once have we solved all of a customers horrible performance
>problems by doing nothing more than putting the :TUNE parameters back to
>their defaults.
>
>Science tells us that there's no point in even speculating about things
>which we cannot measure, and playing with the :TUNE command is difficult
>because it is so very hard (in most cases) to determine just *what* the
>results of a change are.  Unless you can scientifically measure the effects
>of each tweak with valid reproducible experiments, it's easy to convince
>yourself that you've made things better when in fact they have actually
>gotten worse overall.
>
>G.

ATOM RSS1 RSS2