On Tue, Mar 24, 2009 at 10:24 AM, Rainer Duffner <rainer at ultra-secure.de> wrote: > Rob Townley schrieb: >> >> Every time i read these posts they are filled with contradictions in >> that one person loves HP and hates CiscoLinksys while another hates >> HP. Let's get a more scientific approach. Switch performance still >> depends on the NICS in the client machines. > > > Uhm. No. Not any longer, AFAIK. > At least, once you leave the SOHO region (AFAIK, the OP wanted >= 48 > ports. I don't want to work in such a home-office, really...). There are 48 port SOHO priced switches nowadays. i am often not very impressed by network performance and need standardized benchmarks to figure out if there may be an issue at the NIC driver, switch or on up to a virus shield. It was either a ~2004 Dell Power magazine or ~2004 Network World article that mentioned that 3Com NICs didn't perform well with Cisco switches and vice versa. They also wrote about other vendors and i don't remember any of them performing extremely well across vendor. Now that NICs are a commodity, the problem could be worse. > Backplane-performance is an issue. > Especially with iSCSI. > > Also, as demonstrated, different switch-vendors offer different > feature-sets at different price-levels. > There's also the compatibility-question: if you already have a number of > devices, the new ones must fit in well into the existing landscape > (VLANs etc.pp.) > > >> >> Performance data would need to have details such as the NIC on the >> client machine and other hw characteristics. How many machines ran >> the benchmark simultaneously. Cat5e vs Cat6 or Fiber connected. >> > > > That's already more variables in the equation than is healthy for a > typical benchmark... > > >> http://www.netperf.org ( OpenSource started by HP, ) >> ftp://ftp.netperf.org/netperf/ (Looks like 2.4.4 is the latest >> version. Not sure what 4.0.0 is) >> >> http://sourceforge.net/projects/jnetperf (java version of netperf) >> >> There may be another project from some Italian Professor, but didn't >> find it in my bookmarks. >> >> Yes, there is the unix way of time dd ... but that wouldn't work for >> windows clients and does not give enough details in terms of metrics. >> > > Switch performance is extremely difficult to measure IMO. You need > enough clients to make sure you're not accidentally measuring > client-performance. Agreed, this is a difficult complex system, but some baseline measurements would still be worthwhile to rule out some problems. Client NIC performance would be valuable info. > > In the end, the only thing that counts is real-world data. Netperf > et.al. don't really provide a real-world scenario, where you have a > mixture of packet-sizes and protocols. > Same for artifical load/packet generators (ixia et.al). netperf could use some work, but some generic baseline perf data would still be very valuable to rule basic problems. Somebody could post an ethereal packet capture of varying packet sizes and protocols that could be replayed on client machines. > > Because (almost) nobody has the time to do extensive tests, past > real-world experience/performance data and word-of-mouth becomes an > integral part in choosing such products. > That, or you have enough money to buy everything from Cisco ;-) In theory, pxe booting a test image on all machines in the lan (maybe via drbl / CloneZilla) with netperf and running overnight could automate this process. The reality is that it can take much much more time to track down where a performance bottleneck is on a heterogeneous LAN. What "performance data" are you referring to? > > > Rainer > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >