Begrip bottleneck gigabit netwerk

[Jojakim]

Ik ben een beetje aan het onderzoeken wat een wijze serveroplossing is voor de toekomst en vroeg me het volgende af in hoeverre een gigabit-netwerk een bottle neck vomt.

Om ijn vraag zo te stellen: als ik twee desktops zou verbinden via gigabit via een degelijke intel NUC en HP switch met jumbo frames ingesteld. In opstelling 1 zitten in beide desktops een standaard SSD (bv een crucial bx100) en in opstelling 2 vervang ik beide SSD's voor flink snelle disks, bijvoorbeeld Samsung 950 Pro.

Zou ik in geval 2 betere overdrachtsnelheden krijgen voor bijvoorbeeld een bulk kleine bestanden, of zorgt de bottle neck van gigabitverbinding voor zelfde snelheden?

[Eboman]

specificaties geven aan dat die crucial 550MB/s doet, dat is dus 4400mbit/s.

Je netwerk zou dus eerst de bottleneck vormen als je bij de theorie blijft, die SSD maakt dus niets uit voor je transfers.

[ Voor 8% gewijzigd door Eboman op 02-03-2016 16:39 ]

[Paul]

Tja, wat noem je een bottleneck. Hoe vaak ga je het doen en hoeveel geld heb je er voor over om het op te lossen? Een SSD valt overigens al onder "flink snelle disk", en een 950 Pro is ook 'gewoon' een SSD

Over gigabit grote bestanden kopiëren gaat makkelijk met (meer dan) 100 MB/sec, mits je storage het trekt. In geval van moderne SSD's is dat geen enkel probleem. Bij kleine bestandjes komt overhead kijken, en haal je minder. Hoeveel minder is niet zomaar te zeggen.

Andersom, om boven gigabit uit te komen zijn er niet zoveel opties. De goedkoopste is om meerdere gigabit netwerkkaarten in een team / link aggregation te zetten, het load-balance mechanisme vertellen een algoritme te gebruiken dat niet afhankelijk is van de bron of het doel (want die zijn steeds hetzelfde) _en_ meerdere connecties tegelijkertijd openen (of niet teamen en met verschillende subnetten werken), anders gaat het nog steeds maar over één netwerkkaart.

De andere optie is 10 gigabit, en dan ben je zo 1000 euro verder, terwijl die gigabit-link je zo goed als niets kost.

[Brahiewahiewa]

Jojakim schreef op woensdag 02 maart 2016 @ 16:30:
...met jumbo frames ingesteld..

Dat levert je nog geen 2% snelheidswinst op

[Jojakim]

Misschien wat eenvoudiger gesteld: wat zouden deze statistieken worden wanneer je deze benchmark zou uitvoeren via een gigabit-verbinding:

http://nl.hardware.info/r...m2-ssds-as-ssd-deelscores

[ Voor 48% gewijzigd door Jojakim op 02-03-2016 20:27 . Reden: handiger geformuleerd ]

[ijdod]

Hangt van een heleboel variabelen af, die grotendeels los staan van het link zelf. De gebruikte protocollen, de implementatie van die protocollen, afstand (latency), enzovoorts.

[Gravit0n]

Brahiewahiewa schreef op woensdag 02 maart 2016 @ 17:27:
[...]

Dat levert je nog geen 2% snelheidswinst op

Dat varieert nogal...

[brid]

Krijg je ongeveer zoiets:


Was wel 6 jaar geleden, raid5 met 5x 1.5TB schijven

[ijdod]

Gravit0n schreef op donderdag 03 maart 2016 @ 11:03:
[...]


Dat varieert nogal...

Niet echt. De doorvoer wordt netto wat hoger omdat de verhouding payload/headers gunstiger wordt, maar dat is uiteindelijk maar een paar %. De winst van jumboframes zit hem op de verwerkingsoverhead op systemen aan beide kanten. Dat laatste is weer erg afhankelijk van de specifics van het betreffende systeem. Meestal is het een kludge om andere suboptimale componenten te omzeilen.

[DukeBox]

Brahiewahiewa schreef op woensdag 02 maart 2016 @ 17:27:
[...]

Dat levert je nog geen 2% snelheidswinst op

Zoals eerder genoemd is, het hangt erg af van het type data of het gunstig is of niet.

Daarnaast, over het algemeen gebruik je jumbo frames alleen maar als deze je netwerk niet verlaten en p2p geen fragmentatie plaatsvind.
Als er bijv. ook verkeer over je internet router gaat heb je alleen maar hinder van de latency.
Ook dingen als flow control die op auto switches standaard aanstaan (en niet uit te zetten is) kan hierbij negatieve invloed hebben, zeker bij kleiner port buffers.

[Gravit0n]

ijdod schreef op donderdag 03 maart 2016 @ 22:00:
[...]

Niet echt. De doorvoer wordt netto wat hoger omdat de verhouding payload/headers gunstiger wordt, maar dat is uiteindelijk maar een paar %. De winst van jumboframes zit hem op de verwerkingsoverhead op systemen aan beide kanten. Dat laatste is weer erg afhankelijk van de specifics van het betreffende systeem. Meestal is het een kludge om andere suboptimale componenten te omzeilen.

