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
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
