Switch recommendations? (now with figure:)
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.
Petr Ladislav Kodym kodym at mit.jyu.fiWed Nov 29 04:04:18 PST 2000
- Previous message: Switch recommendations? (fwd)
- Next message: mosix - architecture setup
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi, Thanks for your very comprehensive answer. There might be a pitfall, however. >However, you're right -- the HP example alone indicates that I should >stop worrying about what kind of switching technology a given switch is >based on and focus on just the latency issue itself, since that is what >matters. Here is the corrected "rule": > >Switches that advertise latency in the 10 microsecond range or less are >"good" (or at any rate "better":-) for fine grain packet traffic, >whatever the mechanism they use for switching (which might be some >proprietary mix of SnF and CT and black magic for all I really know >about the internal hardware of a switch -- I just plug them in and they >work, on a good day;-). They also cost "more" (per port) and often >come with other possibly desireable features, e.g. manageability, VLAN >capabilities and so forth. There are two ways of measuring the switch latency. HP reports latency of their S&F switches on a LIFO basis (standard way of latency measurement for S&F switches). LIFO latency is the time elapsed between the end of the last bit of the packet going into the switch to the beginning of the first bit of that packet emerging from the switch. Cut-through switch latency is however measured on a FIFO basis --- time measured from the beginning of the first bit of the packet going in the switch and beginning of the first bit of the outbound packet coming out out of the switch. To convert LIFO figure into FIFO, one must add the time spent on the wire: FIFO = LIFO+(packet length(bytes)*0.08 usec) That doesn't make much difference for very short packets, but it adds 80 usec for packets 1kB long. This could make a lot of difference if you are trying to go user-level and bypass the TCP/IP stack overhead. On the enclosed postscript figure are plotted our measurements of the TCP round-trip times for different packet sizes using different types of interconnections (3Com 3300 switch, SMC EZ1016DT switch and crossover cable). All our machines were equipped with Intel EtherExpress Pro 100 NICs and they were running the Linux kernel version 2.2.14. The line labeled as Uniproc Xover shows the round-trip time between two single processor Athlon 500 Mhz machines via cross-over cable. The line denoted as Uniproc SMC depicts the round-trip time between the same pair of machines via SMC EZ1016DT switch. You can clearly see the impact of the Store&Forward algorithm on the latency, even when using high-overhead TCP/IP protocol stack. SMP Xover labels results of measurements between two dual Celeron 466Mhz machines via cross over cable. The initial latency for 64B packets is almost twice higher than latency for uniprocessor machines (why?). The last two plots denoted as SMP SMC and SMP 3Com displays round-trip times between the two above described SMP machines over SMC EZ1016DT switch and 3com SuperStack II 3300 switch correspondingly. Although the price of these switches differs significantly, the performance from the point of view of latency is exactly the same. SMC EZ1016DT switch has 16 ports, while 3Com 3300 comes in 12 or 24 ports version. However, SMC produces EZ1024 switch, equipped with 24 ports as well. It's listed backplane bandwidth is 2.4Gbps, therefore it should be capable of full wire speed on all 24 ports simultaneously. According www.pricewatch.com this switch could be purchased by the beginning of February 2000 for about USD 520. According the same source, the street price for 3Com SuperStack II was USD 1350 at the same time. Hope that it was interesting for someone. Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: plot.ps.gz Type: application/octet-stream Size: 2948 bytes Desc: Url : http://www.scyld.com/pipermail/beowulf/attachments/20001129/68502c9a/plot.ps.obj
- Previous message: Switch recommendations? (fwd)
- Next message: mosix - architecture setup
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
