Výkon iSCSI přes ethernet, optimalizace

V návaznosti na thread o bootování Win7 ze sítě jsem narazil na zajímavou problematiku - ladění výkonu iSCSI.
Zatím laďme lokálně a do sítě se přesuňme, až bude vyladěno přes loopback.

Níže naměřené výsledky jsou dost zoufalé. Použitý software je IET jako target, open-iscsi jako initiator.
Platforma:
Linux tix 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64 GNU/Linux
HW:
Atom D510, 4GB DDR2, 3x Samsung F2 v mdraid jako RAID5.

Tady rychlý test volumu připojeného přes iSCSI lokálně (target je stejný stroj jako initiator, ale není připojený přes loopback)

Kód:

---

tix:/home/marty# hdparm -tT /dev/sdd1

/dev/sdd1:
 Timing cached reads:  1666 MB in  2.00 seconds = 832.52 MB/sec
 Timing buffered disk reads: 136 MB in  3.04 seconds =  44.76 MB/sec
tix:/home/marty# hdparm -tT /dev/sdd1


/dev/sdd1:
 Timing cached reads:  1624 MB in  2.00 seconds = 812.29 MB/sec
 Timing buffered disk reads: 170 MB in  3.02 seconds =  56.26 MB/sec
tix:/home/marty# hdparm -tT /dev/sdd1


/dev/sdd1:
 Timing cached reads:  1662 MB in  2.00 seconds = 830.86 MB/sec
 Timing buffered disk reads: 176 MB in  3.01 seconds =  58.53 MB/sec
tix:/home/marty# hdparm -tT /dev/sdd1


/dev/sdd1:
 Timing cached reads:  1660 MB in  2.00 seconds = 830.37 MB/sec
 Timing buffered disk reads: 182 MB in  3.01 seconds =  60.39 MB/sec
tix:/home/marty# hdparm -tT /dev/sdd1


/dev/sdd1:
 Timing cached reads:  1654 MB in  2.00 seconds = 827.29 MB/sec
 Timing buffered disk reads: 182 MB in  3.03 seconds =  59.98 MB/sec

---

Připojený přes loopback:

Kód:

---

tix:/home/marty# hdparm -tT /dev/sdd

/dev/sdd:
 Timing cached reads:  1572 MB in  2.00 seconds = 785.67 MB/sec
 Timing buffered disk reads: 202 MB in  3.02 seconds =  66.80 MB/sec
tix:/home/marty# hdparm -tT /dev/sdd


/dev/sdd:
 Timing cached reads:  1600 MB in  2.00 seconds = 800.18 MB/sec
 Timing buffered disk reads: 212 MB in  3.03 seconds =  70.00 MB/sec
tix:/home/marty# hdparm -tT /dev/sdd


/dev/sdd:
 Timing cached reads:  1576 MB in  2.00 seconds = 787.73 MB/sec
 Timing buffered disk reads: 212 MB in  3.01 seconds =  70.32 MB/sec
tix:/home/marty# hdparm -tT /dev/sdd


/dev/sdd:
 Timing cached reads:  1542 MB in  2.00 seconds = 770.41 MB/sec
 Timing buffered disk reads: 218 MB in  3.03 seconds =  71.89 MB/sec
tix:/home/marty# hdparm -tT /dev/sdd


/dev/sdd:
 Timing cached reads:  1594 MB in  2.00 seconds = 797.01 MB/sec
 Timing buffered disk reads: 214 MB in  3.02 seconds =  70.95 MB/sec

---

A napřímo test pole, na kterém to běží:

Kód:

---

tix:/home/marty# hdparm -tT /dev/md2

/dev/md2:
 Timing cached reads:  1540 MB in  2.00 seconds = 769.85 MB/sec
 Timing buffered disk reads: 434 MB in  3.05 seconds = 142.53 MB/sec
tix:/home/marty# hdparm -tT /dev/md2


/dev/md2:
 Timing cached reads:  1554 MB in  2.00 seconds = 776.51 MB/sec
 Timing buffered disk reads: 318 MB in  3.00 seconds = 105.87 MB/sec
tix:/home/marty# hdparm -tT /dev/md2


/dev/md2:
 Timing cached reads:  1608 MB in  2.00 seconds = 803.60 MB/sec
 Timing buffered disk reads: 352 MB in  3.00 seconds = 117.27 MB/sec
tix:/home/marty# hdparm -tT /dev/md2


