|
Grex > Coop9 > #10: Reducing the number of telnet ports |  |
|
| Author |
Message |
ajax
|
|
Reducing the number of telnet ports
| 
Nov 24 08:11 UTC 1996 |
There was recently a suggestion in another item about reducing the
maximum number of ptys (or "telnet ports") available to users at one
time. I think it's a big enough issue to be worth having a separate
item for it. Here are six responses about this so far:
>#31 of 36: by Rane Curl (rcurl) on Fri, Nov 22, 1996 (12:37):
> Forgetting inuendo and all that, I perceive what STeve does, with regard
> to the difficulty of using Grex for either simple pleasure or for more
> serious pursuits, because of its slow speed (not to mention outages). I
> find no fault with the introduction of innovative ideas, but it seems to
> me that if the system is a pain to use, there are negative effects upon
> both use and perceptions. I suggest that steps be taken to make the system
> respond at a "reasonable" rate for both staff and users, by placing limits
> on some resource hogs (perhaps mail and ftp), and/or cutting back on the
> max logins and backtalkins, etc.
>
>#32 of 36: by Michael O'Leary (nephi) on Sat, Nov 23, 1996 (17:22):
> (I wonder what would happen if we reduced the number of pty's by six?)
>
>#33 of 36: by STeve Andre' (steve) on Sat, Nov 23, 1996 (19:43):
> Not that much--I think that interactive telnet sessions pale
> behind that of mail, ftp, Lynx, and the other things we d.
>
>#34 of 36: by Michael O'Leary (nephi) on Sat, Nov 23, 1996 (22:49):
> I'm not necessarily arguing for this -- just seeing how others feel . . .
>
> But if we cut down on the number of people who can use Grex, we will
> be cutting down on the number of people who can be sending email, the
> number of people who can be using lynx, etc. The telnet sessions
> themselves aren't what slows Grex down, but the things people do over
> those telnet sessions.
>
> Now that we have a queueing and Backtalk, people who want to use the
> conferences are always guaranteed that they can do so. For once, we
> finally have the ability to start guaranteeing a certain speed to
> conference-goers. Is this something we want to persue?
>
>#35 of 36: by STeve Andre' (steve) on Sun, Nov 24, 1996 (02:12):
> I'm sure there is a coorelation between the number of users and
> the amount of mail received on Grex, but I don't think we have any
> idea how that will work out in practial matters. If we made it much
> harder for people to get in here for example, there would still be
> the mail for those denied access to Grex, piling up.
>
> I'd think that it might take 90 days for any real test of
> reductions in mail service to prove themselves.
>
>#36 of 36: by Rane Curl (rcurl) on Sun, Nov 24, 1996 (02:29):
> OK. A 90 day test. Go for it.
|
| 52 responses total. |
ajax
|
|
response 1 of 52:
|
Nov 24 08:36 UTC 1996 |
I favor lowering the maximum ptys. The load average goes up a
disproportionate amount as those last few users are on-line. Here's
some data from a recent 30-day period:
Mean
Users Load Sample
Online Avg. Size
----- ----- ------
20 1.76 14
30 2.57 88
40 4.36 127
50 6.03 169
60 8.57 214
70 14.80 160
When 70 users were online, the load average averaged about 15; when
60 users were online, it averaged about 9. Reducing the maximum ptys
by 5 would probably reduce the load average at those peak usage times
by around 3, or 20%, on average.
There would be some longer-term effects as well, as STeve describes,
but it seems very likely that a measurable speed improvement at peak
usage periods would occur immediately. I haven't seen any evidence
to the contrary.
|
janc
|
|
response 2 of 52:
|
Nov 24 20:30 UTC 1996 |
Hmmm. I wasn't over much in favor of this at first, but Rob's data is
compelling.
|
popcorn
|
|
response 3 of 52:
|
Nov 24 22:41 UTC 1996 |
I agree that it makes sense to lower ptys.
I'm wondering if the really high load averages could be due to big telnet
queues of people waiting to get in. If a telnet waitlist can pump up the load
average, then lowering the number of ptys won't help the situation; it will
just trade on-line users for users in the queue.
Still, I think the best way to find this out would be to try it and see.
If it doesn't help, we can always add the 6 ptys back again. It's an easy
change to make.
|
janc
|
|
response 4 of 52:
|
Nov 25 01:48 UTC 1996 |
Ah. If that is true, then it would explain (1) why we sometimes have really
huge load averages with no apparant problem processes, and (2) why there is
a steep increase in load average as we reach near saturation in Rob's data.
If it is true, then reducing the number of ptys will give us the same
increased load as the system hits the new pty limit. So instead of preventing
the high loads from occurring, it will cause them to occur sooner, with fewer
users on Grex.
|
e4808mc
|
|
response 5 of 52:
|
Nov 25 05:27 UTC 1996 |
It's me again. What does this do to "users like me"?
|
arthurp
|
|
response 6 of 52:
|
Nov 25 06:14 UTC 1996 |
Well, a test would be a good way to find out if the load increase is from the
queue. It doesn't have to be permanent.
|
ajax
|
|
response 7 of 52:
|
Nov 25 09:51 UTC 1996 |
Catriona, some people think it would make no difference to you,
others think it would mean maybe a 25% faster response time when
Grex is crowded. Nobody knows for sure.
Re 3, it crossed my mind that the login queue contributes to the
load average during peak usage periods. However, I think it's
a small effect. Here's why:
The load average does not increase linearly before all the ptys fill
up. At 30 users, each extra user adds about 0.12 to the load average.
At 40 users, the number is 0.16. At 50 users, 0.25. At 60 users,
0.33. And at 70 users (though the data sample is smaller), each extra
user is met with a 0.56 higher load average. So the effect of each
user having a greater impact when more users are on is evident even at
low user levels, long before the login queue kicks in.
The exact portion of that 0.56 (added for the 70th user) that's due
to the login queue is debatable, but based on the values for lower
numbers of users, it appears very unlikely that it's more than 0.15,
and it's possibly a lot less. So reducing the ptys by one would
almost certainly be expected to drop the average load average by at
least 0.41 when there are 70 users online. (Given all the other
conditions in this data being held constant, which is never true given
Grex's dynamic nature :-).
|
scg
|
|
response 8 of 52:
|
Nov 25 17:54 UTC 1996 |
I'm not entirely convinced by this. It seems likely that the times of day
when we get the most users are also the times when we're getting hit hardest
by mail and the like.
|
tsty
|
|
response 9 of 52:
|
Nov 25 18:26 UTC 1996 |
we already have a limit on ptys. from the sense of usage (which was
discounted until VeryRecently) and the collected data ( which demonstrates
that sense counts), a reduction of 12 ptys seems more in order for
**testing** purposes, inching upward by 1 or 2.
first make a predictably dramatic change and then boil the frog again
slowly.
|
albaugh
|
|
response 10 of 52:
|
Nov 25 20:09 UTC 1996 |
less-pty's + faster-CPU = happier connected users
|
scg
|
|
response 11 of 52:
|
Nov 25 20:53 UTC 1996 |
But it also means that it takes longer to connect.
|
dang
|
|
response 12 of 52:
|
Nov 25 21:22 UTC 1996 |
This item is linked to coop9.
|
e4808mc
|
|
response 13 of 52:
|
Nov 25 23:35 UTC 1996 |
As one who is likely to see effects immediately, I say go for it. We can mess
around for a while and see what makes the most sense.
|
arthurp
|
|
response 14 of 52:
|
Nov 26 01:49 UTC 1996 |
As users are added more shells and such like load. As more memory is taken
up by such like, less pool is available for caching disk activity. As cache
size goes down, swapping, goes way up. The extra people are blowing away our
performance. (Assuming all free memory is used to cache in SunOS).
|
davel
|
|
response 15 of 52:
|
Nov 26 11:22 UTC 1996 |
I think that most of the time we don't have *any* free memory here, most
likely. We're probably swapping people out to disk ... and that's a good
chunk of the performance drain - the higher the percentage of things being
swapped, the more likely that *your* processes are swapped, and the more time
you wait for things to swap in & out.
|
janc
|
|
response 16 of 52:
|
Nov 26 16:00 UTC 1996 |
I've seen some people say that when they are on the telnet queue, they fire
up backtalk while they are waiting. This is another factor that tends to make
load rise when the queue is long.
|
albaugh
|
|
response 17 of 52:
|
Nov 26 17:53 UTC 1996 |
It might take longer to get connected, but when you (finally) *are* connected,
you'll like it better...
|
rcurl
|
|
response 18 of 52:
|
Nov 26 19:25 UTC 1996 |
That's life.....
|
krj
|
|
response 19 of 52:
|
Nov 26 21:04 UTC 1996 |
Faster response should mean that mail and conference users do what
they want to do and log out more quickly. Theoretically.
But party users won't be on any shorter.
|
dang
|
|
response 20 of 52:
|
Nov 26 22:56 UTC 1996 |
But party is being included in the "Conferencing" that we want to improve,
at least in this case.
|
ajax
|
|
response 21 of 52:
|
Nov 27 05:58 UTC 1996 |
Re 19, *very* theoretically :-). Speaking only for myself, I know I
read more conferences when Grex is responding quickly. If it's dog
slow, I'll usually join two or three conferences, while if it's faster,
I'll check for new responses in my list of 15 or so conferences, and
maybe a conference or two not in my regular list.
For e-mail, Grex's speed doesn't affect me as much. I receive the
same number of messages either way (well, aside from speed-related
delivery problems), and if I'm replying, most of the time is spent
composing the reply in a local editor. There isn't unexplored e-mail
to read like there is unexplored conferences, since I read all my e-mail.
|
dpc
|
|
response 22 of 52:
|
Nov 27 14:35 UTC 1996 |
M-Net has a spiffy new "pty limiter" which Grexians are invited to
check out. Karyl Stein has explained it in Item 235 of M-Net's
Sysop Conference. Basically, it allows incoming telnetters access
to differing numbers of ptys depending on whether they are
M-Net members/patrons/staff or M-Net guests. Karyl is still testing
this infernal device, but plans on opening up the code soon.
I think the pty limiter could be of use to Grex as well.
|
kerouac
|
|
response 23 of 52:
|
Nov 27 18:48 UTC 1996 |
But how can m-net tell if an incoming telnet is a guest or a
member until they log on, at which point they have established
their pty? Are you saying that if a guest logs on with a member
pty that they will be logged back off by the system, with a
response like "sorry, this port reserved for a member?"
|
robh
|
|
response 24 of 52:
|
Nov 27 20:02 UTC 1996 |
Actually, that would be pretty easy to do. (Easy in relative terms,
of course.)
|