|
|
| Author |
Message |
| 25 new of 239 responses total. |
adbarr
|
|
response 125 of 239:
| 
Jan 20 12:37 UTC 1996 |
Sounds rational to me.
|
chelsea
|
|
response 126 of 239:
|
Jan 20 13:45 UTC 1996 |
Re: #116 I don't recall where a 20 minute idle timeout was discussed
at length. I probably just missed it or unremembered it. Valerie,
do you remember where and when it was? I'll look it up.
|
scott
|
|
response 127 of 239:
|
Jan 20 13:52 UTC 1996 |
Last coop? I remember it too. It was something the GVC modems could be
programmed to do.
|
davel
|
|
response 128 of 239:
|
Jan 20 14:44 UTC 1996 |
Try further back than that, I think. But I also remember it.
|
scott
|
|
response 129 of 239:
|
Jan 20 19:18 UTC 1996 |
Less than a year ago, if I would have seen it.
|
kaplan
|
|
response 130 of 239:
|
Jan 20 20:24 UTC 1996 |
I think there are two different issues here. Or maybe it's me that's
confused. But earlier in this item I thought we were talking about idle time
as in not using any CPU time. But if a staffer is compiling something and
it's taking a long time without sending anything to the terminal, that's tty
idle time, but not CPU idle time. The smart modems hang up on you if nothing
goes across the phone line even though the CPU has been working on something
for you. I found out about that the hard way recently. So what kind of idle
time does the idle killer on m-net look for?
|
mdw
|
|
response 131 of 239:
|
Jan 20 20:32 UTC 1996 |
We've got plenty of swap space. Idle users don't contribute to load
average. If we're running out of ports, and have idle users, the
obvious solution is to add more pty's. An idle killer will only waste
CPU - given that we're already CPU saturated, this seems a poor use of
scarce resources.
|
kerouac
|
|
response 132 of 239:
|
Jan 21 00:58 UTC 1996 |
#131...yeah good point...I dont think its stretching staff's time to
manually log off anyone who's been idle for forty five minutes or an
hour. The work an idle killer would save would hardly be worth the cpu
time (unless there really ARE so many excessively idle users)
|
scott
|
|
response 133 of 239:
|
Jan 21 03:29 UTC 1996 |
Unless you count the CPU time it takes a staffer to find the idles, login as
root, and kill the processes. Not to mention staffer time...
|
tsty
|
|
response 134 of 239:
|
Jan 21 06:03 UTC 1996 |
wasn't this the "growth of grex" item, drift notwithstanding?
|
scg
|
|
response 135 of 239:
|
Jan 21 08:30 UTC 1996 |
Greg's proposed random solution still doesn't address the staff functions that
require idle time, like compiling stuff. Not all staff people have extra Suns
to compile things on.
|
robh
|
|
response 136 of 239:
|
Jan 21 11:29 UTC 1996 |
Or running restores, or even back-ups.
|
mdw
|
|
response 137 of 239:
|
Jan 21 13:09 UTC 1996 |
There certainly wasn't any formal periodic poll for idle users by staff
- until the recent spat of "no ports", I would say that staff only
occasionally had to look for idle users, and then only for the dial-up
modems, not for pty's. The frequency of crashes pretty much keeps
people from logging on for days at a time.
|
popcorn
|
|
response 138 of 239:
|
Jan 21 18:04 UTC 1996 |
I've been checking for idle users and logging them off lately 2 and 3 times
a day. At a guess, I'd say it takes 10 minutes each time I do it. So that's
20-30 minutes a day, assuming the system is running reasonably fast.
If it comes to it, I'd rather automate it.
|
sidhe
|
|
response 139 of 239:
|
Jan 21 19:52 UTC 1996 |
If an Idle-Killer is what you're going for, I think an hour time limit
should be sufficient.. but I agree with carson- why should
staff be the only exemptions> What if someone else, non-staff is compiling
something?
|
scg
|
|
response 140 of 239:
|
Jan 21 19:53 UTC 1996 |
But Marcus has a good point. Idle users aren't using Net bandwidth, or CPU
time, and the purpose of limiting the number of ptys is to insure that there's
enough Net bandwidth and CPU time for the active users. Might it be better
to add the average number of idle users on top of the acceptable number of
active users when deciding how many ptys to have available, and then make a
point of not killing off idle users (unless, or course, there was a really
excessive number of them)?
|
scg
|
|
response 141 of 239:
|
Jan 21 19:57 UTC 1996 |
sidhe slipped in. Grex does currently make its compiler available to non
staff people, and probably should continue to do so. Still, when staff are
compiling something, it is generally for Grex, while if non staff are
compiling something , it is generally for themselves. The whole purpose of
limiting the number of ptys, which is what has prompted this whole idle killer
thing, is the need to keep CPU usage as low as possible while still allowing
Grex to function for conferencing, party, and mail, and compiling uses a lot
of CPU time. I don't think we really want random people compiling big things
here, given our current hardware limitations, without at least telling us
about it first. If we built exceptions into the thing, it would presumably
be pretty easy to add people if they needed to be added.
|
ajax
|
|
response 142 of 239:
|
Jan 22 03:42 UTC 1996 |
I actually waste extra CPU cycles defeating the modem timeout when I'm
running a slow program. I tail the uptime log with the --follow option,
so it outputs a new line to my screen once a minute. (I should write a
local macro to send a char once a minute, but haven't gotten around to it).
Personally, I'm in favor of limiting ptys, but I agree with Marcus'
reasoning: if the only reason for killing idle jobs is to avoid the "out
of ports" message, the best solution is to increase the number of ports.
|
tsty
|
|
response 143 of 239:
|
Jan 23 06:53 UTC 1996 |
the balalnced solution, though, is to keep the #ports about the
same and the modei speeds about the same, so that ..... each login
has .... approximately the same performance result.
|
carson
|
|
response 144 of 239:
|
Jan 23 13:01 UTC 1996 |
I also wonder if the "staff should be idle in case something goes wrong
and a staffer needs to get to the system in a hurry" mantra is
erroneous. Has a staff person ever needed to get on to the system and
have not been able to?
|
ajax
|
|
response 145 of 239:
|
Jan 23 20:18 UTC 1996 |
I'm pretty sure it has, but a separate staff-only modem line was approved
not long ago, which addresses that issue most of the time. Though sometimes
people have telnet access but no modem, and GregC the Idle Connection King
can no doubt elaborate on the benefits of idle telnet connections. :-)
|
scg
|
|
response 146 of 239:
|
Jan 24 06:18 UTC 1996 |
Also, while I don't think it happens very often, it's possible for Grex to
get put in a state where nobody can log in, but people who are logged in can
stay logged in. If a staff person is logged in and can fix it, that can save
a trip to the Dungeon. Then again, I don't think that happens often at all.
I'm more concerned about staff not being forced out while trying to do staff
things that require idle time. I don't think we'd want to put staff in a
position where anything that had to be compiled had to be compiled from the
Dungeon. There's no point in making things harder for people who are already
volunteering their time as it is.
|
ajax
|
|
response 147 of 239:
|
Jan 24 08:45 UTC 1996 |
I agree that if code has to slowly percolate through a compiler, a person
shouldn't need to sit around typing stuff to avoid logoff. However, the
idle killer may not do that anyway, or there may be workarounds that would
work for anyone, not just staff. Depends on how the idle killer works.
A special exception for staff may be unnecessary.
|
popcorn
|
|
response 148 of 239:
|
Jan 24 14:31 UTC 1996 |
The reason for leaving a staffer logged in is a security concern. There's
at least once when it's saved Grex's butt, because people who weren't already
logged in couldn't log in, and an alert staffer managed to rescue us.
|
tsty
|
|
response 149 of 239:
|
Jan 24 17:06 UTC 1996 |
more'n once .....
|