/dev/md2:
 Timing cached reads:  1690 MB in  2.00 seconds = 844.82 MB/sec
 Timing buffered disk reads: 418 MB in  3.01 seconds = 138.94 MB/sec

---

A teď k věci:

1. jaká je v praxi režie iSCSI, má smysl ho používat pro lokálně běžící virtuální stroje místo přímého přístupu k RAW souboru?
2. jak poladit IET, aby se při lokálním připojení rychlosti dostaly alespoň nad 2/3 praktické propustnosti přímého přístupu na disk?
3. jak připravit celou konfiguraci pro dosažení podobného výkonu po síti?

Jsem nakloněn případné koupi nového routeru / switche, do kterého je připojen NAS. V síti mám zatím 2ks RB250GS, což jsou gigové managovatelné mikrotikové switche. V současné době mi na tomto HW (NAS) běží virtuální stroj s Windows, který tomu dává slušný kouř (vytížení procesoru je průměrně na 10%), tu mašinu bych mohl případně posunout jinam...

Nezdá se mi varianta, že by řešením byl pouze upgrade procesoru. Pořízení síťovky s TCP offloadingem asi taky není schůdná cesta (znamenalo by to přeházet celý HW, nejsou sloty).

Covece ja ted koukal na http://www.diit.cz/clanek/nas-server...ty/39108/37390 a taky me to iSCSI prekvapilo. Ja ted na novem stroji davam pres NFS maximum gigabitu 115MB/s pri zatizeni do 10% CPU (vc. I/O wait), takze dobrou sitovku nelze nez jen doporucit.

Co ti ukazuje top pri zatezi? Staci nejaky dd nebo cat do /dev/null z toho iscsi zarizeni. Treba je to jen vec bloku, uzke hrdlo muze byt kdekoliv. Na ostestovani site zkus iperf.

1) Co znamená připojeno lokálně? Pomocí adres, co máš na skutečné síťovce?
2) Target je nějaký soubor vytvořený na poli? Nebo nejaky lvm oddíl? Jak je pole zaplněné?

Rozdíl, který vidím mezi použitím loopback interfacu a skutečné síťovky je 70 vs 60MBps, což není tak špatné.

Tipuju, že target je soubor na poli a pole je natolik fragmentované, že více skutečně nezvládne, to co měří hdparm je přímý přístup k diskům nezávisle na filesystemu a fragmentaci.
Vyzkoušej jak rychle ten soubor skutečně přečteš:

Kód:

---

dd if=target_soubor of=/dev/null

---

hdparm mi přímo na poli ukazuje taky kolem 190MBps, ale když se pokusím přečíst novější soubory pomocí dd, tak se dostanu třeba jen na 40MBps.

Díky za podněty!

1. síťovka - mám problém se sloty. Atom má jen MiniPCI Express a PCI. V PCI mám SATA řadič. Šlo by SATA přesunout do MiniPCI Express a do PCI hodit síťovku, ale tím si nepomůžu. MiniPCI Express síťovka bude trošku oříšek, ale sehnat se dá. Má to smysl? Viděl bych to ale jako až poslední možnost.

2. vytížení /dev/zero >> iscsi, mazec, viz příloha, já jsem na to koukal přes htop a asi mi něco uniklo. Vypadá to, že má fakt procák problém???

3. připojeno lokálně - ano, pomocí adres na síťovce

4. target je soubor vytvořený na poli, pole je z 95% plné (zbývá asi 150GB). Problém s fragmentací nevidím:

Kód:

---

marty@tix:/mnt/data/volumes$ dd if=16G_blank.raw of=/dev/null33554432+0 records in
33554432+0 records out
17179869184 bytes (17 GB) copied, 162.655 s, 106 MB/s
marty@tix:/mnt/data/volumes$ dd if=iscsi_hdd_01.img.backup of=/dev/null
33554432+0 records in
33554432+0 records out
17179869184 bytes (17 GB) copied, 147.647 s, 116 MB/s

---

Příloha 9289

Ještě jednou testík přístupu na iSCSI volume připojeného přes 127.0.0.1

Kód:

---

tix:/mnt/sdd# dd if=/dev/zero of=/mnt/sdd/testfile bs=1M count=40964096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 141.706 s, 30.3 MB/s
tix:/mnt/sdd# dd if=testfile of=/dev/null
8388608+0 records in
8388608+0 records out
4294967296 bytes (4.3 GB) copied, 82.2473 s, 52.2 MB/s

