HZ and HPC
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.
Ken Chase math at velocet.caWed Jan 29 06:10:16 PST 2003
- Previous message: HZ and HPC
- Next message: HZ and HPC
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wed, Jan 29, 2003 at 08:55:11AM -0500, Ken Chase's contradicting himself again with... > With large caches today you can tune a class of jobs for your cluster > that are below the threshhold size nicely, and run those jobs differently > from the others (using different #s of nodes, possibly even different > interconnects as thrashing will obviously destroy scaling). Actually, now that I think of this, it may well do the opposite in fact if you have a job that runs slower for some reason, the relative speed of your network is now faster for that job - it may well allow you to maintain scaling with slower interconnects between nodes. Most likely you may be able to scale the same amount over a few more nodes than with the job running faster on the CPU. (Consider the pathological condition - if a job ran 100 times faster on a CPU when not thrashing the cache, you'd need a much faster interconnect (much lower latency) to get the messages to the other nodes in time to avoid having them waiting on data.) Sometimes I think that really wide pipes that are otherwise cheap and slow might serve heavily loaded (multiple jobs) CPUs more efficiently. Comments? /kc -- Ken Chase, math at velocet.ca * Velocet Communications Inc. * Toronto, CANADA
- Previous message: HZ and HPC
- Next message: HZ and HPC
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
