[Fwd: Re: 32-port gigabit switch]
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.
Richard Walsh rbw at ahpcrc.orgFri Mar 7 09:12:35 PST 2003
- Previous message: LM article support website...
- Next message: [Fwd: Re: [Fwd: Re: 32-port gigabit switch]]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, 7 Mar 2003 06:52:26, Eray Ozkuraln wrote: >It depends on the application :) > >Actually throughput is more important than latency in many cases I believe. >And of course while it is not too difficult using common programming >techniques to optimize for high throughput high latency it would be much >harder to do so with low throughput low latency don't you think? :) Right. In the limit of a 1 byte message, the inverse of the latency is the worst-case bandwidth for repeatedly sending 1 byte. On a GBE system with a latency of say 50 usecs your worst case bandwidth is 20 KB/sec :-(. This is mostly a hardware number. If you add in other contributors to the latency things get worse. As message size shrinks latency eventually dominates the transfer time ... the larger the latency the sooner this happens. Under the heading of "everything is just another form of something else", the distinction between latency and bandwidth gets muddy as latency grows relative to message size. [Reminds of that mass <--> energy thing ... ;-) ... E = MC**2] On the other hand, if you can manage your message sizes, keep the latency piece a small percentage of the message transit time, and have good bandwidth you may not care what the latency is. Pushing up data volumes per node imply larger surfaces to communicate which imply larger messages. These transfers can be hidden behind compute cycles. Of course, one has to worry about faster processors shrinking compute cycles. There are better more detailed analyses in the archives as I recall. rbw #--------------------------------------------------- # Richard Walsh # Project Manager, Cluster Computing, Computational # Chemistry and Finance # netASPx, Inc. # 1200 Washington Ave. So. # Minneapolis, MN 55415 # VOX: 612-337-3467 # FAX: 612-337-3400 # EMAIL: rbw at networkcs.com, richard.walsh at netaspx.com # rbw at ahpcrc.org # #--------------------------------------------------- # To minimize is human, to anneal divine. # --Tin from Metal Men Comics #---------------------------------------------------
- Previous message: LM article support website...
- Next message: [Fwd: Re: [Fwd: Re: 32-port gigabit switch]]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