---

a vytížení při čtení (předchozí post je zápis)
Příloha 9290


Mno, tak to vypadá, že hlavní příčinou všelijaké rychlosti bude
1. kolísání rychlosti na RAIDu
2. vytížení procesoru mimo jiné VirtualBoxem

Napadá vás ještě něco dalšího?

ja mel nejlepsi zkusenosti, co se tyce vykonu iscsi, se scst ... takze jestli se ti chce spekulovat, tak vyhod ietd a nahod scst ... rekord mam asi 1.5GB/s ...

Citace:

---

Původně odeslal Fox!MURDER

ja mel nejlepsi zkusenosti, co se tyce vykonu iscsi, se scst ... takze jestli se ti chce spekulovat, tak vyhod ietd a nahod scst ... rekord mam asi 1.5GB/s ...

---

OMG, na jakem hardwaru?

Dual Xeon E5620, Areca 1880, 12x Seagate Cheetah 15k.7 600G, Mellanox ConnectX, IPoIB.

Muhahaha. :eek: Když jsem říkal, že je pro mě investice do MiniPCI Express síťovky moc, tak jsem tím myslel i nějaký infinibandový zvěrstva ;D
Ale slušnej oddíl, to teda jo :drool:

Na SCST už jsem dneska koukal, rozhodně tomu dám šanci. Ale teď se bez gigabitový kabeláže nehnu :(

mno, myslim, ze v cene tohohle bys mel tech sitovek asi tak kamion :D
psal jsem to tu spis proto, ze jsem testil vsechny ctyri iscsi targety a prave se scst jsem dosahoval nejlepsich vysledku.
ale to samozrejme nemusi platit pro tvuj setup ...

Jasan, taky už jsi dostal K+ ;) rozhodně SCST testnu, ale nejdřív musím odklonit ten load tou virtuální mašinou jinam a natáhnout gigabit...

Tak pro srovnani jsem udelal test s pomoci tohoto SW http://www.starwindsoftware.com/starwind (Win2k8R2 nemam kam na test nainstalovat, pro pouziti M$ iSCSI targetu).

Puvodne jsem to chtel otestovat s pomoci Tune HD, ale to mereni je nejake divne, neprekroci 50MB/s.
Takze jen beznym kopirovanim, rychlost je cca 80MB/s, vytizeni atom dvoujadra pri tom 15% (i podle Resource Monitoru to na ten disk skutecne takhle rychle zapisuje, na serveru tedy).
Soft umoznuje vytvorit i RAM disk target, ale zadny narust rychlosti tam uz nebyl, spise naopak (asi malo fyzicke RAMky na tyhle testy).

Neco mi rika, ze SW RAID5 nebude levna zalezitost co do vyuziti CPU...

Citace:

---

Původně odeslal Gargamel

Neco mi rika, ze SW RAID5 nebude levna zalezitost co do vyuziti CPU...

---

I při čtení? Při zápisu souhlas...

Zase tak hrozné to není, při startu se testují různé algoritmy a do 8GB/s mám ještě pěknou rezervu.

Kód:

---

[    1.208020] raid6: sse2x4    6435 MB/s
[    1.208027] raid6: using algorithm sse2x4 (6435 MB/s)
[    1.208662] xor: automatically using best checksumming function: generic_sse
[    1.228014]    generic_sse:  8053.000 MB/sec
[    1.228020] xor: using function: generic_sse (8053.000 MB/sec)

---

hw viz podpis: Intel(R) Pentium(R) Dual CPU E2200 @ 2.20GHz

Aha, dobrý tip, tak na tom Atom není taky tak zle.

Kód:

---

[    2.832149] raid6: int64x1    323 MB/s[    2.900076] raid6: int64x2    507 MB/s
[    2.968034] raid6: int64x4    595 MB/s
[    3.036042] raid6: int64x8    713 MB/s
[    3.104057] raid6: sse2x1    619 MB/s
[    3.172041] raid6: sse2x2    1128 MB/s
[    3.240027] raid6: sse2x4    1981 MB/s
[    3.240032] raid6: using algorithm sse2x4 (1981 MB/s)

---

Jinak včera jsem si s tím hrál už na gigabitu (přes FTP, SMB i iSCSI) a mám tam nějakej větší problém, asi špatnej kabel či co, každopádně si to dělalo úplně co chce... občas kolísalo kolem 10MB/s a pak nějak padlo na rychlosti kolem 4MB/s... laboroval jsem ale i s MTU, takže bůh ví, co jsem domrvil :)

