Surkea 10GbE yhteys palvelimen ja pöytäkoneen välillä.

Liittynyt
07.03.2017
Viestejä
184
Hellurei!

Viime aikoina ongelmana on ollut vajaatehoinen 10GbE yhteys palvelimen ja pöytäkoneen välillä. iperf antaa bandwidth vain max 8.56Gbits/s, yleensä pyörien jossain 5-7Gbits/s. Myös RAMdiskiin CrystalDiskMark antaa vain n. 600-700MB/s luku- ja kirjoitusnopeutta.

Koneet on yhdistetty 5m CAT6a johdolla, palvelimessa Intelin X550-T2 kun pöytäkoneessa Asuksen XG-C100C (Aquantia). Windowsiin on asennettu ekaksi Asuksen ajurit, sitten päivitetty Aquantian uusimmat (uudemmat kuin Asuksen). Ei ratkaise. Laitettu Jumbo Framet (9014, koska Asus ei anna säätää tasan 9000). Ei auta.

Palvelimessa on Ubuntu Server 18.04 LTS ja pöytäkoneessa W10Pro 64bit. Suorittimina on palvelimessa Xeon E5-1650v4 ja pöytäkoneessa i7-5960X.

iperfiä testatessa Ubuntussa, välillä tulee herja, että esim. vaadittua "-w 512k" ei käytetä, vaan 416Kbytes. Syytä en tiedä miksi, saman tekee vaikka vaihtaisi 1024k. Molemmissa päissä iperfissä on samat -w arvot.

Link Speed on sekä Ubuntussa että W10:ssa manuaalisesti laitettu 10GbE.

Ideoita missä kiikastaa? Mistä kohtaa vois korjailla? Mitä tehdä? Ideat on minulta loppu.


Offtopic:
Lainaus Linukselta sopii tähän aivan hiton hyvin:
"Network crap is never that easy"
 
Ei noihin lukemiin ainakaan kovin merkittävää parannusta voi saada vaikka minkä tekisi.
 
Onko se joskus toiminut täydellä nopeudella?

Paljonko prosessorin käyttöaste on testatessa?

Kaapelin pituus ja laatu? Onko mahdollista kokeilla paremmalla kaapelilla, vaikka Cat7:llä?
 
Cat6 kaapeli? Kuinka pitkä?
CAT6a, 5m kuten yllä sanotaan.
Oletko testannu Auto asetusta?
Olen, ei apua.
Onko se joskus toiminut täydellä nopeudella?

Paljonko prosessorin käyttöaste on testatessa?

Kaapelin pituus ja laatu? Onko mahdollista kokeilla paremmalla kaapelilla, vaikka Cat7:llä?
En ole ennen testannut nopeutta, joten en osaa sanoa. Prosessorin käyttöaste on 13% Windowsissa, kun Ubuntussa pyöritään 10%, normaalisti 2-6% (CrystalDiskMark tosin pyörii vain alle 1% käyttöasteella Windowsissa).

Kaapeli on CAT6a ja 5 metrinen. CAT7 ei ole tarjolla, mutta pistin tänään Saksasta toisen valmistajan CAT6a 5m johdon tilaukseen, katsotaan korjaako se tilannetta.
 
Saako verkkokorttien ajureiden asetuksista send & receive buffereita kasvatettua?

Jos tcpdumppaat (Wiresharkkaat) liikennettä, niin ovatko ethernetframet saman kokoisia kumpankin suuntaan ja oletko tuunannut linux-puolen framet saman kokoisiksi kuin windowssilla?

Sadoissa megoissa/sekunti mitattavat ramdisk-nopeudet kuulostavat huonoilta, mutta en tiedä mitä niiden pitäisi olla.
 
Prosessorin käyttöaste on 13% Windowsissa,
Montakos corea/threadia sulla oli? Jos softa on single thread ja koneessa 8 säiettä niin 13% tarkoittaa että yksi core huutaa punaisena. Oletko testannut sammuttaa kaikki taustasovellukset? Saako silloin parhaat tulokset?
 
