[Beowulf] SGI to offer Windows on clusters
Many of your questions may have already been answered in earlier discussions or in the FAQ. The search results page will indicate current discussions as well as past list serves, articles, and papers.
Jim Lux James.P.Lux at jpl.nasa.govThu Jan 18 09:37:30 PST 2007
- Previous message: [Beowulf] SGI to offer Windows on clusters
- Next message: [Beowulf] SGI to offer Windows on clusters
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 06:53 AM 1/18/2007, Eric Shook wrote: >Ashley Pittman wrote: >>On Wed, 2007-01-17 at 08:50 +0100, Mikael Fredriksson wrote: >>>Eric Shook wrote: >>>>I talked to our SGI rep about this yesterday and he told me they >>>>are not really targeting "hard-core" university research where >>>>Linux/UNIX already has a strong foot hold. Instead this is for >>>>the Business sector where simplified workflows and having easy >>>>HPC integration into an already 100% Windows Infrastructure is more appealing. >>>> >>>>This was his take and it seemed reasonable to me. >>>Yes, it is. And more so if this cluster/LAN can also utilize som type >>>of "MOSIX" system. This will substatially increase the throughput of >>>"standard serial" processes. >>I find this statement hard to comprehend, how can any OS substantially >>improve throughput of jobs unless what it replaces is incredibly >>deficient in some way? The limiting factor on clusters is the speed of >>the hardware, even if some OS magically manages to be say 50% more >>efficient doing it's bit than another OS it's still only a tiny percent >>of time used, substantial improvements in job throughput can only come >>about from better parallel algorithms, better code or faster hardware. > > >Actually there are a few case studies floating around comparing >Linux to Windows (not sure about UNIX). That when running on >identical hardware and the same code you can lose up to 30% >efficiency running on Windows. Hmmm.. I would imagine that there are not-quite-pathological cases where this is true. Certainly, I would expect this kind of differential installing essentially the same application on box stock installs of each, just because the stock install of Win tends to have a lot of other stuff added in to "enhance the user experience" as well as providing a "Windows Genuine Advantage" so that your vast music and video collection "Plays for Sure". On a stripped down WinXP system, I'd not be so sure. Once you've gotten rid of all the little helpful stuff that grabs a cycle here and grabs a cycle there (automatic software updates in the background are a particuarly annoying case) it's going to be pretty similar.. the underlying kernel to do things like disk i/o and start/stop processes doesn't consume a huge fraction of the overall CPU or bus bandwidth in either Win or Linux, so even if Win's an absolute dog, performance wise, the overall impact isn't going to be that big. (And, of course, the kernel in Win isn't all that inefficient.. a) it's not that hard to make it "reasonable" and b)it's a worthwhile investment for MS to make it decent) There's a whole literature on tweaking WinXP for realtime performance (folks doing things like DSP for radios, audio recording, video editing, gaming, etc. have figured all this out), just as there is for Linux. And, that tweaking is essentially a one time "installation" sort of effort. Spend the couple days getting rid of unneeded processes and utilities (hmm sort of like customizing your init scripts) setting process priorities, etc. and you're in good shape. Yes, there is ALWAYS the risk that some update goes and sets things back, just to be helpful, but, in general, that's pretty rare. A real time waster for WinXP has to do with network access to remote disk drives.. there are pathological cases where it can spend a LOT of time apparently spinning in the kernel waiting for a response that never comes. But I've only encountered this on a large heterogeneous network (JPLnet can fairly be called large and heterogenous, I suppose) with both machines having a lot of oddball network access drivers and services installed (e.g. AFS Client, Tivoli, NearSpace, Timbuktu, etc.), some of which I am certain are mutually incompatible. On a smallish (<10 machines) network with me controlling all the nodes, I've never had the big kernel waits. James Lux, P.E. Spacecraft Radio Frequency Subsystems Group Flight Communications Systems Section Jet Propulsion Laboratory, Mail Stop 161-213 4800 Oak Grove Drive Pasadena CA 91109 tel: (818)354-2075 fax: (818)393-6875
- Previous message: [Beowulf] SGI to offer Windows on clusters
- Next message: [Beowulf] SGI to offer Windows on clusters
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