Takže další krok bude pořízení slušné kabeláže. Zajímavé ale bylo, že switche nehlásí žádné errory na linku a spojí se na 1000/FDX.

Citace:

---

Původně odeslal Marty

Aha, dobrý tip, tak na tom Atom není taky tak zle.

Kód:

---

[    2.832149] raid6: int64x1    323 MB/s[    2.900076] raid6: int64x2    507 MB/s
[    2.968034] raid6: int64x4    595 MB/s
[    3.036042] raid6: int64x8    713 MB/s
[    3.104057] raid6: sse2x1    619 MB/s
[    3.172041] raid6: sse2x2    1128 MB/s
[    3.240027] raid6: sse2x4    1981 MB/s
[    3.240032] raid6: using algorithm sse2x4 (1981 MB/s)

---

Jinak včera jsem si s tím hrál už na gigabitu (přes FTP, SMB i iSCSI) a mám tam nějakej větší problém, asi špatnej kabel či co, každopádně si to dělalo úplně co chce... občas kolísalo kolem 10MB/s a pak nějak padlo na rychlosti kolem 4MB/s... laboroval jsem ale i s MTU, takže bůh ví, co jsem domrvil :)

Takže další krok bude pořízení slušné kabeláže. Zajímavé ale bylo, že switche nehlásí žádné errory na linku a spojí se na 1000/FDX.

---

OS taky nehlasi zadne errory na te lince?

Jinak zlate pravidlo MTU je, ze musi byt uplne stejne na vsech strojich v segmentu.

Nemuzu rict, ze bych tomu zrovna rozumnel, ale vsechna mereni vykonu XORu (pro RAID) anebo rychlosti sifrovacich algoritmu (pro TrueCrypt etc.) mi pripadaji velmi malo vypovidajici. Zasadni rozdil je imho v tom, ze neni prakticky mozne pouzit DMA. V normalim modu mate nejaky blok pameti, ktery potrebujete dostat na disk, procesor zinicializuje prenos a zbytek se dodela sam, neni nutne protocit vsechna data pres procesor.

V momente, kdy nad temi daty potrebujete spocitat XOR nebo v horsim pripade je zasifrovat nutne musite vsechno pres procesor propasirovat a rozhodne to nemuze fungovat tak, ze CPU spocita XOR pro vsechna data najednou tou rychlosti, kterou si muzete zmerit, pak je hotovo a jede se jako normalne. IO operace jsou vyrazne pomalejsi, bude tam hodne, hodne context-switchu a ve vysledku bude procesor castecne zaneprazdneny danou IO operaci po celou jeji dobu. Vyvedte me nekdo prosim z omylu, ale presne takhle si ja vysvetluju, ze laptop se sifrovanym diskem je citelne pomalejsi nez ten s nesifrovanym diskem, at jsou testy vykonu ohromujici jak chteji.

Mluvim samozrejme softraidu a softsifrovani...

Citace:

---

Původně odeslal frelichl

...

---

takhle by to bylo, pokud by nad tim nikdo vubec nepremejslel a udelal to nejjednodussim zpusobem ...

jinak ale staci obetovat trochu pameti na buffery a neni problem ...

viz. zapis na

Kód:

---

Cipher name:    aes
Cipher mode:    xts-essiv:sha256
Hash spec:      sha512

---

Kód:

---

Device:        rrqm/s  wrqm/s    r/s    w/s    rMB/s    wMB/s avgrq-sz avgqu-sz  await r_await w_await  svctm  %util
sdc              0.00    0.00    0.00  475.00    0.00  211.21  910.64    0.26    0.55    0.00    0.55  0.47  22.50
dm-0              0.00    0.00    0.00  475.00    0.00  211.21  910.64    0.22    0.46    0.00    0.46  0.39  18.70
sdc              0.00    0.00    0.00  557.00    0.00  247.74  910.91    0.30    0.54    0.00    0.54  0.45  25.10
dm-0              0.00    0.00    0.00  557.00    0.00  247.74  910.91    0.26    0.46    0.00    0.46  0.39  21.60
sdc              0.00    0.00    0.00  495.00    0.00  220.21  911.11    0.28    0.56    0.00    0.56  0.47  23.30
dm-0              0.00    0.00    0.00  495.00    0.00  220.21  911.11    0.23    0.47    0.00    0.47  0.40  19.80

