RAC Consulting Sponsor Message

Net.digest summarizes helpful technical discussions on the HP 3000 Internet newsgroup and 3000-L mailing list. Advice here is offered on a best-effort, Good Samaritan basis. Test these concepts for yourself before applying them to your HP 3000s.

Edited by John Burke

A Walk on the Moon

Several months ago the movie “A Walk on the Moon” hit US theaters with a resounding thud. My wife and I enjoyed it immensely and were speculating recently about why it had not done better at the box office. We concluded it was too narrowly focused on a moment and place in time for general interest. You see, it was not the story we responded to, but rather the time and places and our memories of that time and those places.

The movie is set in the summer of 1969. The title makes reference to the seminal event of the last half of the 20th century; but it has nothing directly to do with Neil Armstrong’s moonwalk other than as a vehicle to establish a time. Nor does it have anything to do, really, with the Woodstock festival or the Catskills’ resorts and camps, other than to set a place. The movie is, in fact, a simple, not very original story about the re-discovery of a love gone stale. However, for those of us of a certain age, the movie clearly evokes a time and places that made us feel more intensely about this otherwise ordinary story and movie. In fact, the atmosphere overwhelmed the story — but only if that time and those places meant something to you.

Clearly, that time and those places mean something to many of the contributors to 3000-L. Over the last month we were treated to dozens of great reminiscences about the official Walk on the Moon as its 30th anniversary was observed. Further evidence, I might add, to bolster my comments a few months ago about the graying of 3000-L.

There were other threads about telephone area codes, Interex bylaws, user licensing, more on SETI at home and more DDS horror stories. And there was even a thread on “trade dress,” a concept Apple Computer is counting on for its iMac. You can look it up.

The big news of the month was the announcement that Mark Bixby — who did more than anyone outside HP (and possibly more than anyone inside HP) to drag CSY and the HP 3000 into the Internet age — is going to work for HP. I will leave it to future historians to determine if he has gone over to the Dark Side. I wish him well and hope that he continues his presence on 3000-L.

Even with all this, there were still many hundreds of postings meriting serious consideration. My usual practice is to present several threads. However, this month there was one thread so compelling (and long), that the rest of the column will be devoted to it.

Why do I always end up in the longest queue?

One of the more brilliant design elements of MPE, dating back to its earliest days, is the job scheduler. We’ve all heard about the C, D and E queues. Maybe even the A and B queues. But how many can explain exactly how they work? A question:

“I had a problem the other day in which none of my jobs (submitted in the D queue) were advancing at all. The users’ sessions (in the C queue) didn’t report any drop in performance. If a job was ‘promoted’ to the ‘C’ queue, it ran through okay.

“Does anyone have a not-too-technical explanation of how the queues work together, and possibly an explanation for what was happening? Are there any configuration changes that could be made to give my jobs an increased slice of the action without slowing down the users’ sessions too much (i.e. to the extent that they phone me up to complain)? Also, at the end of the day the users logged off and the previously static jobs in the ‘D’ queue jumped back into life. Is this relevant?”

Two of the more frequent, knowledgeable and literate contributors to 3000-L, Jeff Kell and Wirt Atmar, wrote extensively in response. Some of what they wrote follows (edited for length):

First, from Jeff Kell, master of 3000-L and Chairman of SIG-MPE:

This can’t be explained without a basic “reference,” the best one being the tail end of a :SHOWQ listing. The default values are:

The MPE Dispatcher handles process scheduling. Every process in the system is classified (simplistically) into either “DORMANT” or “RUNNING” columns in :SHOWQ output. Dormant processes are those which are waiting on something (terminal read, disc I/O, database lock, etc.) while those RUNNING are ready to execute. They may not all actually be “running” — you can only be running as many processes at the same time as you have processors. But the remaining processes in the running list are “eligible to run.”

Processes that are running will continue to run until they do something that makes them wait (issue a terminal read, or a disk I/O, etc); or, they exceed their “quantum” of CPU time, in which case the dispatcher takes over and interrupts them.

The second case does not apply to system processes scheduled linearly and some priv-mode exceptions, but let’s keep this simple.

When the CPU is “available” through the conditions above, the dispatcher must decide which process to launch next. If there are no processes in the running list, it simply suspends until some process is ready to go. Otherwise, the process with the lowest priority number is selected.

Now, on to how the “numbers” are assigned. From the :SHOWQ trailer you can see that CQ covers 152-200, DQ 202-238, and EQ 240-253. So, in answer to your original question, as long as there is a process in the CQ ready to run nothing in the DQ will ever be selected, as there is no overlap. One or more of your CQ processes must be CPU intensive to dominate the CPU like that; generally there are some cycles available to the lower queues.

What determines the numbers within the queues? Processes start at the base priority. If they exceed their quantum before otherwise giving up the CPU, their priority number is incremented. This process continues until it reaches the “limit” value. Certain events can return the priority to the base value - such as completion of a terminal read. However, if the process is compute bound, it may never rise back in priority. This is the default behavior of the “DECAY” algorithm.

An alternative to DECAY is OSCILLATE, which, as the name implies, will pop you back up to the base after you reach the limit.

