Dotaz: SCP, 40MBps over 1G ( SSD to SSD )

[alfonz]

Ahoj, chtel jsem se zeptat, je realny, ze dostavam rychlosti 40MBps pres scp na 1G siti z SSD disku na SSD disk? Dostaval jsem neco podobneho pres WebDav, ale myslel jsem, ze je to omezeni protokolu. Chapu, ze neprotlacim cely 1G, ale alespon 80MBps bych ocekaval, muzu vyzkouset sambu, ale te jsem se predem vyvaroval.. Jinak pouzivam Intel J5005, to neni uplny orezavatko. ( iperf projde na skoro 1G ) Diky

Odpovědi

[PetebLazar]

Scp neni zrovna nenarocne, 40MBps(320Mbps) mi pro dane cpu neprijde jako spatny vysledek. Jake je vytizeni vlaknem scp na obou stranach.

[alfonz]

Na clientovi problem nebude ( i7 9900K ), ale ten server ( J5005 ) je vytizenenjsi, musim vyzkouset sambu/nfs, abych stanovil nejake etalon rychlosti :_)

[k3dAR]

zkus NFS nebo tu Sambu, to by melo oboje saturovat GLAN, ted sem zkusil rychlost s Intel C2550 (coz je servrovej cpu i kdyz trochu starsi/pomalejsi nez J5005)... pres sftp rychlost ~38MB/s, pres sambu ~95MB/s, pres nfs ~112MB/s

[alfonz]

No, WebDav je za https, SCP je sifrovane explicitne, pak asi budu muset zvazit NFS,Sambu nesifrovane, je to jen v lanu..

[Michal Kubeček]

Tak si pusťte top a podívejte se, jestli je procesor (resp. jedno jádro) vytížený naplno (a na které straně). Pokud ano, pak bych tu Sambu klidně zkusil, protože i když není tak efektivní jako třeba HTTP, FTP nebo NFS, bez šifrování a autentizace by neměl být problém z toho vytáhnout víc než těch 40 MB/s.

[Peter Golis]

Predpokladám že ten J5005 prijíma dáta a má podporu AESNI. Ale aký CPU odosiela dané dáta, a na akej šifre sa dohodli?

[alfonz]

Tam problem nebude, desktop, ktery odesila je i7 9900K, budu se asi muset vzdat https/scp a ano J5005 prijima a ma podporu AESNI

[PetebLazar]

Dostupnost AES-NI by měla jít ověřit, zda ji SSH k přenosu využívá je asi otázkou jinou.

Výsledky na Tr 1950X (jednovláknově).

výsledek se zapojením AES-NI

openssl speed -elapsed -evp aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 197725115 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 66949274 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 17310821 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 4374988 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 547711 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 274492 aes-128-cbc's in 3.00s
OpenSSL 1.1.1c  28 May 2019
.....
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc    1054533.95k  1428251.18k  1477190.06k  1493329.24k  1495616.17k  1499092.31k


výsledek bez zapojení AES-NI

openssl speed -elapsed aes-128-cbc
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128 cbc for 3s on 16 size blocks: 31983328 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 64 size blocks: 8416170 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 256 size blocks: 2224772 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 1024 size blocks: 1124657 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 8192 size blocks: 140648 aes-128 cbc's in 3.00s
Doing aes-128 cbc for 3s on 16384 size blocks: 71172 aes-128 cbc's in 3.00s
OpenSSL 1.1.1c  28 May 2019
....
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128 cbc     170577.75k   179544.96k   189847.21k   383882.92k   384062.81k   388694.02k

[kolemjdouci]

Ano je to velmi reálné. SSH je pomalé především díky staticky definované velikosti bufferu. Více zde: https://www.psc.edu/hpn-ssh NFS by mělo být rychlejší.

[Michal Kubeček]

To je docela zajímavá teorie, ale poněkud kulhá při konfrontaci s realitou.

[alfonz]

Tady je dobrej clanek https://blog.ja-ke.tech/2019/08/27/nas-performance-sshfs-nfs-smb.html, ted posledni dobou se mi zda, ze sshfs se dostava do mody..

[alkoholik]

A co mu zkusit vnutit nejakou slabsi sifru?

[PetebLazar]

Pokud bude ssh schopen využít zadrátovaného AES-NI, pak asi nebude moc rychlejších šifer (pokud tedy nepočítáme substituční 1:1 ).

[alfonz]

Hm, zkousel jsem to s winscp 5.15 ( posledni verze ) , aesni ma byt podporovano az v 5.16 https://winscp.net/tracker/1769 :)

[PetebLazar]

Na WinSCP 5.13.4 jsem byl schopen cca saturovat 1Gbps (110MB/s). Mezi i7 6700hq(win10) a TR 1950X (Linux), patrně hrubou silou zúčastněných CPU.

Mezi Linuxy na default sshd_config pomoci scp na 10Gbps se podařilo docilit 160MB/s(1,2Gbps), brzou byl slabsi CPU(100%,65%) z obou Linuxů.

Mezi Linuxy při preferenci AES-128 sifry pomoci scp na 10Gbps se podařilo docilit 480MB/s(4Gbps), brzou byl slabsi CPU(100%,63%) z obou Linuxů.

[alfonz]

Zkousel jsem a 60% sshd,15% scp procesy, rychlost ~66MBps, takze se to s novou verzi winscp zlepsilo, ale stejne je tam prostor pro to, aby to jelo rychleji

[alfonz]

AES-256 SDCTR, dokonce to pise, ze je to AESNI accelerated

[PetebLazar]

Sorry, ta WinSCP hodnota ode byl blud. Nevšiml jsem si, že tam mám v profilu uložen FTP přenos. Hodnoty Winscp při použití scp jsou tristní (řádově MB/s) a dále klesají. Přitom při použití scp z Putty projektu, na kterém snad WinSCP staví to tak hrozné není.

[alfonz]

Jinak samba mi funguje ~112MBps, to je zvlastni, ze si tohodle dosahl pres sftp/scp ? Kdyz mi to nevytezuje ani na 100%, tak tam nemuze byt bottleneck na CPU

[PetebLazar]

Otázkou je, co to je za hodnoty vytížení. Pokud je to celkové vytížení CPU ve Windows, pak je třeba to zohlednit k počtu jader. I 25% vytížení CPU může u quad-core znamenat plně opřené jedno jádro (pro single-thread zátěž prakticky konečná).

[PetebLazar]

Pokud bude scheduler toto vlákno obsluhovat více core, tak se tyto ani v grafu jako vytížené nemusí jevit (ve skutečnosti je CPU vytěžováno maximálně v sumě síly jednoho core).

[OldFrog {Ondra Nemecek}]

Ještě zkontrolujte, zdali nemáte zapnutou kompresi?