Van wat ik uit dit stukje begreep is dat het vooral afhankelijk van de CPU van verschillende machines.

Is het voordeel van jumbo frames dan meer merkbaar op oudere of minder (CPU) krachtigere apparatuur?
Thuis kan ik die gigabit wel voltrekken zonder jumbo frames, maar ik heb verder geen spannende apparatuur staan.

[ijdod]

Daar komt het, kort door de bocht, wel op neer. Jumbo frames was een vrij eenvoudig te implementeren feature in de tijd dat geavanceerde hardware offloading nog geen gemeengoed was. Inmiddels is dat (grotendeels) achterhaald (die post op smallnetbuilder is ook alweer 9 jaar oud, en haalt zelf dingen aan van voor de eeuwwisseling).

Je kan eigenlijk stellen dat als je niet in detail weet waarom je ze nodig hebt, je ze niet nodig hebt; in de zin dat de use-cases dusdanig specifiek zijn dat als je je daar mee bezig houdt, je ook hiermee bekend bent. Wat uiteraard geen reden is om er als tweaker niet mee te spelen

[ Voor 16% gewijzigd door ijdod op 04-03-2016 21:18 ]

[Ben(V)]

Jumbo frames werken contra productief als je goede hardware hebt.

Door de jumbo frames krijg je iets minder overhead omdat de packages groter zijn, maar dat is in aantallen bytes te verwaarlozen.

Vroeger hadden de cpu's meer moeite om die stuur bytes te scheiden van de data bytes, maar tegenwoordig doet zelfs de goedkoopste instap cpu dat op z'n sloffen.
Sterker nog het is tegenwoordig verstandiger de offload capaciteiten van de nic uit te zetten, omdat de cpu dat vele malen sneller kan dan de nic hardware.

Dat kleine beetje voordeel dat je krijgt van een beetje minder overhead weegt niet op tegen het nadeel dat je krijgt doordat de package groter zijn.

Als de data bijvoorbeeld 1 byte groter is dan dan een veelvoud van de package size dan hebt je bij jumbo frames ineens 9000 - 1 bytes overhead extra en bij normale frames maar 1500 -1 .

Bij fragmentatie op het netwerk kan dit zelfs zo erg worden dat jumbo frames duidelijk trager zijn dan normale frames.
Ook kleine bestanden overzetten of kleine data packages zoals internet verkeer hebben alleen maar nadeel van jumbo frames.

[ Voor 5% gewijzigd door Ben(V) op 04-03-2016 22:43 ]

[DukeBox]

Ben(V) schreef op vrijdag 04 maart 2016 @ 22:41:
Sterker nog het is tegenwoordig verstandiger de offload capaciteiten van de nic uit te zetten, omdat de cpu dat vele malen sneller kan dan de nic hardware.

Heb je daar een bron van ?

Als de data bijvoorbeeld 1 byte groter is dan dan een veelvoud van de package size dan hebt je bij jumbo frames ineens 9000 - 1 bytes overhead extra en bij normale frames maar 1500 -1 .

Maar dat is juist hét idee van jumbo frames, de belasting is gelijk, het blijft dezelfde handeling alleen kán er meer data in. Tuurlijk is er meer kans op overhead maar omgekeerd geld het zelfde.

Bij fragmentatie op het netwerk kan dit zelfs zo erg worden dat jumbo frames duidelijk trager zijn dan normale frames.
Ook kleine bestanden overzetten of kleine data packages zoals internet verkeer hebben alleen maar nadeel van jumbo frames.

Dat was ook al eerder genoemd, je moet het niet voor internet verkeer gebruiken, alleen intern. Gelukkig hebben de betere routers geen problemen met fragmenteren en is de internet verbinding zelf vaak de bottleneck.

[Ben(V)]

De bron is overal op het internet te vinden en wordt gestaafd door mijn eigen testen.

Alle offload instellingen van de nic uitzetten en ook xon-xoff uit krijg je duidelijk een hogere en stabielere snelheid op je lan.

Ook het gebruik van jumbo frames heb ik uitgebreid getest, maar levert maar heel zelden voordeel op en meestal nadeel.

Fragmentatie op je lan treed uiteraard alleen op als er meer dan een verkeersstroom is, maar als dat het geval is treed het ook altijd op.
Dit is per definitie van het medium ethernet.

[DukeBox]

Ben(V) schreef op vrijdag 04 maart 2016 @ 23:40:
De bron is overal op het internet te vinden en wordt gestaafd door mijn eigen testen.

Ik heb dat niet ergens kunnen vinden. Wat was dan de uitkomst van je testen ? Over het algemeen zorgt een TOE voor lagere latency, minder verkeer op je PCI(e) bus én minder interrupts op je CPU (ook een van de voordelen van jumbo frames overigens).

[ Voor 12% gewijzigd door DukeBox op 04-03-2016 23:49 ]

