[switch] prijs/kwaliteit factoren (16 ports)

[Carnifex]

Ik zoek een 16 ports switch om te gaan gebruiken voor een LAN party waar ongeveer 30 mensen komen. Deze switch zal dus maximale belasting te verduren krijgen. Ik ben van plan een aantal 8 ports switches + servers aan deze 16 ports switch te gaan knopen en de dan nog vrije poorten aan pc's toe te wijzen (lijkt mij de beste opstelling). De vraag is dus welke switch het meest geschikt is.
Het enige grote verschil dat ik tussen de switches kan vinden is de prijs en de buffergrootte. De Sweex switch (www.sweex.nl/product.asp?pid=110&s=3) heeft bijv maar 256 kb aan buffer terwijl de SVEC (http://www.svec.com/Products/FD816EDS.HTM) 2 Mbyte zegt te hebben (zou dat niet 2 MBIT moeten zijn? Ik zie geen enkele switch met 2 Mbyte, zelfs de 3com officeconnect heeft 'maar' 1 MByte). In hoeverre kun je dat verschil merken?
Dat geheugen wordt toch gewoon gebruikt om packetjes op op te slaan, te kijken waar ze heen moeten en daarna via de juiste poort weg te sturen? Packetjes worden bij de SVEC dus minder snel weggegooid (omdat het niet meer in het buffer zou passen). De snelheid waarmee de packetjes geevalueerd worden is afhankelijk van de 'processor' die in die switch zit lijkt me, maar hier kan ik niks over vinden... moet ik maar aannemen dat dat dus ongeveer hetzelfde zal zijn?

De SVEC kost iets van 150 EURO en de sweex 66 EURO. Nogal een verschil! Alleen voor de buffer?

Welk nut heeft een groter MAC-adressen geheugen? hoeveel geheugen kost het om 1 MAC adres op te slaan? Ik neem aan dat dat alleen bij hele grote netwerken een rol gaat spelen.

In de C't magazine van December 2002 staat er ook een stukje over en daar zeggen ze dat een 8 ports switch genoeg heeft aan 2 MBIT aan buffer (256 kbyte), maar hoe ze daar bij komen staat er niet. Ik vraag me dan ook af of 512 kbyte dan 'genoeg' zou zijn voor een 16 ports switch.
Het zou leuk zijn een benchmark te zien van de SVEC en de sweex.

p.s. Ik ga er vanuit dat de backplane van al die switches gewoon 3.2 Gbit (dat is toch standaard tegenwoordig? hoewel de backplane bandbreedte bij de sweex niet vermeld staat.)

[ Voor 5% gewijzigd door Carnifex op 16-12-2002 15:40 ]

[TD-er]

Voor een dergelijk klein netwerkje als wat jij geschetst hebt, is een sweex snel zat.
een groter geheugen voor MAC-adressen is uiteraard alleen interessant voor grote netwerken. Groot als in >8000 actieve MAC-adressen gedurende de tijd waarbinnen het weer geflushed wordt(= 5 mins geloof ik)
de opslag van een MAC-adres kost 6 bytes. Ik weet niet hoe het intern gaat, wat betreft de opslag van de poort waarachter dat adres zit.
Qua opslag van de pakketten zou je niet veel ruimte nodig hebben, want het zou alleem maar gebruikt moeten worden voor pakketten die naar een poort gestuurd moeten worden, die bezet is omdat een ander pakket erheen moet.
Bij snellere netwerken (gbit) worden de pakketten vaak wat groter gemaakt, dus daar zou je met meer geheugen mogelijk wel een merkbaar snelheidsverschil kunnen krijgen.
Een nadeel van meer geheugen is wel dat je meer data moet gaan bijhouden op de switch en dan kan dat weer een vertragende factor worden. Mogelijk hebben de switches met meer geheugen er dus ook een snellere processor in zitten en dan is het weer appels en peren vergelijken.

Ik ben wel eens benieuwd hoe je die switches wilt gaan benchmarken.
Je zou met NetIO een benchmark kunnen uitvoeren, maar om dat goed te coordineren lijkt me nogal lastig (mischien met het at-commando onder linux). Naast dat je toch wel 8 - 16 vrijwel identieke computers nodig hebt.

[Carnifex]

Hmm, als ik het zo hoor zijn er niet zoveel 'interne' verschillen dus (hooguit managed of unmanaged).

Ik denk dat ik toch maar voor de Edimax 24 ports 19" rackmount ga. Wel heel iets anders dan waar ik naar vroeg, maar ik heb al een 8 ports Edimax switch die goed bevallen is op de vorige lan (stress-test overleeft).

Om simpel te benchmarken zat ik meer te denken aan het aansluiten van alle poorten en dan de helft van de pc's "ping -f" naar de andere helft uit te laten voeren. Dan moet de switch gewoon alle poorten van 100mbit voorzien. En dan kijken of er een (grote) packetloss optreedt. En anders is het ook nog te vergelijken met 2 pc's die met een cross-calbe verbonden zijn (ook een "ping -f") zodat je weet dat het niet aan het systeem/netwerkkaart of kabel ligt.

[DavidK]

Ik denk dat je switch geen probleem heeft met je ping -f. Een ping is niet echt een goede test om je switch te benchmarken. Probeer eerder een flink aantal ftp sessies verdeeld over een aantal systemen, maar dan vraag ik me nog af of je er iets mee bereikt. Je moet goede systemen hebben en goede netwerkkaarten wil je uberhaupt je 100Mbit vol krijgen.

[Carnifex]

Deze switches zijn Layer 2 netwerk apparaten, dus het protocol doet er niet toe. Het voordeel van "ping -f" is dat er gewoon het max haalbare uit de netwerkkaart naar de switch wordt gestuurd. Misschien zou het wel uitmaken als de ping packetjes een groter zijn en dus het interne geheugen van de switch sneller vol raakt.

[TD-er]

Pingen is inderdaad niet een goede test, daar die pakketten zo klein zijn.
Ik denk dat NetIO dan toch een beter idee geeft.
NetIO ontvangt als client de nodige pakketten van een op te geven NetIO server. Deze pakketten worden langzaam aan steeds groter (elke grootte wordt gedurende +/- 10 sec gemeten).

bijvoorbeeld (XP naar linux)

code:

D:\NetIO\bin>nt -t 192.168.101.1

NETIO - Network Throughput Benchmark, Version 1.14
(C) 1997-2001 Kai Uwe Rommel

TCP/IP connection established.
Packet size  1 KByte:   18455 KByte/s
Packet size  2 KByte:   20362 KByte/s
Packet size  4 KByte:   24371 KByte/s
Packet size  8 KByte:   31955 KByte/s
Packet size 16 KByte:   37106 KByte/s
Packet size 32 KByte:   43473 KByte/s

Dit voorbeeld is een beetje een extreem geval (Gbit crossed cable), zodat je goed het verschil tussen verschillende pakket groottes kunt zien. (van linux => linux is het vrijwel constant 45 MB/s) Bij 100 Mbit en een beetje rappe machines zul je veel minder verschil zien bij verschillende pakketgroottes.
Oftewel voor het testen van een switch is linux een betere keus, want dan kun je mooi zien wat de verschillen zijn met een switch.
Tot slot nog even de snelheid tussen een PIII733 en een P120, beide linux, beide aan een 100Mbit switch. (de PIII haalt naar een andere snelle computer makkelijk 9,5 MB/s over 100 Mbit, over dezelfde switch)

code:

TCP/IP connection established.
Packet size  1 k bytes:   5764 k bytes/sec
Packet size  2 k bytes:   5731 k bytes/sec
Packet size  4 k bytes:   5725 k bytes/sec
Packet size  8 k bytes:   5731 k bytes/sec
Packet size 16 k bytes:   5766 k bytes/sec
Packet size 32 k bytes:   5757 k bytes/sec

[Verwijderd]

Je wilt dus die 16 poorts switch als een soort 'core-switch' gaan gebruiken? Dus daar de servers rechtstreeks aanhangen, + enkele client switches via een 100mbit kabel aan deze switch koppelen? Als het een LAN party is voor 'maar' 30 man, zou ik proberen om bijv een 24 of (nog beter) een 48 poorts switch te lenen/huren/kopen. Want als je allerlei switches via 1 100 megabit verbinding aan die 'coreswitch' verbind, zal het netwerk heel traag worden, denk ik. Stel dat persoon A op clientswitch 1 zit, en hij wil wat van persoon B op clientswitch 2 kopieren. Maar tegelijkertijd kopieert ook persoon C op clientswitch 1 ook wat van persoon D op clientswitch 2 (vat je het nog? ). Nu gaan er dus 2 verbindingen via 1 100mbit lijntje naar de 'coreswitch', waardoor ieder dus maar 50mbit ter beschikking heeft. Dit is slechts een voorbeeldje, maar 't geeft wel aan dat de snelheid dan gedeeld wordt.