Fórum Ubuntu CZ/SK
Ubuntu pro osobní počítače => Hardware => Téma založeno: matlala 19 Září 2013, 01:19:01
-
Zdravím,možná mi nekdo pomůže přijít na způsob jak zrychlit mou síťovku, jelikož an rychlosti mi záleží. Doma mám gigabitovou síť, NAS s inteláckou pořádnou síťovkou.
Problém je v notebooku, vím že s tím moc neudělám, ale naštvalo mě zjištění, že pod ubuntu 12.04.2 x64, jádro 3.5.0-40 je rychlost cca 30-34MB/s a pod windows 8 pro x64 cca 54-56MB/s
Síťovka je Atheros
matlala@matlala-ubuntu:~$ lspci | grep Ethernet
04:00.0 Ethernet controller: Atheros Communications Inc. AR8161 Gigabit Ethernet (rev 10)
Vím, že když jsem NTB pořizoval, tak nebylo v 12.04jádro s ovladačem a musel jsem mít 3.5 jádro, kde už ovladač je. Otázka je, jde nějak třeba nahrát windows driver a zrychlit to tím? Třeba jsme se teď setkal s historickým acerem, kde je brodcom wi-fi karta a tam se stahovaly windows drivery + acpi support pro acery, tak mě napadlo, že nějak to pujde.
Tak co vy na to? Celkem ěmě to štve, na windowsech je to skoro 2x rychlejší a často po síti tahám HD videa.
-
Jseš si jistý tím, že je to opravdu rychlejší, že ten test pod Windows jen nekecá
-
No a jak si to měřil? Stahování přes sambu, cifs či jak? Nebo přes NFS, SSHFS?
-
no samba na NAS/HTPC doma, informace o něm v podpisu. Ten v poho dává 120MB/s, na notesu zase sabma, SSH je pomalejší a jiné nepoužívám.
No 30GB hudby jsme naposled zpátky do linuxu kopíroval asi 15min a pod windows asi jen 8 minut. Přesně jsme to neměřil.
-
Myslím, že jdeš špatnou cestou, když si myslíš, že za to mohou ovladače. Podle mne to dělá ta samba. Máš nějaký firewall? Neblokuješ některý z portů, co používá samba? Spousta lidí má u samby problémy, pokud běží nad TCP/IP, s použitím UDP dosahují vyšších výkonů. Já tomu moc nerozumím, každopádně asi bych viděl chybu někde v té neoptimální konfiguraci samby. Na druhou stranu, jak často takto kopíruješ data? Já myslím, že i tak je to slušná rychlost, pokud se ti neseká video atd, tak je to OK.
-
@beer:
Třeba se pletu, ale měl jsem za to že samba nad udp běhá jen ve velmi vzácných případech?
Co se týče výkonu samby, hodně lidí automaticky konfiguruje sambu tak, že dodává onu kouzelnou formulku
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
která je ale pro kernely 3+ kontraproduktivní a skutečně degraduje výkon samby.
-
Já se v tom opravdu moc nevyznám, já jsem rád, že mi samba funguje :). Ale četl jsem nějaké příspěvky někde na fórech, kde se to řešilo. A když tam porovnávali výkon nad tcp/ip a nad udp, tak to udp vycházelo líp, a to výrazně.
Polovina portů, které používá samba, je tcp/ip a polovina udp.
UDP/137 - used by nmbd
UDP/138 - used by nmbd
TCP/139 - used by smbd
TCP/445 - used by smbd
Nicméně tyto porty nejsou všechny, které samba může používat.
Mne běží samba přes udp, alespoň tedy předpokládám, protože mám sambu na n2n, a n2n mi běží na udp. Tedy u mne nemá vlastně na výběr...
-
V protokolu UDP se odesílající strana o odeslaný paket nestará, a je jí srdečně jedno jestli dorazil do cíle v pořádku, či jestli vůbec dorazil.
V protokolu TCP vysílající strana čeká na potvrzení o převzetí paketu. V případě chyby je paket odesílán znovu.
Z toho plyne:
UDP je rychlejší, ale méně odolné vůči ztrátě či pozměnění dat během přenosu.
TCP je pomalejší, ale odolnější proti ztrátě či pozměnění dat během přenosu.
Síťaři mi prominou můj laický pohled ;).
-
@beer - to, že n2n běží nad udp neznamená, že protokol smb v něm jdoucí není TCP/IP, protože n2n je vrstvy 2.
Ty porty jsou sice obecně udávaný výčet, ale jak jsem psal - ve skutečnosti smb UDP využívá jen ve velice speciálních případech (pokud se nepletu, tak to využívá akorát NetBIOS pro logon a vyhledávání okolních PC přes BCAST).
Zkus se jen tak pro legraci mrknout na iptraf (doufám, že umí dumpovat n2n zařízení), uvidíš, že vlastní datový tok smb jde přes TCP 445.
Docela by mne samotného zajímalo, jak donutit SMB na UDP ...
@Myrmica - je to přesně tak, jak říkáš. Proto se také UDP využívá např. pro VoIP, nebo některé druhy (vlastně většina pomineme-li multicast, jenže i ten využívá logiky "já to posílám a o víc se nestarám") streamingu, protože pokud vypadne třeba 10 paketů z tisíce, člověk to nepozná, zatímco při TCP by se čekalo na odpovědi a latence by logicky vzrostla a výstup by nebyl kontinuální.
-
Ten iptraf doma zkusím. Jen musí mít bratr zapnutý komp. Je 120 km ode mne.
-
Pro začátek doporučuji změřit to pomocí nástroje iperf.
Na tom NASu spusť server:
iperf -c
Na tom počítači spusť klienta:
iperf -c A.B.C.D,
kde A.B.C.D je IP adresa toho NASU.
Ovládání na Windows je podobné, verzi si můžeš zkompilovat ze zdrojáku, ale je dostupná i binárka pro Windows.
Podle toho se můžeš rozhodnout - jestli je problém v neefektivitě samby nebo ovladačů síťovky.
Pro praktický test taháním dat použij iSCSI, nástroje jsou už předinstalované ve většině distribucí (včetně Ubuntu) i ve Windows (od Vist dál určitě, XP nevím).
-
hmm, iperf mi vždy jel kolem 980Mb/s, ale zkusím
-
jj, porovnat i s Windows
-
Tak zatím jsem konečně na NAS/HTPC nastavil pevnou IP adresu abych později mohl pořídit veřejnou IP a přistupovat na něj zvenčí.
Pro jistotu jsem změřil obě síťovky samba + zkouším NFS (konfigurace dle wiki: /home 192.168.1.0/255.0.0.0(rw,no_root_squash,sync )
No a karty jsou teda
matlala@NAS-HTPC:~$ lspci | grep Ethernet
01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
Testy prováděny kopírováním na SSD /home u mě který je ext4 s 9.7GB MKV filmem
Intel dává po sambě pořád cca 30MB/s, přes NFS konstantě 99 +/-cca 1.5MB/s
Realtek po sambě začíná na 40 a končí na cca 35MB u konce, NFS dává 130 a klesá na cca 108MB/s ke konci.
Ještě jsem změřil odezvy obou síťovek, po přepojení vždy následoval restart.
##intel
matlala@matlala-ubuntu:~$ ping -c 5 192.168.1.199
PING 192.168.1.199 (192.168.1.199) 56(84) bytes of data.
64 bytes from 192.168.1.199: icmp_req=1 ttl=64 time=0.337 ms
64 bytes from 192.168.1.199: icmp_req=2 ttl=64 time=0.355 ms
64 bytes from 192.168.1.199: icmp_req=3 ttl=64 time=0.312 ms
64 bytes from 192.168.1.199: icmp_req=4 ttl=64 time=0.377 ms
64 bytes from 192.168.1.199: icmp_req=5 ttl=64 time=0.346 ms
--- 192.168.1.199 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3997ms
rtt min/avg/max/mdev = 0.312/0.345/0.377/0.027 ms
##realtek
matlala@matlala-ubuntu:~$ ping -c 5 192.168.1.199
PING 192.168.1.199 (192.168.1.199) 56(84) bytes of data.
64 bytes from 192.168.1.199: icmp_req=1 ttl=64 time=0.216 ms
64 bytes from 192.168.1.199: icmp_req=2 ttl=64 time=0.221 ms
64 bytes from 192.168.1.199: icmp_req=3 ttl=64 time=0.192 ms
64 bytes from 192.168.1.199: icmp_req=4 ttl=64 time=0.137 ms
64 bytes from 192.168.1.199: icmp_req=5 ttl=64 time=0.170 ms
##pozn druhý test byl srovnatelný, nejspíše mělo CPU co dělat a brzdilo síťovku na desce
Z toho usuzuju, že teda v síťovce problém není, samba je strašně pomalá mezi linuxem a linuxem a intelka dává stabilní přenosy a není ovlivněna zatížením CPU jako integrovaná (což potvrzují i recenze na tuhle intelku).
No a mimochodem ode mě na windows co si ted přetahoval spolužák ve škole po přímém kabelu, tak šla samba tak 100 a končila na 65MB/s po cca 20GB dat. Takže je mě to divné a čas přenosu souhlasil také, schválně jsem se koukal na hodiny.
Takže nějaké nápady jak to poté zefektivnit? Doma určitě nepotřebuju nějaké zabezpečení a zvenku pak budu používat SSH, stejně mě poskytovatel nepustí víc jak 1Mb/s ven a ještě to može omezit někde na cestě (eventuelně by se s ním dalo domluvit na extra tarifu co standardně neposkytuje v balíčku,a le asi to nebude potřeba, nehodlám poskytovat data nikomu jinému než sobě a občas kamarádům, které nevidím často osobně a tudíž to nemůžou dostat kabelem na přímo mezi notesy nebo na jiném médiu).