response 226 of 270:

Oct 7 04:00 UTC 1995

I'd certainly prefer to see availability.  There isn't any way this
system is ever going to be "fast" to anyone who is used to real
computers; nor is there any reason; as I see it, our mission is to be a
public communications service, not a private computing service; anyone
who really needs speed is far better served with a desktop pentium; and
if we really care about performance (and aren't just trying to become
more exclusive) on Grex, we might just as reasonably steer people way
far away from pine, or look into improvements to the tcpwrapper script
and to telnetd to avoid the nightmarish ident & double DNS hit upon
logging into grex.  (that long slow delay you see before the login
prompt isn't Grex swapping like mad, it's pure network fat.)

response 228 of 270:

Oct 7 04:47 UTC 1995

If we did cut off a few pty's for a while, that might encourage some ppl to
avoid the high-load times.  If we did it w/o warning, as was suggested, it
might have good effects w/o much in the way of complaints.  Even if it was
decided to discontinue the experiment, if anyone changed their usage habits
to avoid peak times, it will have done some good.

response 230 of 270:

Oct 7 05:43 UTC 1995

   I'm sorry Selena, but there are lots of people who disagree with
you, and don't use Grex precisely because it is so slow.  Read the
comments about Grex on M-Net, as an example.  Grex gets so completely
slow at times that *I* have problems using it.

response 232 of 270:

Oct 8 04:16 UTC 1995

I won't dispute that system performance could stand improvement.
Certainly, moving to a sun-4 will be a win, and in fact, it's likely to
make enough of a difference that it's really kind of stupid to try to
figure out a fix now.  The bottlenecks are almost certainly going to
move around.  I notice that as I write this, Grex has 40 people, & M-net
42.  That's not a very scientific sample, nevertheless, I do think it's
sufficient to suggest that CPU speed is highly overrated.

There's another factor here as well - I suspect STeve knows a lot of
people who work in & around the UM computing community; and that means a
lot of people who are used to ethernet speeds and SparcStation 20 CPU
power.  I rather doubt we'll ever see many of those people on grex; we
don't have the budget to afford more than a microscopic fraction of the
CPU the UofM buys every day.  So, Steve is always going to have an
impression of Grex as the slow system on the block.

There are also plenty of people who are used to "faster" systems from
their ISP.  Practically by definition, an ISP will always be able to
afford more hardware than Grex; that is a game we cannot win.  Indeed,
it's a battle we're much better off losing; if we won, all we'd do is to
become a fast cheap web/ftp/mail site.

Actually, in a sense, performance is a constant.  It's kind of like
highways.  If you build more highways, people will use them.  If you
provide more CPU, people will use it.  As a general rule, in order to
provide a *perceptible* difference in speed, you have to provide at
least a factor of 2 improvement.  (That's one reason why modem speeds
have generally jumped in increments of at least 2, and more generally
4.) So, if we had 30 people on instead of 40, there would not be enough
difference in speed to make a difference.  If there *were* a difference,
chances are it would be due to people "camping out" on scarce lines, and
thereby dramatically shifting their usage of grex towards optimizing
scarce CPU.  I'd like to think Grex is about something more important
than that.

And perhaps that's the real key - the poeple who are going to complain
the most, and go elsewhere, are the people who already have
alternatives.  We can't *possibly* hope to to keep *everyone*.  In fact,
the more successful we are, the more people we'll be losing, and the
more we'll hear about ourselves elsewhere.  It's inevitable.  It's
perfectly reasonable to worry about performance, but let's worry first
of all about *improving* it by doing things like looking at where the
lag & CPU consumers are, and fixing those.  Did you know that on the
UofM's nice big fast sparcstation 20's, they still don't get more than
about 40 people on?  It seems they all run pine, and that's the # of
pine clients you can get running before sparcstation 20 performance
starts to suffer.

response 234 of 270:

Oct 8 13:00 UTC 1995

I'm vehemently in favor of trying this, to see what happens.
It's incredibly easy to reverse, if we don't like how it works.

response 236 of 270:

Oct 8 18:39 UTC 1995

My $.02:  If you do it w/o announcing it, ppl may not notice the increase in
"no ports" msg's, while still noticing that the slowest Grex gets isn't as
slow as before.  Also, increasing "no ports" msg's will encourage those
receiving them to call at other times.

Go for it.

response 238 of 270:

Oct 9 14:29 UTC 1995

   Marcus, you aren't getting one very important point in all
