How should we determine how many dialin lines we should have?

Oct 1 17:56 UTC 1998

There are currently 13 phone lines dedicated to users who dial in to use Grex.
There is some evidence that that is more than we currently need, and it might
make sense for us to disconnect them and use to money we save on something
else.

Before we do that, though, we should come up with some criteria for deciding
how many dialin lines we should have at any given time.  That way we can
periodically re-evaluate the situation, and adjust the number of lines up or
down as appropriate.

In item:coop10,101 (oldcoop item 101), Richard Green proposed a couple of
possible criteria:

1) We should have the right number of lines so that the last line is busy
   between 1 and 5 percent of the time (i.e., between 15 and 75 minutes a day)
   and no single period of business lasts more than 5 minutes.

2) We should have 8 lines per dialin user.

Dave Cahill suggested the alternate method:

3) We should cut one line per month until we get complaints.

The goal of this item is to come to a consensus on what criteria we should
use.  To be acceptable, clearly, the criteria must refer to data that we can
actually obtain.  The most useful data in this regard will probably  be the
wtmp log, which tells when each terminal session begins and ends, and so can
be used to tell how many people are dialed in at any given time.  It's
also possible that we could get Ameritech to give us some statistics on how
often each of our lines is busy.  (I'd like more info on what exactly they
can tell us.)

response 2 of 154:

Oct 1 20:33 UTC 1998

I'm not sure there are any objective criteria that a consensus can
develop around.  Perhaps Richard Green's #1 is a good place to
start, though.

response 4 of 154:

Oct 1 23:28 UTC 1998

ok, I'll renter that response here.
>I agree with the decision to drop the ICNet service.  I also agree that we
>might want to drop a line or two for dial ins.  I would like a "busy signal"
>criterion.  I don't know if Grex can do that, or if we'd have to have
>Ameritech do it.  Basically it tells you busy signals/hour, and is a slightly
>more useful data set that our simple "duration of 'lines all in use' ".

response 6 of 154:

Oct 2 06:07 UTC 1998

Looks like I should have read this item before I entered my response to
the last one...
Criteria #2 should read "8 users per dialin line", and is a general rule
of thumb gleaned from conversations with other ISP's.  The real criteria
is how many busy signals will our users accept?
  Dropping one per month until complaints happen maximizes our expense on
Ameritech service charges, and is guaranteed to generate some at least
temporary bad PR.
  Deciding on a criteria, then going for it, minimizes service charges,
and has a good chance of being transparent to the user community.

Misti: re#2 - counting busy signals does not equal 'missed users' since
most users will attack dial for at least a minute or two before giving up
for a while.

My experience with the telnet queue at its busiest is that a port frees up
every 20 to 45 seconds.  That's with what 60? ports available? If we went
to 10 dialins instead of 13, would it be appropriate to extrapolate that
one would free up every 120 to 270 seconds?  That, in my opinion, is a bit
longer than the average user would be willing to sit there and push the
retry button, so we should set the criteria for last line in use fairly
conservative, say 1% (15 mins/day) and then only if the longest single
instance of that last line busy is no longer than 5 mins.