CAT6a, 5m kuten yllä sanotaan.

Olen, ei apua.

En ole ennen testannut nopeutta, joten en osaa sanoa. Prosessorin käyttöaste on 13% Windowsissa, kun Ubuntussa pyöritään 10%, normaalisti 2-6% (CrystalDiskMark tosin pyörii vain alle 1% käyttöasteella Windowsissa).

Kaapeli on CAT6a ja 5 metrinen. CAT7 ei ole tarjolla, mutta pistin tänään Saksasta toisen valmistajan CAT6a 5m johdon tilaukseen, katsotaan korjaako se tilannetta.

8-ytimisellä (Hyperthreading ym. mukaan lukien) prosessorilla Windowsin tehtävienhallinta näyttää käyttöasteeksi 12-13%, jos yksi ydin käy täysillä (100/8 = 12.5). Jos kyse on tästä, eli joku suorituskyvyn kannalta kriittinen osa pyörisi yhden ytimen varassa, se voisi selittää jotain. Tämä on toki ihan puhdasta spekulointia.

Se kannattaa huomata myös, että Windows voi jakaa yksisäikeistä kuormaa useammalle ytimelle, jolloin useampi ydin näyttää olevan hommissa, mutta jos kuormat laskee yhteen, saadaan summaksi vain yhden ytimen täysi kuorma.

Linuxissa riippuu käytetystä prosessienhallintatyökalusta, miten prosessorikuorma näytetään.

Cat6a:n pitäisi toki sopia 10 Gb/s yhteydelle, mutta onko jokin syy, miksi et tilaisi saman tien Cat7-kaapelia?

e: hidas, ja täydennyksiä.

zepi sanoi:
Sadoissa megoissa/sekunti mitattavat ramdisk-nopeudet kuulostavat huonoilta, mutta en tiedä mitä niiden pitäisi olla.

Verkon yli tässä vissiin siirrettiin, eli verkkolevylle, joka on serverin päässä ramdiskillä? 700 MB/s = 5.6 Gb/s, eli täydestä 10 Gb/s nopeudesta jäädään vähän, mutta suuruusluokka on hyvinkin järkevä, kun verrataan iperf:in tuloksiin.
 
Viimeksi muokattu:
Saako verkkokorttien ajureiden asetuksista send & receive buffereita kasvatettua?

Jos tcpdumppaat (Wiresharkkaat) liikennettä, niin ovatko ethernetframet saman kokoisia kumpankin suuntaan ja oletko tuunannut linux-puolen framet saman kokoisiksi kuin windowssilla?

Sadoissa megoissa/sekunti mitattavat ramdisk-nopeudet kuulostavat huonoilta, mutta en tiedä mitä niiden pitäisi olla.
Kyllä niiden pitäisi olla enemmän kuin 10GbE, sen verran osviittaa voin antaa. Minusta nuo framet pitäisi olla samat Ubuntussa, että Windowsissa (Jumbo frame ainakin), mutta onko ideoita miten tuon voisi helpoiten varmistaa? iperf jostain syystä pakottaa tuon Socket buffer sizen automaattisesti 416K, kun mennään 512k tai suuremmaksi.

Transfer and Receive buffer on molemmat niin tapissa Windowsissa, että Ubuntussa (säädetty Ethtoolilla).

Montakos corea/threadia sulla oli? Jos softa on single thread ja koneessa 8 säiettä niin 13% tarkoittaa että yksi core huutaa punaisena. Oletko testannut sammuttaa kaikki taustasovellukset? Saako silloin parhaat tulokset?
Molemmat koneet on 8 ydin prosessoreita, eli 8 core ja 16 Threadia. Katsoin että kummassakaan koneessa mikään ydin ei ole punaisena. Taustaohjelmat eivät vaikuta tuloksiin.

