HP3000-L Archives

January 1997, Week 4

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:
Ken Kirby <[log in to unmask]>
Reply To:
Date:
Thu, 23 Jan 1997 12:47:59 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (49 lines)
Tom Kaminski wrote:
>
> We just upgraded from 4.0 to 5.5.  Everything has slowed down - sessions
> and batch.  Does anyone know any general things we could do to bring us
> back up to speed?
>
> We have 96MB of RAM (on 32MB boards) and plenty of disk space (5,000,000
> sectors).  Drives include 670MB HP-IB drives, 571MB (Eagle) drives, and
> some new 2GB SCSI stuff.
>
> Our queues look like this:
>
>                     ------QUANTUM-------
> QUEUE  BASE  LIMIT  MIN    MAX    ACTUAL  BOOST  TIMESLICE
> -----  ----  -----  ---    ---    ------  -----  ---------
>  CQ    152    240   1      2000   216     DECAY    200
>  DQ    240    250   2000   2000   2000    OSC      200
>  EQ    250    250   2000   2000   2000    DECAY    200
>
> I'd appreciate any advice anyone could provide.
>
> Tom Kaminski
> Career Systems Development Corp.
> Rochester, NY
________________________________________________________________________

We had some problems with certain processes choking our system shortly
after upgrading from 4.0 to 5.0. As a result, batch queues backed up,
and when I :TUNEd the system to punish long-running CQ processes, folks
began to complain about bad response time.

After identifying the culprits and looking for similarities, we noticed
that all the offending programs were running in CM. A call to the HP
response center confirmed that there are indeed performance problems
associated with running CM programs on 5.0 and up. Their advice was that
CM is a no-no, and to recompile in NM or use Octcomp (so what about
FCOPY, HP?).

The problem appears to be in mode switching. We have several old CM
programs still using CM KSAM (long story), and they do not seem to pose
any problems. The killer programs were having to switch between CM and
NM mode (e.g. a CM program calling TurboImage intrinsics).

Don't know if this is your problem, but it might be something to look at
if you have some CM code lurking about.

--Ken Kirby
  Vanderbilt University

ATOM RSS1 RSS2