---

Kód:

---

----total-cpu-usage---- ---system-- ---io/sdc-----io/dm-0-- --dsk/sdc-----dsk/dm-0-
usr sys idl wai hiq siq| int  csw | read  writ: read  writ| read  writ: read  writ
  0  83  0  15  0  3|4592  3045 |  0  507 :  0  507 |  0  225M:  0  225M
  0  96  0  2  0  2|4728  1249 |  0  619 :  0  620 |  0  275M:  0  275M
  0  78  0  21  0  1|5363  881 |  0  486 :  0  488 |  0  217M:  0  217M
  0  78  0  21  0  1|5379  1033 |  0  479 :  0  477 |  0  212M:  0  213M

---

context switchu tam moc neni a preruseni taky ne (vzhledem k tomu, ze 4000 je klidovej stav pri 4 CPU a HZ=1000 kernelu)
HW: 1x Xeon E5504, Areca 1680, 5x2TB WD2002FYPS RAID6, 6GB RAM

(samozrejme se jedna o velmi jednoduchej test-case - sekvencni zapis na fs)
(ty vypisy jsou chycene v rozdilnych casech - jsou spis informativni, nez aby mely velkou vypovidaci hodnotu)
(zkusim jeste najit nezatizenej sw raid5/6 ...)

A nemuzu ted narychlo najit benchmark kernelove implementace AES256-XTS, ale pro obrazek rychlost OpenSSL implementace AES-256-CBC pri vyuziti vsech 4 jader (kernel ma AES implementovany v assembleru a tim padem o neco rychlejsi).

Kód:

---

The 'numbers' are in 1000s of bytes per second processed.
type            16 bytes    64 bytes    256 bytes  1024 bytes  8192 bytes
aes-256 cbc    171594.18k  179896.87k  182058.07k  182586.71k  182591.49k

---

btw. marty - nahod komplet konfigurak ietd ...

Ja tedy notebook s sifrovanym diskem pouzivam a ze by byl nejak extra pomalejsi to mi neprijde ;-)

Fox: jasne, nerikam, ze je to udelane tak hloupe, ale princip je jasnej: vsechno musi projet pres registry procesoru, ze to jde udelat blokove je samozrejme podstatna optimalizace, ale jde to vzdycky delat po rozumnych blocich?

HollyG: nerikam, ze je to v prumernem pripade extra pomalejsi, ale jsou situace, kdy notebook se sifrovanym diskem bezpecne poznam. Ale taky samozrejme zalezi na konkretni implementaci, specialne ta, co mam na pracovnim notebooku mi pekne pije krev.

Citace:

---

Původně odeslal frelichl

Fox: jasne, nerikam, ze je to udelane tak hloupe, ale princip je jasnej: vsechno musi projet pres registry procesoru, ze to jde udelat blokove je samozrejme podstatna optimalizace, ale jde to vzdycky delat po rozumnych blocich?

HollyG: nerikam, ze je to v prumernem pripade extra pomalejsi, ale jsou situace, kdy notebook se sifrovanym diskem bezpecne poznam. Ale taky samozrejme zalezi na konkretni implementaci, specialne ta, co mam na pracovnim notebooku mi pekne pije krev.

---

ono ani tak neni problem v rozdeleni do bloku ... koneckoncu to v blocich musi byt vzdy.
problem je v tom, ze kdyz to nemas v blocich, musis precist co uz na disku je, zmenit to, co zmenit chces a zase to zapsat (a to plati jak pro raid - problem pri velkem stripe, tak pro sifrovani - tam bloky nastesti nejsou tak velke)
a nakonec, marty ma problem i se ctenim a to v raid5 skrz cpu projit nemusi ...

Citace:

---

Původně odeslal Fox!MURDER

OS taky nehlasi zadne errory na te lince?

---

Ověřím.

Citace:

---

Původně odeslal Fox!MURDER

Jinak zlate pravidlo MTU je, ze musi byt uplne stejne na vsech strojich v segmentu.

---

Co na to switche? Když nastavím nějakou velkou velikost, a switch to nebude umět, co se stane?
Hledal jsem hledal a můj hlavní switch (v routeru Edimax BR6574n) to snad i umět má (ač jsem tu kdysi tvrdil něco jiného).
Trochu mi v tomto tématu chybí teoretický základ, takže budu muset trochu nastudovat, vo co jde.
(jak je to s hlavičkou, kolik má bajtů? 14 nebo kolik?)

