Prestandatester med 10 Gigabit

Vad är det för OS på burkarna? Den ena ser det ju ut att vara Windows på iaf

Det är inte så enkelt att lagringen inte hinner med så när minnesbufferten är full så går det "lite" långsammare?

Mina virtuella 2012or och 2012R2or uppför sig så i mycket större utsträckning än 2008R2orna. Har lekt lite med storage spaces och så fort bufferten är full så går det i Fast Ethernet -hastigheter, i bästa fall... Har inte ägnat hur mycket tid som helst åt det men har inte lyckats tweaka bort det.

Edit: såg att "hasenfrasen" hade samma teori i den andra tråden.

Om du kör de virtuallet , så kör inte Legacy network adapter ? då får du inte alls lika bra speeds.

Kan det vara så att vid GbE så hinner den "hålla undan" medan det blir knökfullt med 10GbE? Eller någon lustig inställning i drivisen till 10GbE NICet.

Kanske ska tillägga att jag kör ESXi 5.5 (då 5.1) och testerna gjordes mellan 2008R2 och 2012/R2 samt W7x64. Gjorde lite tester internt mellan VMar (på olika fysiska diskar) i ett försök att utesluta nätverksproblem men har för mig att jag fick samma resultat. Dvs att den chokade men jag är inte helt säker. Slutsatsen är iaf att jag vid stora överföringar får mycket jämnare och bättre prestanda mot 2008R2 än 2012/R2.

Oh intressant tråd.
Har själv precis fått hem HP 452372-001 Infiniband-kort och kablar. Har tänkt att skippa switchen och bara köra mellan två ESXi hostar och sen Nexenta i en triangeluppsättning.

Såg att du inte tänkt migrera till 2012 ännu, synd det skulle vara ett intressant test annars.

Testa att boota upp systemet via en USB-sticka med Linux och kolla prestanda med iperf, siffrorna du får nu verkar löjligt låga.

Även om jag klockar ner en i7-4670T till 800MHz (scaling governor "power-save" i Linux) så rapporterar iperf över 9GBit/s med den förvalda fönsterstorleken och en MTU på 1500.

Kör med "82599EB 10-Gigabit SFI/SFP+ Network Connection" (kodnamn "Niantic", ett 10Gbit/s Ethernet kort över fiberkablar) och Ubuntu 12.04LTS server. Med Infiniband har du lägre latens än vad jag får med 10Gbit/s Ethernet.

Edit: vad det gäller optimeringar har jag ganska precist lekt lite med olika angreppssätt för att skriva program som kan hantera så många transaktioner/s över nätverket som möjligt. En sak jag lärde mig då var att alla former av frekvensskalning på CPUn tenderar minska kapaciteten en hel del då det tar rätt mycket tid för CPUn (med tanke på att du kan ha upp till 14miljoner paket per sekund i båda riktningarna på ett 10Gbit/s NIC).

Du har en i7 3820 (Sandy Bridge), så den tar minst 10µs för att byta frekvens. Vet inte hur man läser ut exakt värde i Windows, men på Linux kan du göra detta

$ cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency
10000

På min Haswell maskin ser man att det är 10000ns = 10µs.

Så steg ett är att alltid köra på max-frekvens (max s.k. P-state), den viktigsta strömsparfunktionen är ändå det man kallar C-states som CPUn hoppar mellan när den jobbar och inte har något att göra. Att hoppa mellan C0 (CPU jobbar) och C1 (CPU sover, men väldigt "lätt") tar runt 1µs, enda sättet att aldrig hoppa in i C1 är att aldrig anropa något som kan "blocka", finns sådana system men då åker strömförbrukningen upp rejält och det är definitivt overkill att undvika C1 i ditt fall.

Du bör också ha en fönsterstorlek på 20-100kB, exakt storlek beror lite på latens men den ska ju vara riktigt låg på Infiniband så du ska klara dig med rätt små fönster. Allt för stora fönster kommer leda till att du fyller CPU-cachen med så mycket data att risken är att saker skrivs över innan du ska till och använda det.

Varför bara MTU på 1500 byte? Testa att öka MTU till t.ex. 9k och labba sedan med fönsterstorlek.

Hur är det när du flyttar filer som är mindre än totala ram mängden?

skulle du kunna plotta en graf på hur hastigheten sänks över tid?

bråkar med liknande problem, dock bara över gbit, men det är riktigt frustrerande när hastigheten dalar ner när man flyttar större filer