[johnkeates]

Ja, je netwerkverbinding is dan langzamer dan je schijven kunnen lezen en schrijven. Zodra je meer dan 110MB/sec kan verwerken is 1 Gigabit niet meer genoeg als je de volledige snelheid van je data opslag wil kunnen gebruiken over een netwerkverbinding. Je kan naar 10Gbit ethernet kijken, of zaken zoals Infiniband.

[fast-server]

Die 1000Mbps is gewoon niet realistisch op een NUC, je haalt eerder 100Mbps met een max van net geen 400Mbps afhankelijk van het type bestand.

Dit komt puur omdat de onboard oplossingen zo goed als alle load door de CPU laten afhandelen, en de CPU op een NUC of andere mini PC is meestal niet 1 van de snelste.

Als je echt sneller wil dan ontkom je niet aan een goede Intel NIC welke hardware matig het verkeer afhandelt zonder een al te hoge CPU load.

Een leuk ITX systeem met losse NIC is veel sneller en gebruikt amper meer als de componenten goed gekozen zijn, dit komt omdat deze veel sneller klaar is door de hogere doorvoer snelheid. (veel minder CPU load)

[RGAT]

Met SMB3 heb je geen LACP enz. nodig en worden meerdere 1Gb (of andere snelheden) links tegelijk gebruikt, ook voor 1 copy opdracht waardoor je met bijv. twee 1Gb links ergens in de 1.5-2 Gb/s kan halen.
Maar dit is alleen met SMB3 (vziw) dus alle andere zaken zullen max. 1Gb doen.
Je zou kunnen kijken naar 10GbE, op eBay zijn zat kaartjes te vinden voor weinig die 10GbE doen.
Dan moet je btw wel een directe link van de server naar 1 client doen aangezien 10GbE switches voor de meeste nog te duur zijn.

Maar het hangt er vooral vanaf wat je ermee wil doen, ik neem aan dat je niet de hele dag bestanden van de ene SSD naar de andere gooit en 1Gb is meestal zat.

[ Voor 27% gewijzigd door RGAT op 05-03-2016 02:25 ]

[Ben(V)]

fast-server schreef op zaterdag 05 maart 2016 @ 02:05:
Die 1000Mbps is gewoon niet realistisch op een NUC, je haalt eerder 100Mbps met een max van net geen 400Mbps afhankelijk van het type bestand.

Dit komt puur omdat de onboard oplossingen zo goed als alle load door de CPU laten afhandelen, en de CPU op een NUC of andere mini PC is meestal niet 1 van de snelste.

Als je echt sneller wil dan ontkom je niet aan een goede Intel NIC welke hardware matig het verkeer afhandelt zonder een al te hoge CPU load.

Een leuk ITX systeem met losse NIC is veel sneller en gebruikt amper meer als de componenten goed gekozen zijn, dit komt omdat deze veel sneller klaar is door de hogere doorvoer snelheid. (veel minder CPU load)

Dit is onzin.
Zelfs een nuc is vele malen krachtiger dan bijvoorbeeld een Nas en beiden halen met gemak de theoretische maximale snelheid die een 1Gb netwerk toelaat.
Zoals al aangegeven elke cpu doet dat tegenwoordig op z'n sloffen.

[Ben(V)]

RGAT schreef op zaterdag 05 maart 2016 @ 02:24:
Met SMB3 heb je geen LACP enz. nodig en worden meerdere 1Gb (of andere snelheden) links tegelijk gebruikt, ook voor 1 copy opdracht waardoor je met bijv. twee 1Gb links ergens in de 1.5-2 Gb/s kan halen.
Maar dit is alleen met SMB3 (vziw) dus alle andere zaken zullen max. 1Gb doen.
Je zou kunnen kijken naar 10GbE, op eBay zijn zat kaartjes te vinden voor weinig die 10GbE doen.
Dan moet je btw wel een directe link van de server naar 1 client doen aangezien 10GbE switches voor de meeste nog te duur zijn.

Maar het hangt er vooral vanaf wat je ermee wil doen, ik neem aan dat je niet de hele dag bestanden van de ene SSD naar de andere gooit en 1Gb is meestal zat.

Alleen SMB3 op windows heeft multiipath io.
Op Samba is dit nog niet geimplementeerd en dat gaat nog wel even duren ook.
Het nut van hoge netwerk snelheid ligt enkel bij grote data hoeveelheden en dan heb je al gauw een NAS nodig en die draaien meestal linux en zijn dus afhankelijk van Samba.

Een alternatief is een server versie van windows te gebruiken, dan kun je nic teaming gebruiken en meerdere nics inzetten. Maar ook hier alleen window-window connecties.
Moet je wel intel server nics hebben, want de desktop versies ondersteunen dat niet.

Kortom alle alternatieven zijn lastig en duur en voorlopig is de max 1Gb en kun je voor meer capaciteit enkel meerdere nic's in LACP inzetten, maar dat verhoogt de maximale snelheid niet, alleen de bandbreedte.