response 26 of 196:

Jul 13 06:26 UTC 1996

Selena slipped in.  Obviously, the wait queue as it was implemented a few
nights ago was not a good fix.  That's why Marcus backed it out and went back
to the old system while he works on fixing it.  There was a bug that left a
large number of ports used by people who logged off unavailable for new people
to use.  So, what we had was effectively a situation where the line wasn't
moving, while more and more people were getting in it.  When it is fixed it
won't have that problem, so I'm not concerned about that.

I have yet to see a new, relatively untested, complex program that doesn't
have some bugs in it.  that's just the nature of programming, since even the
best programmers make mistakes, or don't anticipate something that's going
to happen.  Testing is the only way to find bugs, and putting something into
service is the best way to test it.

response 28 of 196:

Jul 13 17:51 UTC 1996

Okay I can see now that if the bugs are worked out, that this is p robably
a good idea.  Whether it is convenient depends on your situation.  I was upset
the other night because by unfortunate co ncidence, I was not at home and was 
trying to log on from the library, which has a thirty minute time limit. 
Spending ten minutes of tha ttime waiting on a countdown not only is not time
efficient but doesnt make the people behind you waiting to use the computer too
happy either.  Therefore, it may not be practical to grex from there in the
future.  Not everyone has the time to wait around on hold.  I think that if it
is going to make logging on more time consuming then it could discourage folks
from coming here altogether.

I think it is just natural that a staff discussion of this was going to 
focus more on the technical merits.  This is wh y I think this needed to be
discussed in coop before implementation.  There are always non-technical
considerations.  It is just a matter of pure consideration to get as much
feedback as necessary from regular users before proceeding with something
like this.

response 30 of 196:

Jul 14 05:01 UTC 1996

it will be really nice if it starts working ;}

response 32 of 196:

Jul 14 08:22 UTC 1996

This fix was also mentioned in another item by me about a month or so ago.
While I do think a posting in the MOTD might have been nice, and I think Chaz'
tone is a bit acerbic, I do have to agree that the warning has been around.
I was rather happy to see the queue in the afternoon.  I was distressed when
I tried to login on at 2 am and there were 200+ people in the queue and only
30 ttys actually in use (FOUR of them, I might add, by nestene... not sure
if any of those were idle, though).  I figured, logically, that there was
something wrong with the queue program (especially since some of the 200+
folks had been in queue four hours, supposedly).

At any rate, I like the queue program.  Yes, the wait was longer in the
afternoon than it had been with the telnetd-block, but with the latter, I have
to stay with the computer and repeatedly try, with the queue, I can at least
go do something else and just keep an eye on things.

response 34 of 196:

Jul 14 13:02 UTC 1996

A little warning would have been nice, since it has been pretty open-ended
when this would go into effect.  BUT, I'm not that worried about.  After all
we're talking about changing how an error message works, not how telnet really
behaves.  We just get telnet errors a lot due to our popularity.

response 36 of 196:

Jul 14 20:39 UTC 1996

If the system you're coming from supports offsite fingering, you don't 
even have to join the queue to see who's on.

response 38 of 196:

Jul 15 01:40 UTC 1996