Now, armed with this background, how do you solve your problem? There are probably dozens or more different opinions, depending on who you ask, but in general:

• If the DQ is getting nothing, you must make it at least overlap the CQ by raising the DQ base above the CQ limit.

• If the DQ processes get pushed below the CQ base and hang after they get started, you may need to raise the DQ limit or lower the CQ limit so that they have equal contention.

• If the DQ processes drop to the base and stay there, resulting in less-than-desirable performance from the DQ, you might consider changing the DQ to OSCILLATE.

This is just a simplified overview of the major players in process scheduling. It’s a complicated issue when you get down to details.

Wirt Atmar, developer of QueryCalc, followed with two postings. The first, an explanation of queues using a bank and tellers as the driving analogy, is what he uses in training classes. It is way too long to publish here, even though Wirt calls it “albeit brief.” But if you are looking for something a little less technical, I suggest you look it up in the 3000-L archives.

The second posting follows, minimally edited:

The two central goals of a scheduler are (i) fairness and (ii) a desire to never let the CPU sit idle, to drive CPU utilization to 100 percent, if at all possible.

These are, however, exactly the same goals that drive the design of an industrial factory or a bank or an airline. The mathematics that are used to describe CPU schedulers come directly from the operations research people in industrial engineering. There is no significant difference between the various scenarios, other than the speed at which their respective processes are dispatched and executed.

If you read my general explanation (it’s not as silly as it may sound and it doesn’t hurt to think of these things in slow motion), and then re-read Jeff Kell’s, and then read these two Web pages:

www.sct.edu/cs/cla sses/cs503/ops3.htm

http://moon base.wwc.edu/~aabyan/352/Scheduling.html.

You will have a very good idea of how processes are queued, scheduled, and executed on the HP 3000.

A couple of notes that may make reading the Web pages easier: A first-come/first-served (FCFS) queue mentioned in these pages is the same thing as the “linear queue” on the HP 3000, a non-preemptive queue that is reserved primarily for system processes. A “round-robin” queue is almost the same thing as the “circular queues” of the HP 3000’s user processes, with the significant exception that a process that stays within a circular queue on an HP 3000 “decays” in priority every time it makes a trip through the queue. Although “flat” round-robin queues are often described as the oldest, simplest and fairest of the queuing structures, the addition of priority decay makes the HP 3000’s queuing structure even more fair yet again — and more efficient.

It is easy to demonstrate (an academic way of saying, “easy to prove”) that a “shortest job first” (SJF) scheduler is always the most efficient. The problem is, in real life, you have no way of knowing a priori which of the several processes that are currently in a queue is the shortest and which is the longest. The decay algorithm solves this problem for you, adaptively. If a process repeats over and over again in the C queue, its priority drops with each pass through the queue, ultimately to the bottom limit of the C queue. While new processes that have just entered the queue are normally put at the end of the queue (and I presume they are done that way on the HP 3000), their position doesn’t really matter. At the end of each time slice, the scheduler reassesses its process list. The circular queues on the HP 3000 are not “flat.” Newly arriving processes’ priorities are set so high that the dispatcher will always cause them to execute first, maintaining the illusion to the casual user that he or she has the machine all to himself.

Someone running a massive report in the C queue will have no more effect on the terminal users than would someone running the same report in the D queue. Indeed, if you look, the HP-fresh-from-the-factory settings (see above) have the limit of the C queue set just slightly higher than the D queue. Because the factory settings don’t have the queues overlapping, a massive C user will effectively shut down the D queue jobs if the heavy C user can get his data into main memory and make his process CPU-bound. Nevertheless, he won’t have any more impact on the light C queue users than if he were in D queue.

If you keep your scheduler tuned the way that HP has it set by default, doing report development in the C queue is all right, so long as there aren’t too many people doing it. But you do want to get your IMPORTANT production reports put into batch as soon as possible and run in the D queue — and get your background, non-time-critical, even more massive reports put into the E-queue.

Doing this creates an extremely simple arrangement, where you help the HP 3000 to put the shortest jobs first by placing them into the higher queues, keeping overall system processing optimal.

To adjust your HP 3000’s priority structure to allow all queues to move a bit, preventing any one user from shutting down all lower queues, move the bottom limit of the C queue somewhere into the middle of the D’s priority numbers and leave the CQ algorithm on “decay.” The D queue numbers (base and limit) would be left where they are, but the algorithm would be changed to “oscillate.” The same should be done for the E queue. Its algorithm should also be set to “oscillate” and its upper base raised to perhaps the same as the base of the D queue, but its bottom limit left where HP set it.

In this manner, the C queue “hog” will automatically begin to start sharing his time with the D and E queue jobs. In fact, depending on where you set the bottom of the C queue (at 50 percent up from the bottom of the DQ, 80 percent up, 90 percent up, etc.), the C queue heavy user could actually get less time than that of the D queue users. This is the part that requires tuning and experimentation.

How well this works for you will depend heavily on what kind of processes you’re putting into the various queues. I generally recommend that our business users, who quite often have no DP staff, leave the queuing priorities that HP has set. And pay more attention to the proper assignment of processes to their appropriate queues — think of a bank with one teller in it.