|
Grex > Coop8 > #146: Reducing the number of telnet ports |  |
|
| Author |
Message |
| 25 new of 52 responses total. |
kerouac
|
|
response 25 of 52:
| 
Nov 27 20:32 UTC 1996 |
I think if ptys are reduced, the countdown que should be
removed. One makes the other less necessary.
|
dang
|
|
response 26 of 52:
|
Nov 27 22:02 UTC 1996 |
re 25: What? It should be the other way around. If there are enough ptys
that the telnet queue is unnecessary, then don't use it. If ptys are reduced,
there should be more use for the telnet queue than every, so I would think
it should stay.
|
ajax
|
|
response 27 of 52:
|
Nov 27 23:50 UTC 1996 |
> how can m-net tell if an incoming telnet is a guest or a
> member until they log on...
M-Net doesn't necessarily need to. They could theoretically
have two IP addresses that get to the same machine, one for
guests, one for members, similar to having different phone
numbers for guests and members.
> I think if ptys are reduced, the countdown que should be
> removed. One makes the other less necessary.
I'm with dang: I think just the opposite is true.
|
nephi
|
|
response 28 of 52:
|
Nov 29 03:43 UTC 1996 |
Number 25 made me laugh.
Thanks Richard!
|
tsty
|
|
response 29 of 52:
|
Nov 29 05:42 UTC 1996 |
one of the cnsiderations voiced somewhere above was that if grex gets
too fast (too little lag/load) that we are indanger of becoming some-
thing akin to an isp, which grex is not.
i had to think abouthat for a while.
i agree with it now.
but how slow does grex have to be to stay non-isp-ish?
not this slow.
|
dang
|
|
response 30 of 52:
|
Nov 29 18:24 UTC 1996 |
I would say something less than the current standard for ISPs, would be my
guess. I would say that the partitioning scheme would drastically reduce the
chances of grex becoming an ISP. Or, rather, grex would remain a good
conferencing system, and the other computer may or may not become and ISP,
depending on how loaded it and it's link are. That shouldn't affect grex too
much, tho.
|
kerouac
|
|
response 31 of 52:
|
Dec 2 16:08 UTC 1996 |
re: wayback there...I was misunderstood in my comments about the
countdown que in relation to cutting ptys. If you cut the number
of telnet ports in half, you will have wait lists twice as long at
times. So what I was saying is that with half as many ptys,
the countdown que will be far more of an impediment to users
coming here at all.
I think the que needs to have a max of thirty or forty if ptys
are cut. Noone should have to try to grex and end up sixty or seventy
in the que because there are only half as many ports.
So absent a cap on the countdown, I dont think the que is desireable
or as desireable with fewer ptys, even though it seems logical that
it would be.
|
orinoco
|
|
response 32 of 52:
|
Dec 2 23:09 UTC 1996 |
Just a question, how does backtalk affect the amount of strain on grex? Some
people have been talking about it like it uses less processor time than
regular conferencing, others have cited it as one of the problems. If backtalk
*does* use up significant amounts of time, would limiting the number of
backtalkers be feasible?
|
rcurl
|
|
response 33 of 52:
|
Dec 2 23:11 UTC 1996 |
Queues are somewhat self-controlling. If the queue is too long, some
people will quit it - but others will just hang in there and do something
else, since it costs very little. So the question is, what is the relation
between the number of ptys and the average length of the queue? There was
also some talk at one time of checking, on long queues, to see if users
were still there: they had to respond to a bell and question within a
short time, or be dumped from the queue. I doubt very much, in any case,
if the ptys were halved, that the queue would double. In fact, we can do a
differential test by reducing the ptys by 10%, and measure the increase in
the average length of the queue.
|
kerouac
|
|
response 34 of 52:
|
Dec 2 23:38 UTC 1996 |
might be a worthwhile experiment at that...need to study whether
longer ques adversely affects user participation.
But it is only logical that ifyou have a four lane highway and
it is cut to two lanes, that the traffic in the two lanes is going to be
twice as long. Either that or fewer people will use the highway at all.
|
janc
|
|
response 35 of 52:
|
Dec 2 23:49 UTC 1996 |
Backtalk places significantly more load on Grex than telnetting in and using
Picospan. I don't really know if it is bad enough to be considered a real
resource hog. I hope in the longer range future we will be able to make
design changes that will improve its performance.
|
scg
|
|
response 36 of 52:
|
Dec 2 23:50 UTC 1996 |
Right, Richard, and when the people using the road don't all fit, you get a
traffic jam, which is a sort of queue where peopel line up to be the first
out the other end of it. It's not a particularly pleasant situation, but I
don't think anybody would argue that it would work better for drivers, upon
encountering a traffic jam, to repeatedly back off, and then ram their car
into the car in front of them.
|
rcurl
|
|
response 37 of 52:
|
Dec 3 08:09 UTC 1996 |
A proportional relation between a traffic queue and the number of lanes is
also false. For one thing, the traffic in all lanes is the same length
(from whichever two points you measure it). There are also many cases
where average speed is not affected at all by the number of lanes (if at
least 2 8^}). The "traffic formula" is vey nonlinear anyway, and the
relation for a queue here would be different. So - try it out....
|
davel
|
|
response 38 of 52:
|
Dec 3 10:26 UTC 1996 |
Re 32: Daniel, IMNAAHO trying to limit the number of backtalk users would
be a Very Bad Idea. The problem is that unlike telnet (& most other stuff),
web access doesn't normally maintain a connection. Instead, every time you
click on something, it resolves the address of what you've clicked on, opens
a connection, & reads the entire document (or whatever) involved, then closes
the connection. So imagine that you're reading a Picospan item, and you
decide to respond (or to read the next item), but you get a message saying
"sorry, too many users, try again later". Or imagine a queue implemented per
access for such situations. Personally I think I'd give up Grex before
putting up with either of those.
|
albaugh
|
|
response 39 of 52:
|
Dec 3 17:13 UTC 1996 |
But you *do* get the "too many users..." message at popular web sites,
especially ftp sites. Most users will then hit the "Reload" button until the
URL they're interested in is finally "serviced".
|
janc
|
|
response 40 of 52:
|
Dec 3 18:02 UTC 1996 |
Dave points his finger right on the reason that limits on Backtalk are hard
to implement. It is possible to do though. Not real soon.
|
remmers
|
|
response 41 of 52:
|
Dec 3 18:16 UTC 1996 |
It's an interesting problem, though. One way to approach it
might be to put a limit on the number of simultaneous
authentications that Backtalk will accept, and have an idle
timer that removes an authentication if the user hasn't done
anything for a while.
|
janc
|
|
response 42 of 52:
|
Dec 3 23:39 UTC 1996 |
That's what's Caucus does. It's a real pain when your conneciton times out
while you are composing a long response.
|
remmers
|
|
response 43 of 52:
|
Dec 4 12:56 UTC 1996 |
Good point. I've been pained by that behavior myself.
|
krj
|
|
response 44 of 52:
|
Dec 4 17:00 UTC 1996 |
Also, an idle authentication isn't tying up resources, is it?
|
janc
|
|
response 45 of 52:
|
Dec 4 18:22 UTC 1996 |
Not much. I certainly will be looking into schemes involving hold connections
open in the future. Yet another configurable option. Oh joy.
|
srw
|
|
response 46 of 52:
|
Dec 4 19:00 UTC 1996 |
Yeah. There's a lot of speedup that can be inserted quickly be turning
on code optimization. On a Sparc platform, this will help a lot.
Even more can be accomplished with compiled scripts. That is a
significant development effort that we haven't begun, although the
architecture supports its development in the future.
Ultimately we may decide to hold connections like Caucus. Jan and I
talked about this a good bit during Backtalk's formative sessions. We
rejected it then, and quite frankly, I'm still not sure it will buy very
much performance. The compilation offers the most promise, as it will
zero out most of the symbol table lookups at run-time.
--
Now to get back on topic (reduce ptys, remember?)...
I think it makes sense to drop them for a few weeks, and compare the
numbers. I think it will make sense to up them again when our
infrastructure improves, but the net result should be slightly better
response from the system for any given individual. Grex is too slow
right now.
Even a faster Grex will never truly compete with an ISP as long as it
does not offer PPP to local dialups. (Limited PPP to just our subnet
doesn't count.)
|
dang
|
|
response 47 of 52:
|
Dec 5 23:37 UTC 1996 |
That's something I didn't even think about, and quite true. A shell dialup
only ISP is a very hard thing to find.
|
tsty
|
|
response 48 of 52:
|
Dec 7 07:50 UTC 1996 |
is there a "way" to separate backtalk users from the generic telnet user?
|
scott
|
|
response 49 of 52:
|
Dec 7 14:02 UTC 1996 |
Yes, since they don't telnet! They use the http server instead, since
Backtalk is completely Web-based.
|