On 4 Jun 99, at 23:36, Peter Doherty wrote:
> However, one thing to note is that SETI @Home doesn't seem to be as "idle
> priority" as Prime95 is. I ran it for a while, and I felt I could notice a
> slowdown, and when it wasn't minimized, there was a VERY noticeable
> slowdown. I think SETI @Home actually steals more than just idle cycles,
> and gets a few more.
I believe the screensaver version (for Wintel) runs at priority 4,
which is normal for screensavers, but the "detatched" version runs
at normal application priority on all hosts. (Unless modified by
"nice" on Unix systems)
>
> >The message of the day on the Sun machines here at the University of
> >Michigan included the following today:
> >
> > * * * * *
> >Please do not run the Seti At Home program on the Login Servers. Although
> >it is for a good cause, the Login Servers do not have any spare CPU cycles
> >to donate. Running Seti At Home interferes with other users getting their
> >work done.
> > * * * * *
This says a lot. Presumably lots of people with accounts on the
server are all trying to run Seti@Home. Though one instance might
go unnoticed, a lot of instances certainly will use up memory (and
other critical system resources e.g. process slots), as well as
interfering with each other - and with whatever job the servers were
installed to do.
> >This illustrates the importance of getting permission before running
> >processor-intensive programs on machines that are not entirely your own.
Agreed. Applies to mprime/NTPrime/Prime95 as well, even if they
do have "better manners" wrt using system resources on multi-user
hosts & servers.
> >There are only about thirty people logged in on the machine that I'm using
> >right now, and as usual almost all of them are running Pine; even with
> >this comparatively light load the slowdown was apparently bad enough to be
> >a problem. I suspect that people trying to run Seti on these machines at a
> >peak time of year would create a big performance drag, and force the
> >administrators to monitor individual users' processor usage more closely
> >to prevent such abuses. It is easy to forget about such consequences in
> >the quest for CPU time.
Probably the memory was getting used up, causing swapping,
which really knocks the apparent performance of the system back.
Or, if there were a lot of instances of the "offending" program, just
having to wait in a long queue to get at the CPU can make things
appear to be unacceptably slow. On a multi-user system, as the
load rises, the response time rises about linearly initially, but
steepens until eventually becoming essentially vertical. The "elbow"
in the response time/load curve is very sharp, this is not a simple
polynominal or exponential growth curve.
Actually it's very easy for system admins to "find" programs like
this that are "abusing" the system & take suitable action (in line
with local site regulations) to stop the abuse. But it obviously
makes sense to ask the users not to be an unneccessary
nuisance in the first place.
Another thing; it's sometimes incredible to users just how limited
the CPU resources on central server systems can be. e.g. at the
University of Ulster, all the staff (academic & non-academic) e-mail
goes through one server running Novell Netware on one Pentium
133. That's well over 1000 users ... It's (just about) adequate but
there really _isn't_ a lot of horsepower to spare. And it would be
impossible to justify an upgrade or replacement on the grounds of
"insufficient CPU power" if "unneccessary" CPU-intensive tasks
were found to be running on the system.
But the really crucial point is that there is absolutely no point in
running more "CPU soak" programs on a system than the system
has processors - if nothing else, the extra task switching between
"CPU soakers" wastes CPU cycles!
> >I'd like to think that GIMPS members, on the whole, do not deserve
> >warnings like the one above. Let's keep it that way.
Some will not need the warning, some (especially those who may
not appreciate the complexities inherent in multiuser systems)
almost certainly do. It's very easy, these days, to assume the only
resources you're using are those of the box you're physically
connected to via your fingertips.
Incidentally Seti@Home is a moderately heavy user of network
resources, too. (Unlike the GIMPS programs, which are very light
on network resources.) At University of Ulster we find this isn't a
problem (though we most definitely do see signs of a shift in usage
pattern since Seti@Home came on line). However it might possibly
be at some sites.
Regards
Brian Beesley
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
