[Beowulf] SGI to offer Windows on clusters

Jim Lux James.P.Lux at jpl.nasa.gov
Thu Jan 18 09:37:30 PST 2007


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 





More information about the Beowulf mailing list