i think it will work really well if after a certain amount of time
well if there's some way to see if the original connection is even still
be maintained at the other end.
and to dumpmp people who have forgotten about it after a certain
amount of time at the login que -- maybe 5 minutes ?
when I was using it it was working and in about 10 minutes
i got from beign 170th or so on the list to having a login prompt
i liked knowing there was movement and not having to do the telnet
dance every 2 minutes (espeically since my telnet program takes 1-3

minutes to give me any information from the system after connection (mean)

response 40 of 196:

Jul 15 05:08 UTC 1996

Yes, I usually don't spread out like that, but when I logged on and saw
only thirty-six users on the system, I figured it was a low-demand night.

response 42 of 196:

Jul 15 06:45 UTC 1996

I was astonished that the queue was reimplemented, considering that this
item was started to discuss it prior to its further use. None of the
questions that have been raised about it have yet been answered, either.
This seems to be akin to what is called "arrogance" on someone's part. 

I came in at #48 in the cue (it said 42 users (??)). When I got down to
31, I started timing my wait. It took 26 MINUTES to connect. I have NEVER
had to telnet in even twice to connect at 2 a.m. The queue obviously
favors collecting a large number of waiting users, who would otherwise go
and do something else. 

At the end of that 26 minutes I did not log in, but waited for the time
out. I had asked here how long that was going to be, but no one answered.
It was 56 seconds. That means that every abandoned (but not cancelled)
queue spot takes a minute to clear. No wonder that the queue gets so long
and the wait time is magnified by an order of magnitude. 

All throughout the wait, there were never more than 40 users on (according
to the message), though when I then dialed in (after my connection was
dropped), it took 5 rings, and there were 67 users. What's wrong there? 

I see that scg sits at his computer all day so has something to do while
waiting 26 minutes to connect to Grex. Not everyone does. Many users will
want to try to connect in a brief time interval, and if they can't get
back to their real lives. Grex will become unavailable to them with this
system. 

I hate it. However the real point is, it should not be implemented again
until an adequate discussion of it has run its course, and the consensus
is that it should be implemented. I don't mind it being experimented with,
but I would appreciate, as a user and a member, that those wanting to
implement this come forward and discuss it with us, and take our concerns
and questions seriously.

response 44 of 196:

Jul 15 07:59 UTC 1996

I've been called arrogant before, by better than you.  I do hope that
now that you vented your feelings, you can dispense with the name
calling.

I don't blame you for hating the queing; I don't like it the least bit
too.  However, apparently unlike you, I also hate the "no ports" message
even more.  One of the reasons people like you can log in "without much
waiting", is because people like me realize there's nothing fair about
the resulting "lottery" process, and also that the "no ports" message is
an expensive drag on grex resources, so we go away, I am fairly well
convinced, based on evidence in the log files, that there may be *some*
people who run this script: "while :; do telnet grex; done".  This
presents *that* person with all the convenience scg enjoys, of "doing
something else" until a grex login prompt pops up, but it's even worse:
it slows the system down *until* they get a prompt, & if they go off &
leave it running overnight, it *keeps* slowing the system down.  When I
first discovered this, the first thing I did was to put in the "sleep"
after saying "no ports".  This did, in fact, have a beneficial effect on
system load and net lag, although it also generated a number of outraged
messages from people.  I suspect some of those people were outraged that
their attack telnet scripts weren't quite as "aggressive" now.  We've
also gotten rather curious complaints, from time to time, that the login
program doesn't wait "long" enough at the login: prompt before timing
out.  In fact, it waits 60 seconds, which is quite long except for
people who aren't paying attention to their attack telnet script.

Something even sadder then happens.  Some of those people like you, who
fought through the "no ports" delay, get on and discover the system is
very slow.  Instead of blaming it on "attack telnet"'s, or ftp's, they
blame it on there being "too many users online".  This causes a hue and
cry to drop the # of pty's, which of course would only *increase* the
whole problem.  leaving the system apparently "free" for people like
you.  [Note, in this latter instance, I said people "like you" - not
necessarily "you" in particular.]

But you are right, in the end, the membership is going to have to decide
what it wants.  All I've done here, is to provide a choice.  We could
easily go back to the old system, with all of its attendant
unfairnesses, or the new system, with all of *its* attendant
unfairnesses.  It's still a bit soon to say *how* unfair it will be;
it's likely to take at *least* several days for people's usage patterns
to shift, and for us to predict how big the queue is likely to grow, or
the avg. wait.  My *personal* hope is that this will eliminate enough
pressure from attack telnet'ing that we can open up a few more pty's,
and thus make the system useable to more people than we could before.  I
think that's a net win.  In the end, though, it really is up to the
membership at large to decide, all I ask is that it be given a fair
trial first.

So far as my being presumptuous, I do think that is a bit silly.  "Net
lag" has long been universally recognized as a scourge, and I don't know
many people who would argue for a scarcity of grex telnet ports, or that
the "no ports" message or delay was "good".  One of the responsibilities
staff has is to come up with "improvements" to the system.  I happened
to volunteer, because I thought I could do a "better" job; but there
were several other staff people eager to work on this if I didn't.  I
don't believe there was any particular secret about this; so far as I
can recall, it's showed up with some regularity in staff & board meeting
minutes, and there were certainly even non-members who were aware that
it was coming down the pike.  For anything people on staff or the board
think might be controversial, I believe we make every conscientious
effort to involve the membership at large, *but*, our membership has
also pretty clearly indicated that there are many things where it is
perfectly happy to just "let us do it" and would rather not be bothered
with the details.  Much as we might *like* to spend more time telling
them about all the marvelous things we have planned (often *long* before
we can get around to it), I think we also have a responsibility to only
bother people with the *important* things.  In the end, nevertheless,
the decision is *still* the memberships.  They have the final ability to
if they want to keep the waitlist, or go back to the old system (and it
is even possible that *I*, as a member, might end up urging people to go
back to the old system).  They also have the final ability to decide who
they want on board or staff, or if they are happy with the procedures,
policies, and available resources or not.  I think my work would be
*delighted* if grex were to suddenly sprout a very complex bureaucratic
procedure to stage changes, because I'd probably spend a lot *less* time
doing things for work.

response 46 of 196:

Jul 15 14:11 UTC 1996

<laughs at #10>  But in all seriousnes i think this is great!  Now instead
of having to start my telnet session, get telnetd, start telnet, get telnetd,
start telnet, get telnetd unitll i get a tty i just start it once and wait..
For tose of you that can multitask, then use netscape or irc or something
while you wait.  Now at least you know when you are gonna get a tty.

response 48 of 196:

Jul 15 17:55 UTC 1996

Arguing the pros and cons of something tends to be more productive
when you have actual experience with it. I think it was appropriate
for Marcus to run this again after working some more on it. Now
that we have a feel for what it's really like in practice, we can
argue about it more intelligently.

I've telnetted in three times today in order to try this out. Seems
to work well, and basically I like it. It's a lot more convenient
for me -- I can do other stuff while working my way through the
queue. The system is a lot fairer than the previous Russian
roulette method of getting a connection, and I can believe it's a
lot easier on the system load than the attack-telnetting that the
old method encouraged.

I *did* manage to miss the one-minute window once when I wasn't
watching. Rather frustrating when you've been in the queue for 45
minutes and then have to drop all the way back to the end. And
considering the narrowness of the time window, all too easy to have
happen to you. One suggestion for helping people avoid that: send
an audible beep periodically -- e.g. every time they move up in the
queue -- and then a series of beeps just before giving them the
login prompt. Provide a menu option for turning off the beeps, for
people who find them distracting.