8-ytimisellä (Hyperthreading ym. mukaan lukien) prosessorilla Windowsin tehtävienhallinta näyttää käyttöasteeksi 12-13%, jos yksi ydin käy täysillä (100/8 = 12.5). Jos kyse on tästä, eli joku suorituskyvyn kannalta kriittinen osa pyörisi yhden ytimen varassa, se voisi selittää jotain. Tämä on toki ihan puhdasta spekulointia.

Se kannattaa huomata myös, että Windows voi jakaa yksisäikeistä kuormaa useammalle ytimelle, jolloin useampi ydin näyttää olevan hommissa, mutta jos kuormat laskee yhteen, saadaan summaksi vain yhden ytimen täysi kuorma.

Linuxissa riippuu käytetystä prosessienhallintatyökalusta, miten prosessorikuorma näytetään.

Cat6a:n pitäisi toki sopia 10 Gb/s yhteydelle, mutta onko jokin syy, miksi et tilaisi saman tien Cat7-kaapelia?

e: hidas, ja täydennyksiä.
Huonompi saatavuus on syy miksi en tilannut CAT7-kaapelia, ja kyllä järjen mukaan CAT6a pitäisi tuon yhteyden toimia, koska matka on hyvinkin pieni.


Verkon yli tässä vissiin siirrettiin, eli verkkolevylle, joka on serverin päässä ramdiskillä? 700 MB/s = 5.6 Gb/s, eli täydestä 10 Gb/s nopeudesta jäädään vähän, mutta suuruusluokka on hyvinkin järkevä, kun verrataan iperf:in tuloksiin.
Minusta tässä ei jäädä vähän, koska jäädään miltei puoleen. RAMDiskit on molemmissa päissä kuitenkin testien mukaan nopeat, joten johonkin tuota dataa katoaa.
 
Kyllä niiden pitäisi olla enemmän kuin 10GbE, sen verran osviittaa voin antaa. Minusta nuo framet pitäisi olla samat Ubuntussa, että Windowsissa (Jumbo frame ainakin), mutta onko ideoita miten tuon voisi helpoiten varmistaa? iperf jostain syystä pakottaa tuon Socket buffer sizen automaattisesti 416K, kun mennään 512k tai suuremmaksi.
Parhaiten siellä johdossa menevän tavaran näkee siitä packet capturesta.

Linuxissa tcp-dump, windowssissa wireshark. Kumpiakin dumppeja voi tarkastella windowssin guilla.

Linuxin tcp-dumpilla voinee kyllä komentoriviltäkin filtteröidä ethernet framejen koot.
 
Cat6 Verkkokaapeli | BCC Solutions Oy

Cat6 verkkokaapeli
Cat6 kaapeli (category 6 cable) on standardisoitu kuparikaapeli, jota käytetään Ethernet-yhteyksissä sekä muissa tietoverkkoratkaisuissa. Cat6 kaapeli on kierretty parikaapeli, jossa on kahdeksan johdinta jotka ovat kierretty pareiksi. Kaapeli on yhteensopiva aikaisempiin Cat5/5e ja Cat3 -standardeihin. Cat6 on edeltäjiinsä verrattuna edistyksellisempi kaapeliratkaisu, joka mahdollistaa nykypäivän vaatimusten mukaiset nopeudet. Cat6 verkkokaapeli on standardoitu 250 MHz:iin asti.

Siinä missä Cat6 kaapeli on tarkoitettu 1Gbit nopeuksiin asti on Cat6A määritelty jopa 10Gbit yhteyksiin asti. 10GBASE-T ratkaisuissa käytetään Cat6A kaapelia. Cat6A on rakennettu soveltuvaksi 500MHz:in ja sen tiedonsiirto ominaisuudet ovat erinomaiset 10GBASE-T yhteyksissä.

Cat6A-standardi on määritelty ANSI/TIA-568-C.1 asetuksessa vuonna 2009. Cat6A on määritelty 500 MHz:iin asti. Kun Cat6 kaapelia käytetään 1000GBASE-T yhteyksissä, on kaapelin maksimipituus 100 metriä. Jos käytössä on 10GBASE-T suojaamaton Cat6A-yhteys, kaapelin pituus ei saisi olla yli 55 metriä.
 