Citace:

---

Původně odeslal Fox!MURDER

btw. marty - nahod komplet konfigurak ietd ...

---

Kód:

---

marty@tix:~$ sudo cat /etc/iet/ietd.conf | grep -v \#

Target iqn.2003-08.net.myslenka.grisu:vFile1
        Lun 0 Path=/mnt/data/volumes/iscsi_hdd_01.img.backup,Type=fileio,IOMode=ro

Target iqn.2003-08.net.myslenka.grisu:CDs
        Lun 0 Path=/mnt/data/volumes/ubuntu-11.04-desktop-amd64.iso,Type=fileio,IOMode=ro
        Lun 1 Path=/mnt/data/volumes/win7x64.iso,Type=fileio,IOMode=ro

Target iqn.2003-08.net.myslenka.grisu:InstXP
        Lun 0 Path=/mnt/data/volumes/iscsi_hdd_02.img,Type=fileio,IOMode=wt

Target iqn.2003-08.net.myslenka.grisu:vFile3
        Lun 0 Path=/mnt/data/volumes/iscsi_hdd_03.img,Type=fileio,IOMode=wt

---

;D ;D ;D

Jen tak bych zkusil u nejakyho targetu nastavit

Kód:

---

InitialR2T no
ImmediateData yes
MaxRecvDataSegmentLength 262144
MaxXmitDataSegmentLength 262144

---

popripade

Kód:

---

IOMode=wb

---

pokud budes resit zapis ...

co se MTU tyce, tak to je dylka segmentu, takze hlavicky neres (pokud nepouzivas VLANy) ...
pokud mas na strojich vetsi mtu, nez umi switch, tak nejspis proste neprojdou, resp. dojdou poskozeny. (tipuju, hadam zavisi kus od kusu)
pokud mas na ruznych strojich ruzne mtu v jednom segmentu site, tak je dost mozne, ze ti napr. filetransfery budou fungovat jen jednosmerne, pricemz ping se bude zdat ok.
btw. jsi si jisty, ze to ten edimax umi? ted jsem narychlo nenasel nic, co by tomu nasvedcovalo, resp. urcite ne s orig firmware ... nejspis i proto, ze vetsinou se wifi k ethernetu bridguje a to by s velkym mtu asi fungovalo spatne ...

Dík moc.
S tím nastavením MTU mě mátlo, že ve Win ovladači Atherosí síťovky v desktopu byl defaultní údaj 1486, zatímco na NASu v linuxu to je 1500 (tj. odhaduji, že na Win to ovladač bere bez hlavičky).

V současné době mám v segmentu víc zařízení - bude problém, když budu testovat různá nastavení (MTU) jen na dvou z nich? Z toho, co jsi psal, mi přijde, že to musí být nastaveno i na ostatních zařízeních, i když s nimi nekomunikuji...

Jinak asi to udělám tak, že NAS na čas vezmu a přemístím ho desktopu, abych eliminoval i problém délky a/nebo kvality kabelu...

S tím edimaxem si jistý vůbec nejsem, a jak jsem zmínil, jsem nakloněn výměně... jen vybrat něco vhodného, viz jiná diskuze :) Zatím jsem se k tomu neodhodlal/nedokopal. (čím dál víc mě tam visí myšlenka pouze drátového routeru a malého samostatného APčka.

Citace:

---

Původně odeslal Marty

Dík moc.
S tím nastavením MTU mě mátlo, že ve Win ovladači Atherosí síťovky v desktopu byl defaultní údaj 1486, zatímco na NASu v linuxu to je 1500 (tj. odhaduji, že na Win to ovladač bere bez hlavičky).

V současné době mám v segmentu víc zařízení - bude problém, když budu testovat různá nastavení (MTU) jen na dvou z nich? Z toho, co jsi psal, mi přijde, že to musí být nastaveno i na ostatních zařízeních, i když s nimi nekomunikuji...

Jinak asi to udělám tak, že NAS na čas vezmu a přemístím ho desktopu, abych eliminoval i problém délky a/nebo kvality kabelu...

S tím edimaxem si jistý vůbec nejsem, a jak jsem zmínil, jsem nakloněn výměně... jen vybrat něco vhodného, viz jiná diskuze :) Zatím jsem se k tomu neodhodlal/nedokopal. (čím dál víc mě tam visí myšlenka pouze drátového routeru a malého samostatného APčka.

---

Pokud si to spravne pamatuju, tak je IP hlavicka 16B ... a ethernetovej frame pobere tech 1500B ... takze nevim, co je 1486 ...

Mno, jinak receno, kazde dve zarizeni, ktere spolu maji komunikovat musi mit stejne MTU. Tj. pokud ti ty dve zarizeni komunikuji jen mezi sebou a s nicim jinym, tak to vadit nebude. (pokud mas NAS a Desktop 9000, server 15000 a router 1500, tak spolu budou bezproblemove komunikovat jen NAS a Desktop)

Jasan, to jsem si myslel.
Jinak hlavička má od 20 do 24 bytů... chjo :)

