|
|
| Author |
Message |
| 21 new of 270 responses total. |
gregc
|
|
response 250 of 270:
| 
Oct 10 21:40 UTC 1995 |
Selena, when we move to the Sun-4, if we limit total connections to a
total of 48, including modems. The system will be alot more
responsive.
|
steve
|
|
response 251 of 270:
|
Oct 10 23:59 UTC 1995 |
(or keep the modei and 48 additional pty's for the net, and we'll
still be a LOT more responsive.)
Earlier today when in vi composing mail, the system was so slow
that I was getting multi-second character delays in getting what
I typed back to me, and I was on the *console*. I was rather impressed
by that.
|
srw
|
|
response 252 of 270:
|
Oct 11 03:58 UTC 1995 |
It stands to reason that if there is no other limit but netlag and
CPU lag, that Grex will fill with users until the average user who
hasn't logged off in disgust can just barely tolerate the performance.
Grex is in a negative feedback loop with its users that guarantees this.
Grex's users have different levels of tolerance of slowness. We have
selected during peak times for those with the greatest tolerance.
(Mostly partiers) This is all completely natural, not surprising,
but not necessarily good.
|
selena
|
|
response 253 of 270:
|
Oct 11 04:21 UTC 1995 |
Nor bad.
|
lilmo
|
|
response 254 of 270:
|
Oct 11 04:51 UTC 1995 |
Grex is too slow when 'who' takes THREE minutes, and the connection times out
while waiting for Grex to send the rest of a mail message !! (These both
happened to me Tue afternoon).
|
selena
|
|
response 255 of 270:
|
Oct 11 05:33 UTC 1995 |
the cpnnection timeout i've had happen when there was 26 people on.
|
sidhe
|
|
response 256 of 270:
|
Oct 11 15:43 UTC 1995 |
Like I said _way_ ack there, give it a "silent" try. If it works,
fine, if not, then get rid of it posthaste.
|
janc
|
|
response 257 of 270:
|
Oct 11 19:08 UTC 1995 |
Well, I don't know. I get most of my house-keeping done while waiting for
Grex to execute commands. But I guess I'm one of the people who have adapted
to Grex as it is.
|
mlady
|
|
response 258 of 270:
|
Oct 13 19:16 UTC 1995 |
Well, I'll tell you one thing- you didn't keep any members for your
quick decision-making skills.
|
rcurl
|
|
response 259 of 270:
|
Oct 13 21:41 UTC 1995 |
Hah! You have barely seen how slow we can be!
|
ajax
|
|
response 260 of 270:
|
Oct 13 21:41 UTC 1995 |
Non-critical decisions tend to be made slowly on Grex. :-)
Especially those needing board action, as they meet once a month.
Not to put an end the last discussion, but here's another suggestion.
The few times I've been to Grex's dungeon, the monitor on gryphus (sp?)
was always powered on. Is it still that way? I realize the monitor
probably only uses 15 KWh (a buck or two worth) a month. But
conserving electricity is no bad goal, and it would save us a bit of
money if we're that precise in measuring our consumption (or it would
save our landlord some money). The only reason I can see for leaving
it on is wear and tear caused by powering it on and off, but that seems
an even more negligible cost. Also, how about the console terminal
hooked up to Grex? Or are there other reasons to leave that on?
|
davel
|
|
response 261 of 270:
|
Oct 13 21:47 UTC 1995 |
It's a dumb terminal, right? Then it should be ON. System messages
which may come to it would be lost if it were off, if it's not merely
a monitor whose memory resides in a PC or something like that.
Possibly also it may generate breaks & crash the system if turned off.
(Gryps's monitor is another matter, of course. I think I'm in agreement
with you there.)
|
gregc
|
|
response 262 of 270:
|
Oct 13 23:17 UTC 1995 |
There is no reason gryphs montior should be left on, but I've found it
on many times too, and it annoys me too. There is no reason to waste power
and create more heat from that.
Unfortuneatly, the terminal on Grex's console must be left on. If shut off,
the serial interface will produce a <BREAK> condition that will cause the
Sun's monitor program to halt. And grex will be down until someone typs a "c"
on the console. Also, if the machine crashes, it's always useful to
see what the last thing sent to the console was.
|
janc
|
|
response 263 of 270:
|
Oct 14 01:35 UTC 1995 |
Aren't all console messages logged someplace? One could probably wire up
the terminal's interface so that powering down doesn't do a break...but
then, the staff line project will probably obsolete the terminal anyway,
so that may not be worth worrying about.
|
ajax
|
|
response 264 of 270:
|
Oct 14 05:27 UTC 1995 |
Since a frequent cause of Grex crashes is a disk problem, logging
console messages to disk may not log the final pre-crash messages
(if the messages are along the lines of "can't write to the disk").
|
mdw
|
|
response 265 of 270:
|
Oct 14 11:35 UTC 1995 |
I've nearly always found the gryps monitor turned off; and try to leave
it turned off as well. Yes, unfortunately, the grex console should be
left on; that last panic/monitor message can occasionally be crucial.
|
selena
|
|
response 266 of 270:
|
Oct 15 04:24 UTC 1995 |
It's always about *power* isn't it?
:}
|
popcorn
|
|
response 267 of 270:
|
Oct 15 05:45 UTC 1995 |
Ditto to what Marcus said about Gryps's monitor in #265.
Also, the brightness on the console is usually turned *way* down
when I get there, and I turn it way down again before I leave.
|
sidhe
|
|
response 268 of 270:
|
Oct 16 16:14 UTC 1995 |
Indeed? What critcal decisions are made any faster, rob?
|
ajax
|
|
response 269 of 270:
|
Oct 16 18:35 UTC 1995 |
(268 was re: 260, for those who are lost :-).
Staffers make decisions daily that don't warrant board consideration,
but occasionally something comes up (say, locking out an account) that
would warrant consideration, but timeliness is deemed more important.
Security/uptime-related decisions are often made quickly, before the
normal wait-till-board-meeting cycle, but they aren't always discussed
publicly.
(Btw, re: powering off the monitor, guess my sample size was too small;
I thought the monitor was intentionally left on...glad to hear it's not!)
|
sidhe
|
|
response 270 of 270:
|
Oct 18 23:59 UTC 1995 |
Alright, point taken.
|