CAT6 kaapelin speksit on kyllä tiedossa, kuten myös CAT6a, joten niistä ei tarvitse valistaa. Periaatteessa 10GbE on saatu toimimaan jopa CAT5e kaapelilla kun ajetaan lyhyitä matkoja (laadukas johto).

Ja kyllä, ymmärrän että he markkinoivat että tekevät/myyvät johtoja myös, mutta tuo on enimmäkseen yritysmyyntiin suunnattu yritys, joten...
 
Oletko kokeillu laittaa tuo Asus palvelimeen ja Intel pöytäkoneeseen?
 
Millaiseen nopeuteen sä sitten olisit tyytyväinen?

Paljonko se CrystalDiskMark antaa paikallisella levyllä testattuna?
 
Oletko kokeillu laittaa tuo Asus palvelimeen ja Intel pöytäkoneeseen?
Vaikea vaihtaa kun tuo Intel on juotettuna emolevyssä kiinni :D Tekisin kyllä hetimiten tuon jos olisi mahdollista
Millaiseen nopeuteen sä sitten olisit tyytyväinen?

Paljonko se CrystalDiskMark antaa paikallisella levyllä testattuna?
Tavoitteena olisi saada 10GbE toimimaan 10GbE nopeudella, eli antamaan täysi kaista. Ethän sinäkään V12 autoa ostaessa halua että se vain toimii V6:sena. CrystalDiskMark antaa RAMdiskille sen reilun 6GB/s lukua ja kirjoitusta, ja samaa suuntaa antaa tuo palvelimenkin RAM (uskoisin, koska muisti on nopeampaa, matalammalla viiveellä ja ECC). Eli RAMdisk ->10GbE-> RAMdisk pitäisi kyllä minusta saturoida tuo linkki, jota ei kuitenkaan tällä hetkellä tapahdu.

Miksi sitten nipotan tästä? Sen takia että jotain tuolla on pielessä, koska ajoittain nopeudet ovat melko alhaisia, eli jotain siellä on pielessä, mutta en tiedä mitään. Myöskin, tuo kovosetuppi mitä käytän palvelimessa ei vielä saturoi 10GbE, mutta tuleva päivitys nostaa nopeudet yli tuon missä nyt ollaan ns. jumissa (teoreettinen laskettu nopeus). Eli toiveissa olisi päästä sinne 1000MB/s nopeuksiin.
 
Vaikea vaihtaa kun tuo Intel on juotettuna emolevyssä kiinni :D Tekisin kyllä hetimiten tuon jos olisi mahdollista

Tavoitteena olisi saada 10GbE toimimaan 10GbE nopeudella, eli antamaan täysi kaista. Ethän sinäkään V12 autoa ostaessa halua että se vain toimii V6:sena. CrystalDiskMark antaa RAMdiskille sen reilun 6GB/s lukua ja kirjoitusta, ja samaa suuntaa antaa tuo palvelimenkin RAM (uskoisin, koska muisti on nopeampaa, matalammalla viiveellä ja ECC). Eli RAMdisk ->10GbE-> RAMdisk pitäisi kyllä minusta saturoida tuo linkki, jota ei kuitenkaan tällä hetkellä tapahdu.

Kyllä siitä V12 moottoristakin katoaa 10-20% voimansiirtohäviöinä ennen kuin se kiihtyvyytensä tuntuu.

Se 10 Gbps nopeus on se raaka yhteysnopeus, kun varsinaista dataa ruvetaan siirtämään osa kapasiteetista menee datapakettien käsittelyyn, joten tuo sun saama 8.56Gbits/s on kyllä oikealla hehtaarilla.
 
Jumbo framet molemmissa päissä 9014 kokoiset? Tuolla matkalla piuha tuskin vaikuttaa jotenkin enemmänkin varmaan kiinni jomman kumman pään verkkokortista tms
 