Inser att de tester som är gjorda mot disk kan ha andra flaskhalsar, men att bara ligga på ~6Gbit/s med en i7-3820 verkar skumt. Nu är motparten en Celeron 847 som bara går på 1.1Ghz (och är Sandy Bridge-baserad), men den är ändå helt i nivå med en i5-4670T klockad på 800Mhz som inte har några problem att fixa 9.35Gbit/s, hade iperf låst till en CPU-kärna och lasten låg en bra bit under 100% på den kärnan så de 2-kärnornarna i Celeron 847 borde orka mer.

iperf genererar sin traffik direkt från RAM, så finns inga flaskhalsar förutom CPU och NIC.

Så ett steg är kanske att köra Linux på Celeron-maskinen så den inte längre blir en flaskhals, i alla fall när man utför tester.

Jag körde Ubuntu 12.04 på båda maskinerna (en i5 4670T klockad @ 800MHz och en i7 2600 @ 3.4Ghz), har tyvärr inga Windows-maskiner med 10Gbit/s NICar i (de har som bäst 1Gbit/s), så kan inte testa en sådan konfiguration.

$ iperf -c 172.20.1.2
------------------------------------------------------------
Client connecting to 172.20.1.2, TCP port 5001
TCP window size: 23.5 KByte (default)
------------------------------------------------------------
[  3] local 172.20.1.1 port 57010 connected with 172.20.1.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  10.9 GBytes  9.35 Gbits/sec

I ditt fall är ju Celeron-maskinen den stora flaskhalsen, så du skulle kunna testa att boota upp Linux på en USB-sticka och köra "iperf server" på den maskinen. Antar att det är din i7-3820 som du vill testa så den måste ju köra Windows då det är OSet du vill använda.

TCP/IP-stacken i Windows har med åren blivit väldigt bra (sedan Vista) på att följa specifikationerna, men den är fortfarande väldigt ineffektiv jämfört med Linux TCP/IP-stack (som för övrigt blivit väldigt mycket bättre på att utnyttja många CPU-kärnor för 3-4 år sedan, 2.6.32->2.6.38).

Såg att du testade med en fönsterstorlek på 1M, det är definitivt för stort med tanke på att latensen mellan dina maskiner lär ligga på µsekund-skala. Du vill ha så litet fönster som möjligt men där den s.k. bandwidth-delay-product ändå så pass hög att fönstret inte är en flaskhals. Så anta att du har 100µs latens (jag får <100µs latens över Ethernet, Infiniband har ännu lägre latens) och du vill ha kapacitet för 10Gbit/s, ditt fönster måste då minst vara

10Gbit/s / 8bits/byte * 100µs = 10*10^9 / 8 * 10 * 100^-6 = 10*10^3 / 8 * 100 = 125kB

Tror det ändå kan vara CPUn som är flaskhals då en TCP/IP stack inte är begränsad av RAM-bandbredd på en modern CPU utan endera begränsad av kapaciteten på nätverket eller hur snabbt CPUn kan köra heltalsintensiv kod. Noterade när jag körde både servern och klienten på samma maskin att server-instansen av "iperf" drog mycket mer CPU-kraft än klient-instansen.

I detta test drog en fiber mellan två portar på samma maskin och placerade de två portarna i olika s.k. "network namespace", en form av virtualisering där man bara har 1 OS-kärna, men kan ha flera separerade userland instanser, är i praktiken noll "overhead". Körde på i7 2600 maskinen och låste ner server och klient-instansen på olika kärnor. Får även i detta fall >9Gbit/s.

De jämförelser jag gjort mellan Win7 och Linux för något år sedan antyder att Windows använder ungefär 3x så mycket CPU-cykler jämfört med Linux för att skicka/ta emot data via socket APIet.

Kan jag med tre kort av exempelvis denna sort skapa ett litet "kluster" där alla tre noder har direkt kontakt med övriga, utan switch?
Låter för billigt och enkelt för att vara sant...
Hur har du trivts med din hårdvara?

Japp du kan köra en trekant (höhö)
Jag kör dessa kort i mina Vmware ESXi hostar och min lagringsbox
Jag ett kort i en dator som agera lagringsbox och sen varsin anslutning direkt till två ESXi Hostarna. Prisskillnaden mellan 2 portars och 1 är marginell så köp inte 1-portars kort. De två portarna du får över kan du ansluta ihop (direkt mellan ESXi hostarna) och via den kör du tex vMotion

Nämen vad trevligt!
Grejar man det om man är en mindre avancerad användare tro? Jag är snarare en matematik- och hårdvaruentusiast.
Jag föreställer mig att jag kör debian. En utmaning blir (tror jag) att få ordning på MPI, det är avgörande för detta projekt.
Vilka problem ska man vara beredd på?

Jag har faktiskt inte satt upp det på debian. Kör man det på ESXi så finns det ett VIB-paket och sen göra man lite konfigurationer i ett par filer och sen är man igång.