| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 660.1 | | MU::PORTER | gonzo engineering | Mon Apr 24 1989 14:56 | 15 |
| I'm curious: why would anyone use a UAF CPU limit on a single-user system
such as a workstation? On a multiuser system, it's good to encourage users
to be frugal in their use of CPU cycles, so there's more for other people
to use. On a single-user system, any CPU that the single user doesn't use
is wasted.
Likewise, on a single-user system, what's the sense in charging for
the CPU usage? The user has the whole system tied up, regardless of
whether the CPU is churning away or not, so 'connect time' seems to
be a more appropriate charge basis.
I didn't mean this note to be dismissive of your problem -- but I
was rather curious as to why they were doing things this way. Maybe
I've worked with "free computing" for too long!
|
| 660.2 | | LESLIE::LESLIE | There is no final frontier. | Mon Apr 24 1989 18:42 | 4 |
| It's the cursor blinking! Look back at #307.
Andy
|
| 660.3 | free computes IS the problem | CSC32::J_FELDMAN | cixelsyd TON ma I | Mon Apr 24 1989 19:16 | 16 |
| The problem is that there are places that charge departments for the
cpu time that their members use. At some sites, it would not be
uncommon to have workstations available for general use (like schools)
and so a system manager might wish to limit that use. CPU usage is the
only way to do that.
The other scenario is even if a user were dedicated to a single system,
the system manager might wish to do cluster wide accounting in order to
account for both the workstation's usage, but also any "set display"
activity the user might have invoked on other nodes. The incorrect cpu
utilization would then show up as overbilling.
Don't feel bad, everyone in DEC runs accounting, but who really
looks at the numbers
|
| 660.4 | | CSC32::J_FELDMAN | cixelsyd TON ma I | Mon Apr 24 1989 19:30 | 8 |
| re -.2
Thanks Andy
Jim.
ps
Did you return that poor escort GT in one piece?
|
| 660.5 | | LESLIE::LESLIE | There is no final frontier. | Tue Apr 25 1989 05:21 | 2 |
| It was running a little rough, poor thing had been over-revved....
|
| 660.6 | | STAR::MFOLEY | Rebel without a Clue | Tue Apr 25 1989 09:48 | 7 |
| RE: .5
Yea, right... My face is still pulled back from the G forces
incurred hours before you left.. :-)
mike
|
| 660.7 | It could be better... | VMSINT::PIPER | Derrell Piper - VAX/VMS Development | Tue Apr 25 1989 10:39 | 4 |
| Just for the record, the DECwindows folks are working on it. As .1 pointed out,
it was never really a problem before, and we didn't have time to address it for
V1. It probably won't be addressed for V2 either, but maybe soon after that.
|
| 660.8 | What will this do when DWT comes along? | QUARRY::PETRAITIS | | Wed Apr 26 1989 05:39 | 4 |
| I would think that the 'single user system' hypothesis is (was it in .2?)
invalid for any system running a bunch of DWTs. What happens when you run out
of CPULIM in LOGINOUT? Has anyone reached this?
|
| 660.9 | | MU::PORTER | gonzo engineering | Wed Apr 26 1989 11:04 | 12 |
| re .-1
(Systems supporting DWTs)
Is that a hypothetical question, or is it actually going to work that way?
I'd sort of hope that with DECwindows terminals, you wouldn't have
to have a per-terminal process waiting just in case someone decides
to log in. I'd hope it would work more like real terminals: nothing
running, user pokes a key, driver sees unsolicited input from unowned
terminal, so sends message to job controller, which creates a process
running LOGINOUT.
|
| 660.10 | DWT's shouldn't need a dedicated process on the "big" host. | IO::MCCARTNEY | James T. McCartney III - DTN 381-2244 ZK02-2/N24 | Wed Apr 26 1989 19:56 | 7 |
|
I believe the plans are for the DWTs to use some protocol to inform the host
that it wants to start a session. For answers to this and other questions, I'd
recommend consulting the DWT group directly.
James
|