Windows... mikähän mahtaa olla antivirus softan vaikutus, kannattas varmaan disabloida kokeeksi moiset härpäkkeet.
 
Windows... mikähän mahtaa olla antivirus softan vaikutus, kannattas varmaan disabloida kokeeksi moiset härpäkkeet.
Niinpä... Varmaan kannattaa rajata Windows pois ajamalla vaikka Linuxin live USB:tä tikulta ja tehdä testit sen kanssa.
 
Jumbo framet molemmissa päissä 9014 kokoiset? Tuolla matkalla piuha tuskin vaikuttaa jotenkin enemmänkin varmaan kiinni jomman kumman pään verkkokortista tms
Kyllä, molemmissa päissä on Jumbo Frame (MTU) 9014. En itsekään tällä matkalla näe etua CAT7 kuin CAT6a johdolla, koska matkat on niin pienet (testaan toisella johdolla kuitenkin)

Windows... mikähän mahtaa olla antivirus softan vaikutus, kannattas varmaan disabloida kokeeksi moiset härpäkkeet.
Niinpä... Varmaan kannattaa rajata Windows pois ajamalla vaikka Linuxin live USB:tä tikulta ja tehdä testit sen kanssa.
Hyvä pointti, tätä ei ole tullut testattua! Pitääpä testata samalla vaikka palomuurin poislaitolla.
Mikäs kytkin sulla on välissä? Onko Full-Duplex asetus päällä?
Ei kytkintä, pöytäkoneen portista palvelimeen porttiin ilman mitään laitetta välissä. Ja Full-Duplex on päällä.
 
Eipä virustorjunnan ja palomuurin disablointi korjannut ongelmaa. Pitää testata vielä vaihtamalla pöytäkoneeseen LiveCD Ubuntu ja sitten vielä jos sekään, niin sama palvelimelle.
 
Asia edistyy, vika on hyvinkin todennäköisesti jossain kohdin Windowsta. Ubutnu LiveCD:n kun heitti Windowsin tilalle ja ajoi peräkkäisiä iperf testejä, oli Bandwidth lopputulos 9.30-9.49 Gbits/sec, eli saturoitunut yhteys.

Sitten se alkaakin Windowsin nettiasetusten sielunelämään tutustuminen (AKA Release the Kraken).
 
Reilusti liian pienet DefaultSendWindow/DefaultReceiveWindow muistaakseni rajoittavat defaultteina 10G-yhteyksiä Winukalla.
 
Suurensin rekisterin kautta noita, mutta no luck.
Eli asennetulla käyttiksellä Ubuntu - W10 tuottaa nyt sen 9.30-9.50 Gbits/sec nopeudet iperf2:lla, ja samoin toiseen suuntaan. Uusi kaapeli ei auttanut. Tuota tuota. Säätöjä on heitelty mutta mitään ei keksi. Ubuntu uusiksi tai LiveCD? Alkaa meinaa ideat loppumaan :D
 
Suurensin rekisterin kautta noita, mutta no luck.

Vaikuttiko ollenkaan? Kokeile muutamalla selvästi erilaisella arvolla ja katso, mitä tapahtuu.

Vastaavia ongelmia näyttää olevan jonkin verran:

Windows 10, 10gbe connection slow transfer, DefaultSendWindow / tcp - Windows 10 Forums

10Gbits slow speed

10gb SFP + network setup - slow windows TCP Transfer

(Jossain noista oli mainittu joku "optimizer"-softa, jollaista ei varmaankaan kannata asentaa.)
 
Vaikuttiko ollenkaan? Kokeile muutamalla selvästi erilaisella arvolla ja katso, mitä tapahtuu.

Vastaavia ongelmia näyttää olevan jonkin verran:

Windows 10, 10gbe connection slow transfer, DefaultSendWindow / tcp - Windows 10 Forums

10Gbits slow speed

10gb SFP + network setup - slow windows TCP Transfer

