|
|
| Author |
Message |
| 25 new of 270 responses total. |
lilmo
|
|
response 175 of 270:
| 
Sep 27 19:26 UTC 1995 |
If it was linear, than knocking off a few wouldn't make much difference. The
implication seems to be that after thirty, the slowness increases
geometrically, or even just arithmetically with the number over thirty. In
either of those cases, knocking off a few WOULD make a difference.
You seem to think (and I don't know who is right) that Grex has two states:
fast (when less than 30 ppl are logged in) and slow (when >30 are logged in).
If that analysis is correct, then no, knocking off five or eight pty's won't
make the slightest bit of difference.
|
srw
|
|
response 176 of 270:
|
Sep 28 05:48 UTC 1995 |
I don't disagree with STeve that Grex gets slow at 30. The number of
contexts supported in the hardware, and the amount of RAM and average
program size are all factors in creating this effect. Nevertheless I would
argue that the performance continues to degrade as you add more users.
By the time you are using the last three or four ptys, I think Grex
is running backwards, and I agree with Rob Argy that it would be helpful
if we took the edge off of that by cutting back a bit on ptys.
I am thinking of a very small scaleback, so that the amount of time that
we are running limited might increase from the 30-minutes per day level
it is at right now, to now more than an hour or two per day.
This would be a very easy experiment to perform, and could be reversed
if we didn't like the effect.
|
sidhe
|
|
response 177 of 270:
|
Sep 28 20:56 UTC 1995 |
And, once again, I note above that the users who come on to
use party are being pointed out as second-class. PicoSpan is no longer
the main purpose of grex.. this may be a sad fact to many of you, but it
no longer a matter of conjecture. Treating people as if they are not
important because they do not use PicoSpan is, quite simply, shameful.
Grex's best resource is not it's bbs anymore. Bbs is a _good_
resource, but it certainly does not set us apart like it may once
have. Anyone who wants to join a system for conferencing will go to
ISCA. Anyone who wants to strictly "party" will join nether net, and
do IRC. Anyone who wants free email can do so at arbornet OR nether net.
And that speaks nothing of the freenets.
So, once again, the only, and I do mean only, thing that keeps
grex from being "just another old UNIXbox" is the PEOPLE you find
here. And, whether or not those people are members, they are coming
in over telnet to participate, not just in party, but also PicoSpan,
enlivening and enriching it for those of your precious membership who
still come to grex just for the conferences.
Now, the "well, let's try it" attitude is fine, if it would
only be _extended_ to all proposals that could have their effects
revesed if they didn't pan out. If this can be done, then fine, try it.
Otherwise, I ask that you don't use the same excuse that you so
often brush off when asked of you.
|
ajax
|
|
response 178 of 270:
|
Sep 28 22:05 UTC 1995 |
With "try it and see," there's an implicit, democratic "[if
most members or board members agree it's worth trying]".
Grex has limited resources, so we prioritize what to support.
I bet most members would place Picospan first, with party soon
after, and IPhone (don't ask) dead last. In that sense, there
are classes of apps on Grex. There's room for many, but we can't
optimize for just one, at the sacrifice of other important ones.
That's nearly what happens when there are 50+ users on Grex:
party is ok, but Picospan and e-mail are barely usable.
|
selena
|
|
response 179 of 270:
|
Sep 29 02:38 UTC 1995 |
I've been on when we've had 50+ on, and used PicoSpan just
fine. What's eating everyone, anyway?
Oh, and scg, what's with the quotes around my name in #173?
Is everyone who kinda-sorta agrees with me a "selena"? I kind of
thought I was unique, bud.
|
srw
|
|
response 180 of 270:
|
Sep 29 06:25 UTC 1995 |
Grex is not fine whenever I've used BBS at 50+ users.
Other things are worse than BBS, though, like elm. I don't use pine,
because it makes elm look fast.
|
scg
|
|
response 181 of 270:
|
Sep 29 07:02 UTC 1995 |
It depends on your definition of fine. If people are willing to wait five
minutes to join a new conference, Grex is just about always bearable. Some
of us have better things to do with our time. I've been noticing lately that
I seem to be able to get fairly reasonable performance out of Grex around 2:30
to 4:00 am, since that's not a time that works for people with set work
schedules. That seems to be part of the awake part of my sleep schedule these
days, so I think I'll confine my Grexing to those hours until my sleep
schedule revolves past that (that sort of time is currently at the end of my
day, so it will be a while before it becomes too early in the morning for me,
I think.
|
popcorn
|
|
response 182 of 270:
|
Sep 29 12:44 UTC 1995 |
I generally see OK performance in the mornings. (This morning there was a
twit running a hog-up-the-system script, so the load average was in the 60's,
but once that was taken care of, the system started chugging along nicely.)
|
selena
|
|
response 183 of 270:
|
Sep 29 15:02 UTC 1995 |
PicoSpan does *not* take five minutes to change conferences, at 50+
people! <Selena thinks these guys are really overreacting>
|
steve
|
|
response 184 of 270:
|
Sep 30 02:31 UTC 1995 |
Actually Selena, I have seen times close to that. A few weeks ago
when the load average was above 35, I got into PicoSpan going immediately
to Agora, and it took 3:42 to get to the OK prompt. I know becuase I
timed it. So yes, you are right that it probably doesn't take five
minutes, but it can take several minutes. That was a bad time for
Grex with the load averages so high, which isn't usually the case, but
it did happen to me and I timed it.
|
davel
|
|
response 185 of 270:
|
Sep 30 13:11 UTC 1995 |
Yesterday morning around 7:00 was about that bad. I gather that in this case
it was something someone was running, eating cpu time like candy, rather than
a lot of users, but when the system load really climbs Picospan can indeed
take minutes to change conferences.
|
selena
|
|
response 186 of 270:
|
Sep 30 13:40 UTC 1995 |
Right! See? taking users off isn't going to do anything but piss
them off. The load can *still* climb.
|
steve
|
|
response 187 of 270:
|
Sep 30 15:39 UTC 1995 |
We talked about this at the last board meeting. Steve Weiss said
something that did make sense. His thoughts were that, if we take
off some number of pty's, like maybe 8 or so, then at the fullest,
Grex will be slightly better off in terms of speed with those few
ptys disabled. Once the load averages go to hell, they continue
sliding off into the absurd then finally into the ridiculous.
Removing some pty's will not effect Grex at all, for the majority
of time. I haven't gethered any statistics on this yet, but it is
unlikely that we're near capacity more than 10% of the day (2.4 hours).
So, the effect here would be to have Grex unchanged 90% of the time,
but that last 10% when the system is truely bogged down we'd be making
the system less slow.
Given that the vast majority of time this wouldn't impact anyone,
I think this is a reasonable thing to try. Every minute we keep a
record of the load average, so we can look back and see the effect.
If it isn't working we can either stop it completely or ramp back
farther.
Selena's comment about the loads ability to still climb is
certainly possible, but usually not likely. There are times when
a particular combination of loads can drive Grex crazy, but it
usually doesn't happen.
This is all a balancing game. We might have to change things
several times to achieve the proper mix. But it has finally
dawned on my little brain that having Grex faster at the worst
times, making Grex only glacially slow instead of glacticly slow
is a good thing.
|
mlady
|
|
response 188 of 270:
|
Sep 30 15:53 UTC 1995 |
no, not this one..
|
janc
|
|
response 189 of 270:
|
Oct 2 16:56 UTC 1995 |
The performance with 50+ users, as with 2 users, varies widely depending
on what those users are up to. If most of the users are in party and
nobody is doing anything nasty, like an ftp or launching pine, then it
can still be pretty fast. Party literally spends nearly all it's time
asleep -- even that fastest party is really slow by even Grex's CPU's
standards. But if you get a few more people doing CPU or memory intensive
things, the circumstances can change drastically.
|
selena
|
|
response 190 of 270:
|
Oct 2 17:15 UTC 1995 |
Right, so I don't think taking off tty's is going to be any
kind of good solution. It'll just extend the time when grex is not
available to your net users.. and *that* ia annoying enough already.
|
davel
|
|
response 191 of 270:
|
Oct 3 01:06 UTC 1995 |
Actually, it sounds like it could well make a big performance difference at
a very small cost. It will not "extend the time when Grex is not available
to net users" - there will be at least 30 of them on, right then & there.
It will admittedly have a *slight* impact on the number of people having
connections refused. I'd say it's worth trying, though.
|
steve
|
|
response 192 of 270:
|
Oct 3 02:36 UTC 1995 |
The here is that by chopping off the last 8 ptys, we can keep
Grex horridly slow, as opposed to completely and absolutely horridly
slow.
It won't "solve" anything, but it will keep the system from
getting even slower than it would with a full house.
|
janc
|
|
response 193 of 270:
|
Oct 3 03:05 UTC 1995 |
It's worth experimenting with. We should have collect some good data on
performance before the change to have a benchmark to compare to. These
kinds of issues are much easier to debate after we have some facts.
|
selena
|
|
response 194 of 270:
|
Oct 3 04:55 UTC 1995 |
Well, not that this ever means much, but I really object to the idea.
|
robh
|
|
response 195 of 270:
|
Oct 3 12:08 UTC 1995 |
At this point, I'd say go ahead and try it, and then when we get
the torrent of complaints we can switch back.
|
mlady
|
|
response 196 of 270:
|
Oct 3 16:12 UTC 1995 |
Whoa. Brief me, here.. You want to eliminate what?
|
rcurl
|
|
response 197 of 270:
|
Oct 3 18:49 UTC 1995 |
A couple of ptys at the "top end" - that is, reduce the maximum internet
connections from ca. 50 to 48. There is a problem with the system bogging
down extremely rapdily when there are 50 users on...the idea is that
there *might* be better performance for only a slight sacrifice of
capacity.
|
sidhe
|
|
response 198 of 270:
|
Oct 3 20:20 UTC 1995 |
Doubtful. Being one who telnets in exclusively, I find the whole
matter rather disturbing. I would suggest, as a devil's advocate move, to
"just do it" and take abot one-five off WITHOUT MENTIONING IT to anyone,
and see if you get complaints. If not, then obviously, nothing's wrong
with it. If so, and I suspect that this will be more likely, then I
suggest you throw the idea in the fireplace.
Why the reversal in position? I've done marketing. A blind test is
always the most accurate.
Now, can this "let's try it" be extended elsewhere, soon?
|
steve
|
|
response 199 of 270:
|
Oct 3 20:55 UTC 1995 |
I've just gotten some numbers together that might help things
a little. There is a file that contains the output of a "uptime" that
is executed once a minute. I just looked at 1,440 minutes of that
file (1 days worth) from 4:02pm Monday to 4:01pm Tuesday.
Looking at that data, I extracted two sets of numbers; all the
uptimes with fourtysomething users on, and fiftysomething users.
There were 97 minutes in which 50 or more people where on (1 hour
37 minutes), and 370 minutes with 40 to 49 users on (6 hours 10 minutes).
Since we don't have a record of how many pty's are in use as opposed to
dialin lines readily available (we could use the wtmp data if we really
wanted to), there is a certain about of possible variance here, but I
think the numbers still speak fairly clearly on what will happen if we
remove 8 or so ptys
Fortysometing Fiftysomething
users users
Minimum 8.73 9.73
load av
Maximum 43.51 49.59
load av
Average 18 26
load av
The important number here is the average. 18 is still glacially slow,
but not as bad as it can get. It's also important to point out that
we're talking of impacting people's telnetting into Grex about 2 hours
a day, or about 8%.
I think this is a reasonable thing to try. Certainly we can bring
the extra pty's back once we A) get more memory B) move to the Sun-4
C) get a faster net link D) decide that the extra access to Grex is
more important than the speed of the system.
|