dgr@hpfcso.HP.COM (Dave Roberts) (04/12/90)
bzs@world.std.com (Barry Shein) writes: #From: pcg@aber-cs.UUCP (Piercarlo Grandi) #>In article <8840010@hpfcso.HP.COM> dgr@hpfcso.HP.COM (Dave Roberts) writes: #> In school we had a lab full of Sun 3/50s which were all diskless (via NFS) #> to a server. There were about 50 machines on an ethernet which worked #> #>Note that 50 machines to a single server is *crazy*. I would not go over a #>dozen; and even with multiple servers I think that 50+ hosts doing heavvy #>traffic on a single Ethernet requires some careful analysis. # #Gee, Piercarlo, do you ever work from facts forward rather than the #other way around? He said the 50 workstations worked fine except #during peak load (finals), what else is new? Every utility on earth is #set up this way. So you say the set-up is crazy? Why? Because it #worked? Because it offends your intuitive sensibilities? Well, to be honest, I thought it was crazy too. It wasn't a good situation but universities make due with what they have and we did get our programs done eventually :-). The point wasn't to show that 50 diskless machines on an Ethernet is doable, but rather that it *is* crazy in many circumstances. The argument was being made that consolidating your disk resources into servers and having everybody go diskless was a good idea based on the fact that Ethernet bandwidth was higher than some disk drives. My point was that it depends on how you use your Ethernet. #> ...Now a bunch of CS majors do a lot of #> compiling when they're trying to get those projects done (very disk #> intensive) and during this time it took forever to get anything done. #> #>NFS was designed to exchange data easily across heterogenous machines; a kind #>of automatic 'ftp'. It is being used as a file service system. Too bad that it #>offers *horrible* performance. You suffered the consequences. # #I thought compiling hasn't been disk intensive for years, it's CPU #intensive. Does anyone have measurements? That doesn't stop you from #running with this lead and drawing conclusions based on it. Well, it's kind of both. At any rate your're starting a number of processes which all have their images stored across the net and you're reading and writing both the input and output files for a number of passes with files that may get pretty big. It may also be CPU intensive, but the point was that a lot of data was being shoved both ways across the net. And NFS does offer worse (though not quite "*horrible*") performance. It all depends how you use it. #The truth of the matter is that you can't take upper-limit numbers #based on burst activities and derive all sorts of conclusions about #the entire system. # #To be frank, I don't trust your intuitions. I'd rather see some data. # #Perhaps that's rude. Nope, not at all. I'd like to see Pete back a little of it up, too. I run diskless now and haven't had any major problems and it does offer some distinct advantages. The differences between what I have now and the situation I described at school are that there aren't as many people being served by my server (probably closer to 10), the conditions are much more forgiving (we still move big(er) files around but you don't have 50 people all hammering the server at once), and the LAN just doesn't have as much traffic on my local section of it. Like I said before, the point of what I wrote was to try and show that you can push Ethernet way beyond what it was designed to handle and it will fail, no matter what kind of cacheing or disk banking you have on your super duper fast server. This means that you can't just throw 100 meters of coax into a building, add a fast disk server, and expect to attach however many diskless workstations/PCs you want to the thing. But like I'm proving right at this minute, if you do it right and plan your net structuring and load the net correctly, you shouldn't have many problems. I would still keep some local swap though, because it really stinks when you have a huge process running and decide to read your mail or something and have that thing get fired off across the net. Peter's point that it doesn't help for the server to cache this stuff because I obviously shouldn't want it for a while is well taken here. # -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 #---------- Thanks for the comments, Barry. Dave Roberts dgr@hpfcla.hp.com