(Jossain noista oli mainittu joku "optimizer"-softa, jollaista ei varmaankaan kannata asentaa.)
Testattu, ei auta :(

Olen itse hyvin skeptinen näitten softien puolesta, koska jotenkin tuosta ohjelmasta /sivustosta jää sellanen fiilis että tulee adware/bloatware tuossa mukana, tai softa itsessään on sellainen...

Jos jollakulla on kokemuksia tai yms tuosta, jakakaa!
 
Olen itse hyvin skeptinen näitten softien puolesta, koska jotenkin tuosta ohjelmasta /sivustosta jää sellanen fiilis että tulee adware/bloatware tuossa mukana, tai softa itsessään on sellainen...

Jos jollakulla on kokemuksia tai yms tuosta, jakakaa!
Samoin, mutta tuo kyseinen sivu on tosiaan erikoistunut verkkotekniikkaan ja ollut olemassa ties kuinka pitkään. Itse asentaisin jos tarvitsisin. :)
 
Miten kokonaisnopeus käyttäytyy, jos testaat iperfillä useita rinnakkaisia yhteyksia samaan aikaan? Esim. -P 4
 
Miten kokonaisnopeus käyttäytyy, jos testaat iperfillä useita rinnakkaisia yhteyksia samaan aikaan? Esim. -P 4
Tämä tässä onkin mielenkiintoinen, SMB share ei suostu antamaan edes puoliakaan nopeuksia (tai on juuri ja juuri yli puolen), mutta iPerf esim 5-15 rinnakkaisella yhteydellä, 10-600s pituisilla testeilläkin antaa suht vakaata 9.35 - 9.80 Gbits/sec nopeuksia, eli saturoi 10GbE linkin.
 
Tämä tässä onkin mielenkiintoinen, SMB share ei suostu antamaan edes puoliakaan nopeuksia (tai on juuri ja juuri yli puolen), mutta iPerf esim 5-15 rinnakkaisella yhteydellä, 10-600s pituisilla testeilläkin antaa suht vakaata 9.35 - 9.80 Gbits/sec nopeuksia, eli saturoi 10GbE linkin.

Yksi TCP-yhteys ei jaksa saturoida linkkiä. Rinnakkaisilla TCP-yhteyksillä on jokaisella oma vastaanotto- ja ruuhkaikkuna, joten kuittaamatonta dataa voidaan lähettää enemmän TCP window scale option - Wikipedia

Windowsin pitäisi skaalata ikkunan koko yleensä automaattisesti. Iperf3:lle voi antaa koon parametrilla esim. -w 1M. Ennen ainakin iperf2:lla ikkunan koko jäi pieneksi parametrista huolimatta, mutta itse ohjelman lähetys-/vastaanottopuskurin koko kylläkin muuttui. Kaikki viiveet huonontavat siirtonopeuksia. Niiden vuoksi linkin käyttöaste voi jäädä vajaaksi.

Miten käy iperf3:lla, jos kasvatat ikkunan kokoa parametrilla -w, esim. -w 1M, 2M, 4M...?

Jos pingi eli RTT (round trip time) on esim. 2 ms, ehtii 10 Gbps:n yhteys tässä ajassa, ennen kuin ensimmäinen kuittaus vastaanottajalta tulee, lähettämään dataa noin 2,5 Mt. Yhden megan ikkunan koko ei siis riitä. Lähetys tyssää megan kohdalla, kun lähettäjä jää odottamaan vastaanottajalta kuittauksia. Kun vastaanottaja on kuitannut osan saapuneesta datasta, lähettäjä voi lähettää lisää dataa. Kuittaamatonta dataa saa kuitenkin aina olla vain 1 Mt.

Edit:
Itselläni on gigabitin Intelin kortti ja oletuksena esim. IPv4 checksum offload on päällä. Mitä voi säätää on receive ja transmit buffer. En tiedä voiko tuo auttaa, jos nopeudet on kuitenkin monella rinnakkaisella TCP-yhteydellä hyvät.