this.  Grex isn't slow--it's *So Unbareably Slow* that people
have left it because they can't do *anything* reasonably, short
of party.

   It's not that we're the slow kid on the block.  It's that to many
people, Grex is the unusable system on the block, and that not only
worries me, it scares me.

   We're down in terms of our membership, and I will bet that there
are three things here that have caused that.  About equally, I see
them as A) The incredible slowness of Grex, B) the disk instability
which is pretty much the daily Grex filesystem lottery, C) lack of
usenet.

   We *can* control how fast Grex is, too.  We can choose the number
of pty's for incoming telent sessions.  Once we're on the Sun-4, I'd
like to see Grex back at 48 pty's (if we've ramped them down).  Once
we get an ISDN connection, I'd like to see the number of pty's go up
to something like 64.

   We don't have to infinately increase the number of people who can
get on here; we can make some limits, recognizing that Grex can't be
everything to all people.  We can try to be as much to as many, but
realizing that if we get 150 people telent in here at once we'd have
nothing left in the way of the system.

   Back when we first started Grex we had no idea of what kind of
usage we could attract.  I remember thinking (and I think some of
the other founders thought this, too) that we'd have to come to terms
with things like this in the far distant future, if we made it (for
those of you who've only used Grex via the link, there was an initial
one year period where the folks that started this plase also paid the
bills, in the attempt to jump-start Grex and let it gather interest
without having to beg for money evey other day).

   That all worked, and now, we're in danger of seeing Grex cummble,
not because of too few people on, but too many.  What might have
seemed absured in the summer of 1991 is now a real possibility, as
I see things.

response 240 of 270:

Oct 9 18:11 UTC 1995

I agree with Steve here. Marcus, the fact that alot of people on Grex don't
mind the slowness or believe they can get things done, proves nothing. Don't
you understand that the current membership has already been *selected* for
that group of people who either don't mind the system being slow, or they
only run party, which still works reasonably well when the system is 
overloaded. I think that it's entirely likely that there is a much larger
set of people out there that would come to Grex if it was faster and it
was possible to do other things besides party. If we follow your
logic, we are going to eventually wind up with a system with 200 people
logged on, the system dead slow, and 185 of them running party.

I, fo r one, would like to shift Grex's emphasis *away* from party, not
encourage it's use even more.

Re #239: Ajax
Rob, are you aware that Marcus *is* the designer of Picospan?

response 242 of 270:

Oct 10 05:57 UTC 1995

And what makes you think the same slowness will be true on the sun-4?
You don't *KNOW* what the bottlnecks will be.  Neither do I.  We *all*
know that the bottlenecks aren't linear.  Before we argue about fixing
them, let's find out where they shift to, and how bad they are.
Anything else isn't science.

So far as the present membership/"grex is going to go broke next week
and crumble into little bits" - considering we've never made any kind of
real membership drive, and the vast majority of users don't even ahve
any idea that grex is 100% membership supported (but on the contrary,
act in every way as if they thought Grex were funded by the government,
or a large corporation, and had infinite CPU & network bandwidth); I'd
have to say, again, that thinking that improving performance will solve
this, isn't science either.

I have nothing against religion.  But I have not found it to be a very
effective problem solving strategy.

Hey, I use Grex and PicoSpan too.  (What, you think I have a secret
web interface to compose this message?)  I do see a delay here, but
I'm afraid what i'm seeing at the moment isn't CPU at all, but
100% network lag.  The fastest computer in the world won't fix that.

response 244 of 270:

Oct 10 07:24 UTC 1995

I am sure I've hard the argument it's ok to discourage people
during peak times, so performance during those times can't
be relevant.  As soon as you do a maxpty's limit lower than
the # of users, you're going to have to do idle killers, time
limits, and a whole host of other things.  You're fighting
human nature, to pretend otehrwise.

response 246 of 270:

Oct 10 13:12 UTC 1995

Re 243: Another difference between the speed Marcus sees and the speed the
average user sees is that Marcus's account is listed very early in the
password file, which means that Picospan is going to run a *lot* faster for
him than for the latest random newbie who just ran newuser and is listed on
line 7000 of the password file.

response 248 of 270:

Oct 10 17:25 UTC 1995

   (Another expmple of the extreme quickness of Grex right now: Nick
Contaxes, our landlord, stopped by just now, and asked me a question
since he saw me in the Dungeon.  I attempted to run 'man mail | col -b'
and stuff it into a file, but Nick had to go before I could get the
info he needed.  He waited more than 5 minutes and no data.  I'm
still waiting.)