|
Grex > Coop7 > #33: Setting time limits for the new modei on Grex | |
|
| Author |
Message |
steve
|
|
Setting time limits for the new modei on Grex
| 
Apr 17 04:37 UTC 1995 |
Now that the new high-speed (at least for Grex they are) are
in place, there is something we need to discuss about them.
Being newer more configurable units that the 2400bps modei
were, we have the option to set up a time-out in place, such
that after nnn minutes of activity, the modem will hang up.
Right now, that option is in place, set to 20 minutes. After
that period of time with *no* activity on the line, the modem
goes poof, and off that person goes.
In a sense, putting time limits in at the modem level is the
really correct way to do this. What better knows if any activity
is going on there than the modem? This gets around the potential
problems of having a software system on Grex to do this, and get
confused with things like modem transfers, which register as idle
time but really aren't.
We haven't done anything like setting time limits on the modei
before; now we can. I'm not so concerned about time limits for
the ptys (for people coming in over the net) yet. But the dial in
modei are a really scarce resource.
So the question is, do we want to have limits on the high-speed
dialins now? Its easily changed from never timing out, to a time
out only after 90 minutes. If we want time limits, is 20 minutes
too short?
|
| 57 responses total. |
jep
|
|
response 1 of 57:
|
Apr 17 05:38 UTC 1995 |
Are these GVC's, STeve? I never noticed that feature... hmm...
Idle timeouts are a good idea. No one benefits from a modem which is
sitting idle.
Idle timeouts can bite you occasionally. If you start a long process
that won't produce any output for a long time, you might get disconnected
while it's still running. People don't do this a lot.
|
carl
|
|
response 2 of 57:
|
Apr 17 10:09 UTC 1995 |
I agree that it's a good idea, but 20 minutes seems like a short
time to me. There have been several times that I have started
processes that took over 15 minutes to run.
What do you think about an hour of idle time before the snipper
is activated?
|
remmers
|
|
response 3 of 57:
|
Apr 17 11:37 UTC 1995 |
I've done large compiles that run for over an hour (in one case, many
hours) without generating modem activity. However, I generally run
such things in the background so that I can do other stuff, or from a
pty, or "nohup" so that I don't have to be logged in at all while it's
cooking. So I don't see a problem with a fairly short idle tolerance,
like 20 or 30 minutes. Since the dialins are such a scarce resource,
it's probably a good idea. I agree that the modem is an appropriate
entity to be doing the idle detection.
|
mcpoz
|
|
response 4 of 57:
|
Apr 17 13:14 UTC 1995 |
Isn't there some way to monitor to see if processes are running which
do not generate modem activity?
|
steve
|
|
response 5 of 57:
|
Apr 17 13:21 UTC 1995 |
Oh yes, there are, and we can (and will have to, eventually) do that.
It just has to be smart; idle time alone doesn't count--the program has
to look at all the processes attached to that tty, and then determine
if that tty is truely idle.
But for now, all we need worry about is the dialins.
I'm thinking that we should probably up the time to 30, 35 minutes.
|
steve
|
|
response 6 of 57:
|
Apr 17 13:22 UTC 1995 |
Oops, forgot to answer you John; yes, these are the GVC modei.
They have a lot of interesting features.
|
popcorn
|
|
response 7 of 57:
|
Apr 17 14:03 UTC 1995 |
Ja, 30 minutes sounds about right.
Does nohup work for you, John? It used to work for me, but nowadays
I think I've been getting zapped by the idle-process-zapper when I use it.
|
remmers
|
|
response 8 of 57:
|
Apr 17 20:32 UTC 1995 |
Not sure if I've used nohup recently or not. But why should the
idle-process-zapper zap a process that's not idle, I wonder?
|
jep
|
|
response 9 of 57:
|
Apr 18 01:27 UTC 1995 |
Thanks, STeve. I had clearly better do some more manual-reading. I
see no reason why we can't use this feature for M-Net; it will probably
work better than the program we are currently using (untamo).
|
steve
|
|
response 10 of 57:
|
Apr 18 03:02 UTC 1995 |
The downside of course, is that if I'm doing some staffly thing
for Grex and it takes a while to do, I might get zapped.
John (remmers), the idle zapper script will kill things that are
not owned by root, left in the background. I believe it runs every
15 minutes.
John (Perry), I think you want to look at \\T0 thats the option.
|
scg
|
|
response 11 of 57:
|
Apr 18 03:40 UTC 1995 |
Do Do these modems send out some sort of warning before dropping the
connection? I've had some rather unpleasant experiences with idles
killers that did it without warning. Even if it can't, if the time limit
is set high enough it would probably become a non problem, and I suspect
it will free up not just modem time, but also some of the staff time that
is currently spent knocking off long idle connections, so it does seem
worth doing.
|
steve
|
|
response 12 of 57:
|
Apr 18 04:54 UTC 1995 |
No, it won't warn. The modem takes the UNIX approach, and does
it silently.
If we think that 30 minutes is a good idea, then setting it to
40 would get around just about all the unintentional hangups.
|
ajax
|
|
response 13 of 57:
|
Apr 18 05:58 UTC 1995 |
30 sounds good to me. 20 sounds short. Cool feature for a modem!!
|
steve
|
|
response 14 of 57:
|
Apr 18 13:08 UTC 1995 |
About time, I think.
|
nephi
|
|
response 15 of 57:
|
Apr 18 17:25 UTC 1995 |
I don't like 40. Thirty sounds pretty good.
|
nephi
|
|
response 16 of 57:
|
Apr 18 17:27 UTC 1995 |
And what's the deal with the idle zapper program script?
If I FTP in the background will it zap it?
|
steve
|
|
response 17 of 57:
|
Apr 19 00:40 UTC 1995 |
If you log off, yes. It will become fodder for the orphan process
killer.
|
nephi
|
|
response 18 of 57:
|
Apr 19 11:21 UTC 1995 |
Oh, okay. Thanks.
|
tsty
|
|
response 19 of 57:
|
Apr 19 20:02 UTC 1995 |
yes, idle-zappers can cause a lot of "unintended consequence" problems,
me having run square into most of them on "another system."
And, btw, some perns are permitted to nohup stuff, some aren't, it
depends on the root who is investigating at the time.
|
jep
|
|
response 20 of 57:
|
Apr 20 04:01 UTC 1995 |
Thanks, STeve. Once you mentioned that it exists, I went ahead and
looked it up. It was right there.
Today at work I worked with a Motorola UDS modem, and since I had a
little time with nothing to do but wait for a customer for a couple of
minutes, I checked to see if the UDS had an idle timer. It was right
there -- \Tnn, default of '0'. This might be something of a standard.
I'll probably check a lot of different modems as I encounter them, to see
if this is fairly common. Very nifty feature!
|
scg
|
|
response 21 of 57:
|
Apr 20 04:49 UTC 1995 |
I checked the manual for my USR Sportster. Its idle timer is set with
s19=n with a default of 0.
|
n8nxf
|
|
response 22 of 57:
|
Apr 20 13:36 UTC 1995 |
/Tn for this internal Macronics MX from CCS...
|
popcorn
|
|
response 23 of 57:
|
Apr 20 13:54 UTC 1995 |
Re 19: TS, *anybody* with a lot of idle time on a dial-in is likely
to be disconnected by a staffer. *You are not being singled out.*
In fact, after you got so upset the one time I disconnected you,
you're probably a lot *less* likely to be disconnected by a staffer
than any other user. Is that fair?
|
tsty
|
|
response 24 of 57:
|
Apr 21 10:30 UTC 1995 |
I never presume to be "singled out," as I keep saying over and over
and over again. Please do not consider "singled out" unless or
until it is brought up in a "challenge" first.
|