Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!CSV.RPI.EDU!yerazuws From: yerazuws@CSV.RPI.EDU (Crah) Newsgroups: mod.computers.vax Subject: Re: new cluster suggestions... Message-ID: <8701161452.AA14994@csv.rpi.edu> Date: Fri, 16-Jan-87 09:52:18 EST Article-I.D.: csv.8701161452.AA14994 Posted: Fri Jan 16 09:52:18 1987 Date-Received: Sun, 18-Jan-87 01:41:46 EST References: <0537612435@uwovax.UWO.CDN> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 105 Approved: info-vax@sri-kl.arpa Summary: You can do it - but you do NOT want to! It seems that what you think you want to do is to keep the CS students on one CPU, while maintaining the clusterness of the assembly (8600 + 8550) in terms of disk sharing via the HSC Well, one thing *is* important - and that's that you're using LAT's or DECservers. Otherwise, you have to move terminal connections on the backpanel and that's a pain and a half. Method 1) As of 4.4, you can have an entire cluster have a name that a LAT or DECServer knows about; so you (under normal operations) use the name for the cluster. You have the password file in sys$common, so both machines read it from there. When you need to split the system for logins, you disable the clustername (actually it's unnecessary to do this but ...). Further, you put *different* SYSUAF.DAT files in the sys$specific directories of each machine. Viola- you can allocate on a per-user basis who can go where. Method 2: (and preferable in terms of load-balancing.) Use disk quotas to keep the undergrads from overflowing everything (in operation continuously). Put a mod in SYLOGIN.COM to check the node (via F$NODE) and if it's the research machine, then to check the current load (which involves doing a SHO SYS /OUTPUT=filename and then reading the file with DCL - tricky but doable). If the load is too high, then suggest to the poor undergraduate that he should LAT to the other machine, give him a few seconds to read the message, and log him out. Faculty, of course, would be "known to" the SYLOGIN command procedure (either because their group number was different or by having an attribute in SYSUAF.DAT), and wouldn't be subject to this cutoff. The advantage of this method is that it automatically switches in or out depending on what the load is. It frees up BOTH cpu's automatically in the evening, on weekends, when nobody on the faculty is doing anything. You might want to put a "hysteresis hack" in so that short-term decreases in CPU don't start letting undergrads in (i.e. during lunch). This is easy to do - have SYLOGIN write a file (with trash in it) whenever it decides load is too heavy for undergrads. Put this file in SYS$COMMON. After the load check, look at the date/time on the file. If it's been less than one hour, update the file-last-altered time and refuse the login. If it's longer, don't update and allow the login. Hence, if anyone has been bounced on load average within an hour, you keep the undergrads off. You can avoid having billions of versions of the junk file by specifying name.type;version when the command procedure opens the file. You also can have the command procedure omit the whole check whenever it's after 5 PM or on a weekend. Now, a brief flame about the politics of this whole system. I think it's a bad idea. By making the available resources SMALLER when demand increases, the undergrad CPU will die in agony. Meanwhile, every undergrad will know that there's this other CPU virtually unloaded (even though it isn't, they can't go there and see for themselves). This will frustrate them- and so they will go out to try and crack the restriction. And certainly be angry that it exists. This is something you do *not* want to happen! In the US, a third of a college's income comes from donations of alumni - and you desperately do NOT want to alienate your final-semester seniors, who shortly will be wage-earners in a most lucrative field. T'would be far better to tell the professors to go take a week's vacation than to get these newly-minted wage-earners mad at you. Trust me - I know a college that did such things for about a decade to it's undergraduates- and now has severe financial problems because none of the last ten years of undergrads want to donate a cent to the college. (I exaggerate - it's not "none". It is less than a third the national average, however) Sit and endure and if you need an explanation, tell the *management* that although it's "possible" to partition the system, it would result in "severe transient load balancing problems and system instability". The transient load balancing problems is due to switching a much greater load onto the undergrad CPU (making your previous tuning there worthless). Jobs on the undergrad CPU will most likely thrash - and where will the thrashes impact? On your CI and HSC and paging device- which may or may not saturate. But the load on CI/HSC/disk will certainly INCREASE beyond what it would have been if you didn't partition in the first place. The system instability is due to hackers trying to break the partitioning. If they succeed, you lose. If they fail, they might break something important (either crash the system, or maybe just get frustrated and pour a coca-cola into a keyboard). That's bad, too. It's far more kind to never give someone access to something than to give them something and then take it away - just when they need it the most. So, now that you know how to do it, and why you shouldn't do it, what do you want to do? -Bill Yerazunis "You've got it all wrong. I'm not locked up in here with you; you're locked up in here with ME ! "