Advanced Driver Settings for Intel® Ethernet 10 Gigabit Server...

Edit 2:
Kokelin ajaa iperf3:n palvelinta ja clienttia samalla koneella. Sain parhaan nopeudet asetuksella -w 52k.

C:\Ohjelmatiedostot\iperf-3.1.3-win64>iperf3.exe -c 192.168.10.50 -w 52k
Connecting to host 192.168.10.50, port 5201
[ 4] local 192.168.10.50 port 54397 connected to 192.168.10.50 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 2.08 GBytes 17.8 Gbits/sec
[ 4] 1.00-2.00 sec 2.07 GBytes 17.8 Gbits/sec
[ 4] 2.00-3.00 sec 2.09 GBytes 18.0 Gbits/sec
[ 4] 3.00-4.00 sec 2.09 GBytes 17.9 Gbits/sec
[ 4] 4.00-5.00 sec 2.09 GBytes 18.0 Gbits/sec
[ 4] 5.00-6.00 sec 2.10 GBytes 18.1 Gbits/sec
[ 4] 6.00-7.00 sec 2.11 GBytes 18.1 Gbits/sec
[ 4] 7.00-8.00 sec 2.09 GBytes 18.0 Gbits/sec
[ 4] 8.00-9.00 sec 2.11 GBytes 18.1 Gbits/sec
[ 4] 9.00-10.00 sec 2.08 GBytes 17.9 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 20.9 GBytes 18.0 Gbits/sec sender
[ 4] 0.00-10.00 sec 20.9 GBytes 18.0 Gbits/sec receiver

iperf Done.


Asetuksella -w 50k nopeus tippui 15,0 Gbps:ään ja
asetuksella -w 54k arvoon 17,2 Gbps.

Hankala arvata miksi iperf3 käyttäytyy näin. Se, että iper3 on käännetty Windowsille Cygwinillä voi tuota omat mutkansa matkaan. Parempi olisi tehdä testi Linuxilla.


Tämä voisi olla yksi vaihtoehto testaamiseen TechNet NTttcp Utility: Profile and Measure Windows Networking Performance
 
Viimeksi muokattu:
Tämä tässä onkin mielenkiintoinen, SMB share ei suostu antamaan edes puoliakaan nopeuksia (tai on juuri ja juuri yli puolen), mutta iPerf esim 5-15 rinnakkaisella yhteydellä, 10-600s pituisilla testeilläkin antaa suht vakaata 9.35 - 9.80 Gbits/sec nopeuksia, eli saturoi 10GbE linkin.

Puhdasta arvuuttelua, mutta mitähän SMB protokolla versiota palvelinyhteys käyttää, kannattasko tarkistaa, täällä on simppeli ohje PowerShell komennoille jolla asia selviää.
 
Yksi TCP-yhteys ei jaksa saturoida linkkiä. Rinnakkaisilla TCP-yhteyksillä on jokaisella oma vastaanotto- ja ruuhkaikkuna, joten kuittaamatonta dataa voidaan lähettää enemmän TCP window scale option - Wikipedia

Windowsin pitäisi skaalata ikkunan koko yleensä automaattisesti. Iperf3:lle voi antaa koon parametrilla esim. -w 1M. Ennen ainakin iperf2:lla ikkunan koko jäi pieneksi parametrista huolimatta, mutta itse ohjelman lähetys-/vastaanottopuskurin koko kylläkin muuttui. Kaikki viiveet huonontavat siirtonopeuksia. Niiden vuoksi linkin käyttöaste voi jäädä vajaaksi.

Miten käy iperf3:lla, jos kasvatat ikkunan kokoa parametrilla -w, esim. -w 1M, 2M, 4M...?

