rcpieter@svin02.info.win.tue.nl (Tiggr) (11/14/90)
randy@ms.uky.edu (Randy Appleton) writes: >But how does each user, who is about to log in, know which machine to >log into? He ought to log into the one with the lowest load average, yet >without logging on cannot determine which one that is. Andrew Tanenbaum et al solved this problem by developing Amoeba. And far more transparant than logging in onto the server with the lowest load average. Tiggr
tarcea@vela.acs.oakland.edu (Glenn Tarcea) (11/14/90)
In article <16364@s.ms.uky.edu> randy@ms.uky.edu (Randy Appleton) writes:
#I have been wondering how hard it would be to set up several
#of the new fast workstations as one big Mainframe. For instance,
#imagine some SPARCstations/DECstations set up in a row, and called
#compute servers. Each one could handle several users editing/compiling/
#debugging on glass TTY's, or maybe one user running X.
#
#But how does each user, who is about to log in, know which machine to
#log into? He ought to log into the one with the lowest load average, yet
#without logging on cannot determine which one that is.
#
This is not a direct answer to you question, but it may have some merit.
It sounds to me that what you are talking about is a lot like a VAXcluster.
I have often thought it would be nice to be able to cluster U**X systems
together. NFS is a nice utility, but it isn't quite what I am looking for.
I also find it interesting that IBM has decided to go with the clustering
concept for their mainframes. Although it seems to me it would be a lot
cheaper and better for the customer to buy 10 $30,000 workstations and
cluster them together, rather than 3 $22,000,000 mainframes (run yeck! MVS)
and cluster them together.
Perhaps if DEC can get a POSIX compliant VMS out we will be able to
cluster "U**X" systems.
-- glenngdtltr@brahms.udel.edu (Gary D Duzan) (11/14/90)
In article <3849@vela.acs.oakland.edu> tarcea@vela.acs.oakland.edu (Glenn Tarcea) writes: =>In article <16364@s.ms.uky.edu> randy@ms.uky.edu (Randy Appleton) writes: => =>#I have been wondering how hard it would be to set up several =>#of the new fast workstations as one big Mainframe. For instance, =>#imagine some SPARCstations/DECstations set up in a row, and called =>#compute servers. Each one could handle several users editing/compiling/ =>#debugging on glass TTY's, or maybe one user running X. =># =>#But how does each user, who is about to log in, know which machine to =>#log into? He ought to log into the one with the lowest load average, yet =>#without logging on cannot determine which one that is. =># => => This is not a direct answer to you question, but it may have some merit. =>It sounds to me that what you are talking about is a lot like a VAXcluster. =>I have often thought it would be nice to be able to cluster U**X systems =>together. NFS is a nice utility, but it isn't quite what I am looking for. You might want to look into what research has been done in the area of Distributed Operating Systems. Some of these use Unix(tm) and others don't. My personal favorite (from reading up on it) is Amoeba, developed by a group at VU in Amsterdam (including Dr. Tanenbaum, known for several textbooks and Minix). It was build from the ground up, so it is not Unix, but one of the first things built on top of it was a Unix system call server which allowed for fairly easy porting of software. Anyway, many (if not most) DOS's will support some form of automatic load balancing and possibly process migration (a hard thing to do in general). As for which CPU to log onto, it doesn't matter; the DOS makes the whole thing look like a single, large machine. For a more immediate solution, I put together a simple Minimum Load Login server on a Sun 3 network here at the U of D (a real kludge, I must say). To use it, one would "telnet fudge.it.udel.edu 4242". On that port I have a program that searches a list of 3/60's and parses a "rup" to each one. It then tosses packets between the caller's port and the least loaded CPU's telnet port. This is a horrible, ugly solution, but it works, and one can always just kill the original telnet and manually start a telnet to the machine selected by the MLL daemon. Gary Duzan Time Lord Third Regeneration -- gdtltr@brahms.udel.edu _o_ ---------------------- _o_ [|o o|] An isolated computer is a terribly lonely thing. [|o o|] |_O_| "Don't listen to me; I never do." -- Doctor Who |_O_|
mpledger@cti1.UUCP (Mark Pledger) (11/14/90)
Isn't this what symmetrical multiprocessing is all about ? -- Sincerely, Mark Pledger -------------------------------------------------------------------------- CTI | (703) 685-5434 [voice] 2121 Crystal Drive | (703) 685-7022 [fax] Suite 103 | Arlington, DC 22202 | mpledger@cti.com --------------------------------------------------------------------------
rickert@mp.cs.niu.edu (Neil Rickert) (11/14/90)
In article <3849@vela.acs.oakland.edu> tarcea@vela.acs.oakland.edu (Glenn Tarcea) writes: > > I also find it interesting that IBM has decided to go with the clustering >concept for their mainframes. Although it seems to me it would be a lot >cheaper and better for the customer to buy 10 $30,000 workstations and >cluster them together, rather than 3 $22,000,000 mainframes (run yeck! MVS) >and cluster them together. Suppose you wanted a system to manage huge databases. You needed strong integrity controls for concurrent database updates. You needed to access the data in a huge room packed to the gills with disk drives. You needed to be able to access the same data from any CPU in the system. You couldn't tolerate the performance hit of the bottleneck caused by pumping all the data down an ethernet. You just might find the mainframes a better solution than the workstations. IBM didn't get that big by ignoring its customers' needs and forcing them to buy an excessively expensive and underperforming system. Instead they carefully monitored those needs, and evolved their hardware and software to meet them. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
fjb@metaware.metaware.com (Fred Bourgeois) (11/15/90)
In article <16364@s.ms.uky.edu> randy@ms.uky.edu (Randy Appleton) writes: >I have been wondering how hard it would be to set up several >of the new fast workstations as one big Mainframe. For instance, >imagine some SPARCstations/DECstations set up in a row, and called >compute servers. [...] You should look into the Solbourne (TM, I think) system's. They use several SPARC-based CPU's in a single multi-processor unit (I think they use up to 8 CPU's), which attempts to distribute the load as evenly as possible. > [...] But please keep one of comp.arch or comp.unix.large [...] Sorry, I couldn't post to either of those. --- Fred Bourgeois, MetaWare Inc., 2161 Delaware Avenue, Santa Cruz, CA 95060-2806 fjb@metaware.com ...!uunet!metaware!fjb Colorless Green Ideas Sleep Furiously, and so do I.
suitti@ima.isc.com (Stephen Uitti) (11/15/90)
In article <1990Nov14.154322.8894@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <3849@vela.acs.oakland.edu> tarcea@vela.acs.oakland.edu (Glenn Tarcea) writes: >> >> I also find it interesting that IBM has decided to go with the clustering >>concept for their mainframes. Although it seems to me it would be a lot >>cheaper and better for the customer to buy 10 $30,000 workstations and >>cluster them together, rather than 3 $22,000,000 mainframes (run yeck! MVS) >>and cluster them together. > > Suppose you wanted a system to manage huge databases. You needed strong >integrity controls for concurrent database updates. You needed to access the >data in a huge room packed to the gills with disk drives. You needed to be >able to access the same data from any CPU in the system. You couldn't >tolerate the performance hit of the bottleneck caused by pumping all the data >down an ethernet. > > You just might find the mainframes a better solution than the workstations. I'm not convinced that the ethernet would be the bottleneck. If it were, the net could be partitioned. If you can get the transaction rates high enough for the individual machines, and if your data can be partitioned properly, and if your plan allows easy expansion with new nodes, the cost effectiveness of the workstations may give them an edge. I wouldn't use a million Commodore C64's, though. You might find a single Connection Machine to be better than any of the above. If you have a single large application, a single high-end wierd machine may be the answer. A collection of commodity disks on a CM can give you gigibytes of data access with amazing bandwidth. There is probably enough CPU for you too. If you have hundreds of little jobs, I'd go with hundreds of smaller processors. > IBM didn't get that big by ignoring its customers' needs and > forcing them to buy an excessively expensive and underperforming > system. Instead they carefully monitored those needs, and > evolved their hardware and software to meet them. I'm convinced that they got where they are mainly through marketing - something I'd recommend to anyone with the bucks. Stephen Uitti. suitti@ima.isc.com "We Americans want peace, and it is now evident that we must be prepared to demand it. For other peoples have wanted peace, and the peace they received was the peace of death." - the Most Rev. Francis J. Spellman, Archbishop of New York. 22 September, 1940
bzs@world.std.com (Barry Shein) (11/15/90)
> Suppose you wanted a system to manage huge databases. You needed strong >integrity controls for concurrent database updates. You needed to access the >data in a huge room packed to the gills with disk drives. You needed to be >able to access the same data from any CPU in the system. You couldn't >tolerate the performance hit of the bottleneck caused by pumping all the data >down an ethernet. No, but FDDI runs at near bus speeds, so you're talking old technology for an application like this. IBM/370 drives run at about 5 MB/s max, not much a challenge for fiber, tho the software can be challenging for other reasons. Most of the advantage of IBM mainframes is that they *are* a distributed operating system, disk channels have significant processing power. One can do things like send a disk channel off looking for a database record and go back to something else until the answer is found. So we're sort of talking in circles here. > IBM didn't get that big by ignoring its customers' needs and forcing >them to buy an excessively expensive and underperforming system. >Instead they carefully monitored those needs, and evolved their >hardware and software to meet them. That's an interesting theory. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
ian@sibyl.eleceng.ua.OZ (Ian Dall) (11/15/90)
In article <16364@s.ms.uky.edu> randy@ms.uky.edu (Randy Appleton) writes: >But how does each user, who is about to log in, know which machine to >log into? He ought to log into the one with the lowest load average, yet >without logging on cannot determine which one that is. I do just that! I have a little shell script called "least-loaded" which grunges through the output of ruptime. So when X starts up it does "rsh `least-loaded <list of servers>` ...." to start my clients. I also do this when I have a compute bound job to run. The only catch is that all servers need to be capable of running your job. We have several servers set up with NFS cross mounting so they are *almost* identical. You can get caught out sometimes though. Also, NFS imposes an additional overhead. Running a compute bound process this way is fine, running an IO bound process this way might be a bad idea if the disk it accesses is physically on another server. In short, I think it is a good idea, but it needs a more efficient distributed file system before I would want to release it on Joe User. It would be really nice to have a distributed OS which was able to migrate IO bound processes to minimise network traffic and migrate cpu bound processes to the least loaded machine. Dream on! -- Ian Dall life (n). A sexually transmitted disease which afflicts some people more severely than others.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (11/15/90)
In article <16364@s.ms.uky.edu>, randy@ms.uky.edu (Randy Appleton) writes: > I have been wondering how hard it would be to set up several > of the new fast workstations as one big Mainframe. > The advantage is that this seup should be able to deliver a fair > number of MIPS to a large number of users at very low cost. > So my questions is, do you think this would work? How well do you > think this would work? Yes it did work. Cambridge University had a wall full of 68000s doing this sort of thing about 7 years ago (it had been running for some time, that's just when I saw it). -- The problem about real life is that moving one's knight to QB3 may always be replied to with a lob across the net. --Alasdair Macintyre.
src@scuzzy.in-berlin.de (Heiko Blume) (11/16/90)
In article <16364@s.ms.uky.edu> randy@ms.uky.edu (Randy Appleton) writes:
#I have been wondering how hard it would be to set up several
#of the new fast workstations as one big Mainframe. For instance,
#imagine some SPARCstations/DECstations set up in a row, and called
#compute servers. Each one could handle several users editing/compiling/
#debugging on glass TTY's, or maybe one user running X.
#
you might want to have a look at some backissue of BYTE (about distributed
processing). they had an article about a compute server with a damn lot of
processors. it had a Real Fast Bus and processors dedicated for network
handling etc.
--
Heiko Blume <-+-> src@scuzzy.in-berlin.de <-+-> (+49 30) 691 88 93
public source archive [HST V.42bis]:
scuzzy Any ACU,f 38400 6919520 gin:--gin: nuucp sword: nuucp
uucp scuzzy!/src/README /your/homeeugene@nas.nasa.gov (Eugene N. Miya) (11/16/90)
In article <16364@s.ms.uky.edu> randy@ms.uky.edu (Randy Appleton) writes: TOO MANY NEWS GROUPS.... >I have been wondering how hard it would be to set up several >of the new fast workstations as one big Mainframe. Physically: not very hard, these days. Software will be your problem. You must be an aspiring hardware type 8^). You would have to totally rewrite many existing applications, a few from scratch. You are making the assumption that the sum of workstations == a mainframe. This may not be the case. [Gestalt: the whole is great than the sum of the parts.] Perhaps adding computation late in the game will only make the computation slower (later). This will depend very much on the nature of the application: language, algorithm, communication cost, etc. Seek and yea shall find some hypercubes. >But how does each user, who is about to log in, know which machine to >log into? He ought to log into the one with the lowest load average, yet >without logging on cannot determine which one that is. >some such thing), so as to presurve the illusion that this is one big ^^^^^^^^ sometimes a dangerous word. >What would be nice .... >The idea is that as each person logs into the Login Server, their login >shell is acually a process that looks for the least loaded Server, and >rlogin's them to there. This should distribute the load evenly >(well, semi-evenly) on all the servers. ..... >you got (which ought to be invisible) you saw the same files. ^^^^^^^^^ [aka transparent] This is a dream which as existed since the 1960s with the ARPAnet. It has seen limited implementation. There are many subtle problems, but it interests a lot of people: load oscillation effects, reliability, error handling, etc. Performance gains are needed to solve future problems. >So my questions is, do you think this would work? How well do you >think this would work? Do you think the network delays would be excessive? Network delays are probably the least of your problems. Again, it will for for limited applications. The problem is basically a software problem. If you don't have it, it won't work. Depends on your basic building blocks (some of OUR applications require 128-bit floating-point). I have an officemate who is absolutely fed up debugging distributed applications (graphics). Neil W. Rickert writes: | Suppose you wanted a system to manage huge databases. |You just might find the mainframes a better solution than the workstations. | | IBM didn't get that big by ignoring its customers' needs and forcing them to |buy an excessively expensive and underperforming system. Instead they |carefully |monitored those needs, and evolved their hardware and software to meet them. Sure, for some DBMS applications (and systems), but you must be posting from an IBM system 8^). Many workstations are not excessively expensive, and quite a few are very fast, even faster than mainframes. But, please, if you wish, stick with dinodaurs. --e. nobuo miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov The Other Eugene. {uunet,mailrus,other gateways}!ames!eugene
rsalz@bbn.com (Rich Salz) (11/20/90)
In <1572@svin02.info.win.tue.nl> rcpieter@svin02.info.win.tue.nl (Tiggr) writes: >Andrew Tanenbaum et al solved this problem by developing Amoeba. Some solution. Throw out much of your software, and lots of your hardware (if you want the much-touted Amoeba speed) and run a clever O/S unlike anything commercially available. Heterogeneity is the wave of the future. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.