The current number of ptys for non-local users (i.e. coming in from some place other than the terminal server, groupie) has been set at 64 for several weeks now. This number was changed up from 56 when grex moved to the new machine. Has there been data collected on the perceived performance difference between the two settings? If so, has any analysis >been done on this data to determine if the number could be increased >even more? The reason I ask is because although the increase to 64 was great, there is still often a queue forming. Now, the queue can't be eliminated completely, but it appears to me that grex still has enough horsepower and network bandwidth to allow more simultaneous users. Any thoughts?16 responses total.
This response has been erased.
perhaps add a group for local telnetters such as already exists for the dialins. If there are more than XXX many "local" people, it will queue them. Similar to the way m-net does it, but not quite. This would give us the ability to add 10 "local" users or whatnot .
how would you define 'local telnetters"? By address block of the known A2 ISP's? I think we'd be chasing a moving target there... And with so many ISP's having regional and national affiliations, it might be real difficult to discern the 'real' location of an incoming telnet request. And how about us locals who go on the road? I'm planning a mega road trip out west and beyond this summer. Any suggestions for an ISP with nationwide coverage, reasonable rates, and clean connections back home to grex?
(I use IBM Global Network. See http://www.ibm.net) M-Net gives preference to local telnetters, where "local" is defined as "within Michigan". I'd be against Grex doing some- thing like that.
re #3 Local telnetters: MI based folks - Get preference in the telnet queue. Chasing moving targets: ISPs don't renumber very fequently these days. On the road: Well, you can dial direct, or wait. if you dial into your isp that is in the list of "local" sites, that will suffice re #4 I'm just trying to think of a reasonable way to improve.
I fail to see any harm in increasing the number of ptys as long as the system is racking up idle time. It appears to me that with the current limits it is quite common to see a large queue to get on while there is CPU idle time because of insufficient load. We don't appear to be doing excessive swapping most of the time, but we should watch to see if that changes, and if so, back off. Now there are other things that contribute more strongly to CPU usage, like mail, ftp, http and other servers. We should get that mail machine up and running, and I think it should produce room for yet more to log in simultaneously.
could we bring telnet ptys up to 80 as a test? :)
I think the test of 80 ptys is a good idea, though I think getting the mail machine running would be an even better idea. I'm not sure what the status is on the mail machine, so for now I think it'd be an interesting excerise to increase the number of ptys.
I agree that trying more open pty's may be a worthwhile experiment, given a certain amount of idle time on the cpu. I think opening more pty's to local users only is a mistake. I'd like to see us be a little mote egalitarian than that.
The mail machine is coming along nicely. The hardware is all set and is nicely far through some test pounding. It still needs to have the final incarnation of it's OS installed, tested, swept for holes, and then.... Here's Johnny.
This response has been erased.
Seems to be going well this very second, i had to wait a fairly long time to get in too.. 11:04am up 13:56, 72 users, load average: 3.29, 3.41, 3.29
IWLTA that I am posting this from a system at my place running OpenBSD, the OS that the mail machine is destined to use. I'm not an expert at OpenBSD, but I spend the whole evening learing to install it. ;) (NEVER EVER use an SMC ISA network card with this OS.)
(uh, wrong item perhaps?)
(Probably. OTOH, offloading mail might be very relevant to increasing the number of remote logins; possibly this was the logic?)
Yup.
You have several choices: