|
Grex > Coop11 > #32: How should we determine how many dialin lines we should have? | |
|
| Author |
Message |
| 25 new of 154 responses total. |
scg
|
|
response 100 of 154:
| 
Jul 24 02:27 UTC 2000 |
The virtual ttys are artificially limited to what the staff thinks the system
can handle. One of those system limitations is the network link. Another
is the computer itself. How much we could increase the count by before
bogging down the system, if we had the network capacity to do so, is a
question I don't have the answer to.
I doubt all of the network lag is due to Grex's ISDN connection. The routing
to Grex is a really strange kludge right now, since none of the Ann Arbor
based staffers has changed Grex's IP address to what it's now supposed to be
yet. Somebody should really do that soon.
|
mdw
|
|
response 101 of 154:
|
Jul 24 02:42 UTC 2000 |
Grex has more pty's than it has "network slots". It's more efficient to
limit things that way, also utilities like "script" don't work if there
aren't a few free pty's. The network slots limit is defined in
/etc/rules.conf.
Grex currently has a dsl line on order, which should be faster. It
appears to be a complicated multi-vendor order, so I'm not sure exactly
where we stand on that.
There appear to be two holdups for the IP renumbering: (1) we don't have
any one staff person who knows what all needs to be changed, and (2) the
subnet our vendor originally proposed turned out to be smaller than what
we have now, and would leave us with *no* expansion room whatsoever.
Actually, I'm not sure it would hold all of what we have now. We'd like
to avoid having to renumber again to expand, and our vendor seems to
have intended to give us the same size range as before, so again, I'm
not quite sure where we stand on this. Renumber is a fairly complicated
operation, and it's likely there will be a significant period of time in
the middle where things are "broken", ie, not reachable. This could be
as short as 10 minutes, or as long as 1-3 days, depending on how clever
we are, and whether we make any mistakes.
|
scg
|
|
response 102 of 154:
|
Jul 24 05:15 UTC 2000 |
Is anybody following up with the vendor on this?
The IP block they assigned us will leave us with one spare IP address, I
think.
Here's what needs to be renumbered:
Grex. The IP address gets changed in /etc/hosts and Grex gets rebooted.
Gryps. However this is done in OpenBSD.
The terminal server. It's fairly obvious how to do that, IIRC.
Then there are a few configurations that need to be changed. The terminal
server ports need to be set to connect to Grex's new IP address. DNS info
needs to be changed. This is done on Grex. Grex's telnetd configuration
needs to be changed to recognize the terminal server's new address. That's
about it. If anything's missing, it will be obvious really quickly.
|
prp
|
|
response 103 of 154:
|
Jul 24 16:30 UTC 2000 |
Re 97 janc statistics:
Can the program produce statistice for various time periods during the
day? Say Noon-4pm and 4pm-8pm. I doubt that anybody cares how many free
lines there are at 4am.
The CDF is also useful. Thus for June:
--- Percentage ---
#User Hrs/mo PDF CDF 1-CDF
----- ------ ----- ----- -----
0: 162.11 22.52 27.52 72.48
1: 199.08 27.65 50.17 49.83
2: 155.13 21.55 71.72 28.28
3: 108.48 15.07 86.79 13.21
4: 54.13 7.52 94.31 5.69
5: 25.83 3.59 97.90 2.10
6: 9.42 1.31 99.21 0.79
7: 3.99 0.55 99.76 0.24
8: 0.92 0.13 99.89 0.11
9: 0.55 0.08 99.97 0.03
10: 0.29 0.04 100.01 -0.01
11: 0 0 100.01 -0.01
Which means that with 6 phone lines the chances of a busy signal are
8 in 1000 (124:1 against), assuming you have no preferred time of day
to dial.
I was also going to caculate User-Hr/mo, but I forgot.
|
dpc
|
|
response 104 of 154:
|
Jul 24 19:13 UTC 2000 |
I think we should go with 6 lines. We're just throwing $100/mo
away right now.
|
janc
|
|
response 105 of 154:
|
Jul 24 21:29 UTC 2000 |
Note that June was a bit of a dial-in use spike. I think because of M-Net
being down.
|
albaugh
|
|
response 106 of 154:
|
Jul 24 23:23 UTC 2000 |
I'm not confident with dropping half the lines all at once. Certainly the
last 2 of the 12 didn't get any use. 4 others got only marginal use. I might
go conservative and say cut back to 9 or maybe even 8, to start with.
|
scott
|
|
response 107 of 154:
|
Jul 24 23:25 UTC 2000 |
I'd cut 2 to start with.
I think we figured out that it takes three months for a line cut to pay for
itself in the event we end up reactiviating it.
|
srw
|
|
response 108 of 154:
|
Jul 25 05:02 UTC 2000 |
I agree with Scott
|
janc
|
|
response 109 of 154:
|
Jul 25 05:45 UTC 2000 |
The board voted to cut two lines.
|
janc
|
|
response 110 of 154:
|
Jul 25 05:46 UTC 2000 |
(Someone needs to figure out which two lines to cut and tell Greg.)
|
prp
|
|
response 111 of 154:
|
Jul 25 17:40 UTC 2000 |
I think cutting 2 lines leaves 9. That gives a dial-in user a 0.03%
risk of a busy signal. As only unreasonable people want no busy signals
ever, a more interesting number is the risk of two busy singals in a
row.
Lines Risk(%) Odds
9 0.00001 11,111,110:1
8 0.00012 826,445:1
7 0.00116 86,504:1
6 0.00624 16,022:1
5 0.04410 2,267:1
4 0.32376 308:1
|
eeyore
|
|
response 112 of 154:
|
Jul 26 02:14 UTC 2000 |
Somebody really needs a life.
No offense, really, but I guess I just wouldn't expect anybody to actually
calculate the chances.
|
mdw
|
|
response 113 of 154:
|
Jul 26 07:46 UTC 2000 |
Only problem with prp's analysis is that people who get a busy signal
are likely to try again right afterwards, so the two events aren't
independent.
|
prp
|
|
response 114 of 154:
|
Jul 26 23:18 UTC 2000 |
Actually, the bigger problem is that they are based upon 24 hr data. We
know the assumption that people have no preference as time of day is
false.
|
prp
|
|
response 115 of 154:
|
Jul 27 01:35 UTC 2000 |
Re 112:
Mark's original question was: "How should we determine how many dial in
lines we should have?" There are two schools of thought on that.
The first is that busy signals are bad, AND people do not like change.
Do nothing. It costs more, but people are happy.
The second is that by scientifically collecting and analyzing data, we
can accurately predict what will happen, even though some do not believe
this.
|
flem
|
|
response 116 of 154:
|
Jul 27 01:37 UTC 2000 |
re resp:110 - Yes. And if it's now appropriate to drop the Ameritech ISDN
line, someone needs to tell me how to do that, too.
|
scg
|
|
response 117 of 154:
|
Jul 27 05:45 UTC 2000 |
It's ok to cut the ISDN line at Dorian's place. The line in the Pumpkin is
still in use.
|
mdw
|
|
response 118 of 154:
|
Jul 27 06:02 UTC 2000 |
It's probably best to wait - there's a 50% chance that ameritech will
cut the line at the pumpkin instead.
|
pfv
|
|
response 119 of 154:
|
Jul 27 06:03 UTC 2000 |
Only 50%?
(isn't there a Murphy's Corollary that talks about chances?)
|
krj
|
|
response 120 of 154:
|
Sep 14 20:02 UTC 2000 |
I'm going to kick this so it appears new.
A discussion about phone lines is in Agora's System Problems item,
where it is reported that "rarely" are as many as 5 or 6 of our
phone lines are in use. resp:109 says the board voted to cut
two lines earlier this summer; has this been done yet?
|
scott
|
|
response 121 of 154:
|
Sep 14 21:43 UTC 2000 |
Not to my knowledge.
|
scott
|
|
response 122 of 154:
|
Sep 14 21:44 UTC 2000 |
Oh, and we should be cutting our ISDN line(s) as well.
|
krj
|
|
response 123 of 154:
|
Sep 14 21:53 UTC 2000 |
OK. Note that somebody suggested keeping the ISDN line as an
emergency backup, and using it as a dialin line under "normal"
circumstances. I haven't seen anyone analyze the possibility
of that.
|
prp
|
|
response 124 of 154:
|
Sep 17 22:12 UTC 2000 |
re 120:
The fact thet one person got a busy signal for one call is not worth worring
about.
|