|
Grex > Coop11 > #32: How should we determine how many dialin lines we should have? | |
|
| Author |
Message |
| 25 new of 154 responses total. |
albaugh
|
|
response 85 of 154:
| 
May 22 22:09 UTC 2000 |
Just don't use phrasing that "people who dial in are costing grex more".
People don't cost grex a damn thing. Grex deterines the resources, people
use 'em.
|
scg
|
|
response 86 of 154:
|
May 22 23:05 UTC 2000 |
Are you offended by my phrasing?
Grex hopefully determines the resources based at least in part on whether they
are going to be used.
|
devnull
|
|
response 87 of 154:
|
May 23 01:32 UTC 2000 |
Re #80: Exactly, and it seems to me that if there are significant numbers
of such people, we ought to find some way for those people to be able to
telnet in with the same level of priority that they get when they dial in.
I'm also not sure I'm convinced that going for as few busy signals as
grex gets is a particularily appropriate goal, but I can see both sides
of the argument, and I'm not convinced that the status quo is horible.
|
mdw
|
|
response 88 of 154:
|
May 23 03:30 UTC 2000 |
Re #82, Steve forgot to mention that the same user population that is
more likely to use dial-ups is also more likely to contribute (become a
member) of grex. However, as internet access is becoming more
universal, this isn't as true as it once was.
|
davel
|
|
response 89 of 154:
|
May 23 11:21 UTC 2000 |
I rarely dial in to avoid the queue. From home, I have no ISP, and a dialup
is the only real way to access Grex.
|
gelinas
|
|
response 90 of 154:
|
May 23 18:48 UTC 2000 |
Which is why we need to continue with modems. The question is, how *many*
modems do we need? Can we cut back on the number and still provide the same
level of service?
From what I've seen so far, we can.
|
hhsrat
|
|
response 91 of 154:
|
May 24 20:24 UTC 2000 |
Another point: The less dial-up numbers we have, the less modems we need
to use. The less modems we use, the less power we use. Compared to our
overall power usage, modem-drawn power may be negligible, but if the
modems are power-hungry, getting rid of even 1 dial up line COULD result
in savings on our electric bill.
|
scott
|
|
response 92 of 154:
|
May 24 21:12 UTC 2000 |
Very small savings from electricity.
|
keesan
|
|
response 93 of 154:
|
May 29 23:05 UTC 2000 |
I can be on grex by dialing within 30 seconds of turning on my computer. If
I were to use some browser to access an ISP, and then telnet, it would take
me several minutes longer to get onto grex, and then I get the impression that
things just take longer - I type a word and it does not appear on the screen
as quickly, having to go through the net. I have telnetted to grex from
Netscape 3 and 4 and from Arachne, but I see no advantage at all to direct
dialing with Procomm (which gives me a nice legible screen, too).
|
gull
|
|
response 94 of 154:
|
May 30 03:21 UTC 2000 |
Yes, telnet connections have much higher latency, especially given the
overworked charater of Grex's internet link. I'm usually typing three to
four words ahead of the display when I'm entering a response.
|
mooncat
|
|
response 95 of 154:
|
May 30 15:21 UTC 2000 |
I could dial-i, but I chose not to most of the time. Mainly because I
talk to people via IMs on AOL and messaging back and forth on ICQ. By
telneting in I can be talking to multiple people in multiple places. I
generally don't run across too much trouble with lag, just every once
and awhile AOL gets weird and boots me- but that's obviously not a grex
problem. <grins>
I still get the same legible screens (although for some reason I have a
problem reading conferences when I'm telnetted in) and see several
benefits to being telnetted in.
|
mwg
|
|
response 96 of 154:
|
Jun 6 16:50 UTC 2000 |
I telnet in from home, and legibility is a non-issue because I am running
Linux and telnet from a text-mode console. My biggest legibility issues
from being at the office, where I have to use Windows.
Dialing in is not a serious option for me as I live in Southgate, and A2
is a bit of a haul on a land-line. As for the net.wierdness, it has
always been there, so I don't notice any more, unless it stops completely
or gets VERY delayed.
|
janc
|
|
response 97 of 154:
|
Jul 23 05:20 UTC 2000 |
Some new statistics. I think we still have 11 dial-in lines.
Usage between Mon May 1 00:00:00 2000 and Wed May 31 23:59:59 2000
of IP addresses: 204.212.46.132
0: 220.10 29.59%
1: 248.34 33.38%
2: 154.62 20.78%
3: 75.20 10.11%
4: 32.55 4.38%
5: 10.37 1.39%
6: 1.87 0.25%
7: 0.79 0.11%
8: 0.09 0.01%
9: 0 0
10: 0 0
11: 0 0
Usage between Thu Jun 1 00:00:00 2000 and Fri Jun 30 23:59:59 2000
of IP addresses: 204.212.46.132
0: 162.11 22.52%
1: 199.08 27.65%
2: 155.13 21.55%
3: 108.48 15.07%
4: 54.13 7.52%
5: 25.83 3.59%
6: 9.42 1.31%
7: 3.99 0.55%
8: 0.92 0.13%
9: 0.55 0.08%
10: 0.29 0.04%
11: 0 0
Usage between Sat Jul 1 00:00:00 2000 and Sun Jul 23 01:19:07 EDT 2000
of IP addresses: 204.212.46.132
0: 163.26 30.87%
1: 175.01 33.09%
2: 109.09 20.63%
3: 52.99 10.02%
4: 18.09 3.42%
5: 6.98 1.32%
6: 2.20 0.42%
7: 0.92 0.17%
8: 0.29 0.05%
9: 0.02 0.00%
10: 0 0
11: 0 0
Dial-in use was up a smidgeon in June, but I think that was because of the
M-Net outage.
I think we could be very happy with 6 lines.
|
prp
|
|
response 98 of 154:
|
Jul 23 21:13 UTC 2000 |
And at about $20/mo five lines is $100, or about enough to double the
bandwidth of the Internet connection. That should be good enough to
eliminate the login queue.
|
i
|
|
response 99 of 154:
|
Jul 24 02:19 UTC 2000 |
Isn't the login queue due to a limited supply of virtual tty's on grex
to log in to? Logging in through the internet from work of late, i have
found the keystroke delay rather bad at times, and boosting our internet
bandwidth could help on that front.
|
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.
|