Jos pingi eli RTT (round trip time) on esim. 2 ms, ehtii 10 Gbps:n yhteys tässä ajassa, ennen kuin ensimmäinen kuittaus vastaanottajalta tulee, lähettämään dataa noin 2,5 Mt. Yhden megan ikkunan koko ei siis riitä. Lähetys tyssää megan kohdalla, kun lähettäjä jää odottamaan vastaanottajalta kuittauksia. Kun vastaanottaja on kuitannut osan saapuneesta datasta, lähettäjä voi lähettää lisää dataa. Kuittaamatonta dataa saa kuitenkin aina olla vain 1 Mt.

Edit:
Itselläni on gigabitin Intelin kortti ja oletuksena esim. IPv4 checksum offload on päällä. Mitä voi säätää on receive ja transmit buffer. En tiedä voiko tuo auttaa, jos nopeudet on kuitenkin monella rinnakkaisella TCP-yhteydellä hyvät.

Advanced Driver Settings for Intel® Ethernet 10 Gigabit Server...

Edit 2:
Kokelin ajaa iperf3:n palvelinta ja clienttia samalla koneella. Sain parhaan nopeudet asetuksella -w 52k.

C:\Ohjelmatiedostot\iperf-3.1.3-win64>iperf3.exe -c 192.168.10.50 -w 52k
Connecting to host 192.168.10.50, port 5201
[ 4] local 192.168.10.50 port 54397 connected to 192.168.10.50 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 2.08 GBytes 17.8 Gbits/sec
[ 4] 1.00-2.00 sec 2.07 GBytes 17.8 Gbits/sec
[ 4] 2.00-3.00 sec 2.09 GBytes 18.0 Gbits/sec
[ 4] 3.00-4.00 sec 2.09 GBytes 17.9 Gbits/sec
[ 4] 4.00-5.00 sec 2.09 GBytes 18.0 Gbits/sec
[ 4] 5.00-6.00 sec 2.10 GBytes 18.1 Gbits/sec
[ 4] 6.00-7.00 sec 2.11 GBytes 18.1 Gbits/sec
[ 4] 7.00-8.00 sec 2.09 GBytes 18.0 Gbits/sec
[ 4] 8.00-9.00 sec 2.11 GBytes 18.1 Gbits/sec
[ 4] 9.00-10.00 sec 2.08 GBytes 17.9 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 20.9 GBytes 18.0 Gbits/sec sender
[ 4] 0.00-10.00 sec 20.9 GBytes 18.0 Gbits/sec receiver

iperf Done.


Asetuksella -w 50k nopeus tippui 15,0 Gbps:ään ja
asetuksella -w 54k arvoon 17,2 Gbps.

Hankala arvata miksi iperf3 käyttäytyy näin. Se, että iper3 on käännetty Windowsille Cygwinillä voi tuota omat mutkansa matkaan. Parempi olisi tehdä testi Linuxilla.


Tämä voisi olla yksi vaihtoehto testaamiseen TechNet NTttcp Utility: Profile and Measure Windows Networking Performance
Tuo NTttcp ei oikein tässä toimi ku on Windows - Linux -yhteys ja tuo on aikalailla vain Windowseille oleva.

iPerf antaa about samaa tulosta 512K, 2M, 8M ja 20M (bandwidth on 9.74 - 10.1 Gbits/sec). Myös yli 3 samanaikaisen yhteydessä ei eroa enää nähdä, eli 3 on tämä ns. maaginen raja. Tämä siis tehty iPerf2.
Puhdasta arvuuttelua, mutta mitähän SMB protokolla versiota palvelinyhteys käyttää, kannattasko tarkistaa, täällä on simppeli ohje PowerShell komennoille jolla asia selviää.
SMB3 on, se on manuaalisesti pakotettu SMB.conf tiedostoon Linuxissa. Aiemmin SMB Multichannel ei toiminut, mutta eilen sen säädettyä, yhteys palvelimeen on moniyhteyksinen (Ajattelin että tämä on maaginen korjaaja, mutta ei).
 

Statistiikka

Viestiketjuista
257 653
Viestejä
4 480 649
Jäsenet
73 964
Uusin jäsen
poppi75

Hinta.fi

Back
Ylös Bottom