Takže aktuální stav k ladění... přesunul jsem všechen HW na jeden switch a hraju si s tím, nicméně ani přes NFS/FTP/SMB se nedostanu přes nějakých 35-40 MB/s. Na discích v NASu je přitom slyšet, že hrábnou jednou za 5 vteřin, ne-li méně často.

Takže budu se teď chvíli zabývat identifikací úzkého hrdla a pak se vrátím k iSCSI...

Covece ja jsem ted po nejake dobe koukl na svuj stary server (single-core Celeron na architekture Core2 @ 1.6GHz) a zjistil, ze nfsd jakozto prostredek jadra vytezuje temer na 100%. Jednalo se ale o prenos relativne malych souboru v nekolika vlaknech soucasne, nicmene vysledny prutok byl kolem 30MB/s. S jednim vlaknem a velkym souborem to da tech 100MB/s. Taky nevim, co z toho byla rezie filesystemu, to jsem nezkoumal. Hadam, ze ta partition byla slusne fragmentovana.

Jestli meris uzke hrdlo, tak zkus kopirovat pres sit /dev/zero.

Vracím se k tomuto zábavnému tématu, hezky po pár letech.
Na cestě máme s Foxem 10GBe karty, které zmiňoval na předchozí stránce :D :D :D a já jsem na svém serveru znovu začal připravovat a ladit iSCSI. Opět IET a opět tragédie.
SMB mi krásně vytíží gigabit naplno a je stabilní, iSCSI proti Win Initiatoru je absolutní tragédie. Viz přiložený náhled grafu z DUMeteru... jde o přenos stejného 9GB souboru, nejprve přes iSCSI (target LUN je přímo partition na disku nasdílená jako iSCSI LUN), následně přes obyčejnou sambu. Zábavné, že?

Příloha 10501

Citace:

---

Původně odeslal Marty

Vracím se k tomuto zábavnému tématu, hezky po pár letech.
Na cestě máme s Foxem 10GBe karty, které zmiňoval na předchozí stránce :D :D :D a já jsem na svém serveru znovu začal připravovat a ladit iSCSI. Opět IET a opět tragédie.
SMB mi krásně vytíží gigabit naplno a je stabilní, iSCSI proti Win Initiatoru je absolutní tragédie. Viz přiložený náhled grafu z DUMeteru... jde o přenos stejného 9GB souboru, nejprve přes iSCSI (target LUN je přímo partition na disku nasdílená jako iSCSI LUN), následně přes obyčejnou sambu. Zábavné, že?

Příloha 10501

---

Nemas na tom iSCSI svazku nahodou vyple cache?

Jinak IET uz si moc nepamatuju, ale se SCST jsem kdysi udelal 1.5GB/s (velke B je spravne). Ale bylo to s Linuxovym initiatorem. Az sitovky dorazi, taky se na to podivam ...

Hmm, ja doma jedu na LIO jako target (http://linux-iscsi.org/wiki/Main_Page), coz je kernel space vec konfigurovana pres configfs a openiscsi jako initiator a funguje to pekne. K tomu CRC32 na data i protokol. Mam jen gigove sitovky, ale ten gigabit to da bez problemu (backing store jsou mdraid level 1 5700rpm SATA HDD).

Jediny problem, na ktery jsem s LIO narazil, byly failnute alokace pri zapisu kvuli prilis agresivne nastavenemu (tj. vypnutemu) overcommit VM modu a fragmentovane fyzicke RAM. Stalo se to ale jednou za posledni cca dva roky. Bohuzel initiator problemy zpet nereportoval, jelikoz se k nemu ani nedostaly. Mozna bych mel vypnout cacheovani na strane targetu.