| View previous topic :: View next topic |
| Author |
Message |
sacchi
Tux's lil' helper
Joined: 28 May 2004
Posts: 104
|
 Posted: Thu Jan 22, 2015 4:24 pm Post subject: [RISOLTO] iperf e valori molto bassi... |
 |
|
Ciao a tutti,
ho un serverino gentoo con una gigabit ethernet e una wifi in modalità master.
Tutto funziona benino a parte le prestazioni di samba che sono davvero terribili.
Sulla gigabit copio files a 6MB/s, sulla wifi (connessa a 54mbit) a 400KB/s.
Tra due PC windows su cavo copio file sui 110MB/s, quindi immagino che la lan sia OK.
La ethernet è una Intel 82573L (e1000e), la wifi una ISL3890.
Ho provato ogni tuning di samba, ho provato ad abilitare i jumbo frames, non cambia nulla.
Ho poi pensato di fare un giro di iperf... e tra il serverino gentoo e una macchina windows ottengo 150 Mbit su cavo e 10MBit su wifi. Tra due pc windows ottengo valori prossimi a 1Gbit.
uname riporta:
Linux 3.17.2 #1 SMP x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux
I valori di iperf che ottengo sono normali?
Posso lanciare altri tools diagnostici che possano aiutare a trovare il problema?
Molte grazie a tutti!
L
Last edited by sacchi on Thu Feb 26, 2015 11:46 pm; edited 1 time in total |
|
| Back to top |
|
 |
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Thu Jan 22, 2015 10:17 pm Post subject: |
|
|
Non sono dell'umore di applicarmi ma ad uno sguardo superficiale i valori che riporti sono normalissimi e perfettamente in linea con quel che hai. 
Per la wlan ti consiglio di impostare DEFAULT_WESTWOOD=Y forse il problema è quello anche se avevo letto che il minstrel ultimamente dava problemi.
Per la lan... 150 è il valore più che ottimale ... per una 100 non per una 1000... quindi...
Mi sa che per qualche oscuro (ma non troppo) motivo la tua scheda non riconosce la lan come gigabit ma come ethernet 100 o non la impiega in full duplex.
Controlla i cavi, controlla l'hub, rivedi la conf del kernel, vedi se non ti serve del firmware per la scheda di rete per farla funzionare correttamente, controlla dmesg e vedi se viene correttamente riconosciuta.
Controlla anche le prestazioni in I/O dal disco e le impostazioni per il multitasking, già che ci sei. Mi pare più un problema kernel/driver che di rete.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est 
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
sacchi
Tux's lil' helper
Joined: 28 May 2004
Posts: 104
|
| Posted: Tue Jan 27, 2015 12:09 pm Post subject: |
|
|
| djinnZ wrote: | | Non sono dell'umore di applicarmi ma ad uno sguardo superficiale i valori che riporti sono normalissimi e perfettamente in linea con quel che hai. |
Grazie!
| djinnZ wrote: | | Per la wlan ti consiglio di impostare DEFAULT_WESTWOOD=Y forse il problema è quello anche se avevo letto che il minstrel ultimamente dava problemi. |
Dove dovrei mettere questo settaggio? google non mi è stato amico, nel kernel questo settaggio non c'è...
| djinnZ wrote: | Per la lan... 150 è il valore più che ottimale ... per una 100 non per una 1000... quindi...
Mi sa che per qualche oscuro (ma non troppo) motivo la tua scheda non riconosce la lan come gigabit ma come ethernet 100 o non la impiega in full duplex.
Controlla i cavi, controlla l'hub, rivedi la conf del kernel, vedi se non ti serve del firmware per la scheda di rete per farla funzionare correttamente, controlla dmesg e vedi se viene correttamente riconosciuta. |
ethtool mi riporta una connessione gigabit full duplex, cosa confermata dal led dello switch.
Se su quel cavo ci attacco un laptop Windows, la rete va a palla.
Non mi risulta che quella lan abbia bisogno di firmware da caricarci... La Wi-Fi sì, e ho provato due versioni differenti ma non cambia una cippa. Diciamo che al momento vorrei risolvere quantomeno il problema sulla lan.
| djinnZ wrote: | | Controlla anche le prestazioni in I/O dal disco e le impostazioni per il multitasking, già che ci sei. Mi pare più un problema kernel/driver che di rete. |
hdtune e la copia tra i dischi vanno strabenone..
Grazie per l'aiuto!
L |
|
| Back to top |
|
|
sabayonino
Veteran
Joined: 03 Jan 2012
Posts: 1047
|
| Posted: Tue Jan 27, 2015 12:25 pm Post subject: |
|
|
sacchi"
[quote="djinnZ wrote: | | Per la wlan ti consiglio di impostare DEFAULT_WESTWOOD=Y forse il problema è quello anche se avevo letto che il minstrel ultimamente dava problemi. |
Dove dovrei mettere questo settaggio? google non mi è stato amico, nel kernel questo settaggio non c'è...
[/quote]
http://cateee.net/lkddb/web-lkddb/DEFAULT_WESTWOOD.html
e
http://cateee.net/lkddb/web-lkddb/TCP_CONG_WESTWOOD.html
| Code: | # zcat /proc/config.gz | grep CONG
CONFIG_DEFAULT_TCP_CONG="cubic"
|
imposti nel /usr/src/linux/.config (o un a configurazione precedente salvata)
CONFIG_DEFAULT_TCP_CONG="westwood"
con un semplice editor
e ricompili.
_________________
LRS 64/32 |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Wed Jan 28, 2015 9:47 am Post subject: |
|
|
| sacchi wrote: | | Dove dovrei mettere questo settaggio? google non mi è stato amico, nel kernel questo settaggio non c'è... |
Invece che indicare i vari passaggi ti do solo il nome della variabile, non per pigrizia ma perchè è più efficace.
Ho letto che tra i vari algoritmi in "tcp congestion" il westwood è più efficace a gestire i problemi delle connessioni wireless e si comporta meglio con le reti scasse rispetto agli altri.
In ogni caso se in menuconfig digiti "/" ti consente di cercare per nome variabile (e basta solo inserire "WESTWOOD" la ricerca può anche essere parziale) e ti riporta l'help consentendoti di trovarlo, anche se nella tua versione del kernel ha una posizione diversa. Per questo non si indica il percorso (che potrebbe cambiare) ma solo la variabile che attiva l'opzione. Non è una questione di pigrizia, non solo...
Se la inserisci direttamente (che razza di suggerimento...  sabayonino... leggi meglio... non è abilitato di default) non ti scordare l'oldconfig. Perchè non è detto che il modulo per il westwood sia compilato.
fai una prova in ftp/ssh/quelchetipare e vedrai che la rete è lenta a prescindere. Se non è un problema di samba è un problema del kernel. Non è che hai qualcosa di strampalato attivo? Prova a fare un poco di pulizia nella conf del kernel e semmai disabilita il traffic control se lo hai ma non è configurato.
Con questi pochi elementi e lo scarso tempo che ho non so che altro dirti.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
sabayonino
Veteran
Joined: 03 Jan 2012
Posts: 1047
|
| Posted: Wed Jan 28, 2015 11:24 am Post subject: |
|
|
| djinnZ wrote: |
Se la inserisci direttamente (che razza di suggerimento... sabayonino... leggi meglio... non è abilitato di default) non ti scordare l'oldconfig. Perchè non è detto che il modulo per il westwood sia compilato.
|
sono stato pure pigro io , ma lo si può cercare anche così perchè effettivamente non ho incolalto tutte le righe dell'outputtp
| Code: | zcat /proc/config.gz | grep CONG
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
|
e comunque ho indicato di cercare nella configrazione in uso o in quella salvata , sta da se (almeno da parte mia l'ho data per scontata in quanto richiamo sempre la configurazione salvata) che venga richiamata la configurazione. ( e passo sempre l'opzione --save-config)
vabbè metodi diversi ... cercavo di render l'idea
_________________
LRS 64/32 |
|
| Back to top |
|
|
sacchi
Tux's lil' helper
Joined: 28 May 2004
Posts: 104
|
| Posted: Mon Feb 09, 2015 6:33 am Post subject: |
|
|
| djinnZ wrote: | | sacchi wrote: | | Dove dovrei mettere questo settaggio? google non mi è stato amico, nel kernel questo settaggio non c'è... |
[..]In ogni caso se in menuconfig digiti "/" ti consente di cercare per nome variabile (e basta solo inserire "WESTWOOD" la ricerca può anche essere parziale) e ti riporta l'help consentendoti di trovarlo, anche se nella tua versione del kernel ha una posizione diversa. Per questo non si indica il percorso (che potrebbe cambiare) ma solo la variabile che attiva l'opzione. Non è una questione di pigrizia, non solo...
fai una prova in ftp/ssh/quelchetipare e vedrai che la rete è lenta a prescindere. Se non è un problema di samba è un problema del kernel. Non è che hai qualcosa di strampalato attivo? Prova a fare un poco di pulizia nella conf del kernel e semmai disabilita il traffic control se lo hai ma non è configurato. |
Grazie a tutti per l'aiuto!
In effetti avevo abbozzato un traffic control che però non avevo ancora abilitato (avevo solo un po' di classificazione dei pacchetti)... ho segato tutto e non è cambiato nulla.
Discorso un po' diverso per il westwood... non ho provato su wifi, ma su cavo mi pare che le cose siano leggermente migliorate... da 6-8 MB/sec sono passato a 12MB/sec... fa comunque sempre pietà.
Quando riuscirò, proverò a bootare una livecd e a fare un giro di iperf da lì... sono quasi certo che il problema sia in una qualche configurazione software. L'hardware scommetto che è ok.
Grazie di nuovo!!! |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Mon Feb 09, 2015 1:41 pm Post subject: |
|
|
Bada che il westwood è consigliato sulle reti wifi perchè reagisce meglio all'instabilità del segnale.
Di norma sulle reti cablate dovrebbe persino far perdere ma di certo non acquistare velocità. Può anche essere una banale interferenza causata da una presa elettrica allentata (ricordo che su reti elettiche a 220 i morsetti andrebbero serrati ogni 10 anni). Ma qualche problema sul cavo lo hai od è sballato l'MTU.
Mi pare che a De Gaulle attibuiscano il motto sugli imbecilli e le inamovibili certezze... Non c'è nulla di certo. Mai. Non ti fissare sul software e verifica l'hardware. Continui ad avere valori da 100 e non da 1000.
La mie esperienza mi dice che sono sempre tutti e due. Mai solo uno.
In ogni caso 100/8=12,5
edit: per il software dai uno sguardo qui e puoi incrementare ulteriormente con BPF_JIT=Y nella conf del kernel, il rovescio della medaglia è che se le regole iptables sono sballate non hai errore ma solo malfunzionamenti, alle volte incomprensibili.
Scusa ma era passato di mente anche a me che potresti avere un bridge e problemi conseguenti.
Lo potresti escludere semplicemente verificando se senza bridge la rete prende la piena velocità.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
sacchi
Tux's lil' helper
Joined: 28 May 2004
Posts: 104
|
| Posted: Mon Feb 16, 2015 9:06 pm Post subject: |
|
|
Ciao a tutti!
ok ho fatto delle prove.
A sistema avviato da settimane ho ottenuto questo mirabolante risultato:
| Code: | uname -a
Linux tuxserver 3.17.2 #2 SMP Mon Feb 9 07:19:14 CET 2015 x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux
iperf -c 192.168.1.50
------------------------------------------------------------
Client connecting to 192.168.1.50, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.254 port 54373 connected with 192.168.1.50 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.6 sec 15.5 MBytes 12.3 Mbits/sec |
Ho poi riavviato, ottenendo:
| Code: | iperf -c 192.168.1.50
------------------------------------------------------------
Client connecting to 192.168.1.50, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.254 port 39620 connected with 192.168.1.50 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 89.6 MBytes 75.0 Mbits/sec |
Ho poi avviato un liveCD di gentoo molto recente:
| Code: | uname -a
Linux livecd 3.16.5-gentoo #1 SMP Thu Dec 4 06:13:19 UTC 2014 x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux
iperf -c 192.168.1.50
------------------------------------------------------------
Client connecting to 192.168.1.50, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.254 port 42076 connected with 192.168.1.50 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 944 MBytes 791 Mbits/sec |
Insomma, l'hardware è ok.
Dove posso sbattere la testa ora? 
Molte grazie,
L |
|
| Back to top |
|
|
sacchi
Tux's lil' helper
Joined: 28 May 2004
Posts: 104
|
| Posted: Tue Feb 17, 2015 10:15 am Post subject: |
|
|
| djinnZ wrote: | Scusa ma era passato di mente anche a me che potresti avere un bridge e problemi conseguenti.
Lo potresti escludere semplicemente verificando se senza bridge la rete prende la piena velocità. |
Dimenticavo... non sono in bridge. La wifi e la lan cablata sono due sottoreti distinte.
Ciao e grazie,
L |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Tue Feb 17, 2015 2:24 pm Post subject: |
|
|
Leggi lo stesso il link e le verifiche che suggerisce.
Per prima cosa fai una scansione per rootkit, non capisco cosa possa rallentarlo (con la live evidentemente c'è un problema di interfaccia driver) dopo che è passato del tempo.
Hai un qualche demone o log di iptables attivi? Ad esempio un torrent che blocca tutto?
Controlla metrica ed MTU. Driver builtin per la gigabit (abbiamo capito che la wifi tutto sommato mantiene valori normali quindi accantoniamola ed evitiamo che la rete possa subire alterazioni) disabilitando il wifi (hostapd impazzito? dhcpd che va per le sue?) e controlla la conf di dhcpd.
Vedi anche cosa hai configurato sul tcpip (c'è un mare di cose da verificare).
Semplifica la configurazione e riduci le possibili cause del problema.
Per caso la gigabit è usata sia per connettersi al router che per tirar fuori verso gli altri la connessione?
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
sacchi
Tux's lil' helper
Joined: 28 May 2004
Posts: 104
|
| Posted: Tue Feb 17, 2015 3:41 pm Post subject: |
|
|
Ti ringrazio nuovamente per l'aiuto che mi stai dando.
La macchina è un minipc che mi fa da NAS. Ha due ethernet e una minipci su cui ho messo una scheda wifi. La uso anche come firewall/router, connettendo la rete su una ethernet, li modem ppp su un altra, oltre alla wifi configurata come access point. Come firewall uso shorewall, dove ho espressamente disabilitato ("TC_ENABLED=No") tutto quanto ha a che fare col traffic shaping.
| djinnZ wrote: | | Leggi lo stesso il link e le verifiche che suggerisce. |
Se non sbaglio, i comandi elencati sono pertinenti esclusivamente se c'è un bridge (tirarlo su, il comando brctl showstp, i loop, lo spanning tree...). Non riesco a trovare (e qui può essere colpa della mia ignoranza) cose pertinenti...
| djinnZ wrote: | Per prima cosa fai una scansione per rootkit, non capisco cosa possa rallentarlo (con la live evidentemente c'è un problema di interfaccia driver) dopo che è passato del tempo.
Hai un qualche demone o log di iptables attivi? Ad esempio un torrent che blocca tutto? |
Il problema del tempo vedo che in effetti è relativo, nel senso che quei valori sono molto ballerini... iperf mi può riportare 10 come 100 megabit. Sul rootkit ho pensato anch'io, ma non vedo processi o traffico anomalo. chkrootkit non trova nulla.
Prima di fare la prova ho ovviamente fermato tutto.
| djinnZ wrote: | Controlla metrica ed MTU. Driver builtin per la gigabit (abbiamo capito che la wifi tutto sommato mantiene valori normali quindi accantoniamola ed evitiamo che la rete possa subire alterazioni) disabilitando il wifi (hostapd impazzito? dhcpd che va per le sue?) e controlla la conf di dhcpd.
Vedi anche cosa hai configurato sul tcpip (c'è un mare di cose da verificare).
Semplifica la configurazione e riduci le possibili cause del problema. |
Ho spento tutti i servizi, ho spento la wifi, ho lasciato su solo ssh per arrivarci da remoto... non cambia una cippa.
L'MTU l'ho rimessa a 1500 da 8K, visto che anche a 8K faceva pietà. I due PC windows spostano file tra loro a 120MB/s (1 gigabit pieno) con l'MTU a 1500...
Come verifico la metrica? Quanto deve essere?
| Code: | ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.254 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::203:1dff:fe05:2884 prefixlen 64 scopeid 0x20<link>
ether 00:03:1d:05:28:84 txqueuelen 1000 (Ethernet)
RX packets 701171 bytes 61895686 (59.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1203878 bytes 1677306703 (1.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xfd2e0000-fd300000 |
| Code: | ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes |
| djinnZ wrote: | | Per caso la gigabit è usata sia per connettersi al router che per tirar fuori verso gli altri la connessione? |
No, ho un modem configurato in ppp connesso alla eth1.
Grazie di nuovo!
L |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Mon Feb 23, 2015 5:56 pm Post subject: |
|
|
Sempre più strano.
Puoi postare /etc/conf.d/net?¹
¹senza commenti e se usi systemd e/o NM ... t'arrangi
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
sacchi
Tux's lil' helper
Joined: 28 May 2004
Posts: 104
|
| Posted: Mon Feb 23, 2015 8:16 pm Post subject: |
|
|
| djinnZ wrote: | | Puoi postare /etc/conf.d/net? |
Ciao!
Eccotelo qui, scremato dai commenti:
| Code: | config_eth0="192.168.1.254 netmask 255.255.255.0 brd 192.168.1.255"
mtu_eth0="1500"
dns_server_eth0="62.149.128.4 62.149.132.4"
config_wlan0="192.168.2.254 netmask 255.255.255.0 brd 192.168.2.255"
channel_wlan0="5"
essid_wlan0="TuxServer"
mode_wlan0="master"
modules_wlan0="ifconfig !iwconfig !wpa_supplicant"
config_ppp0="ppp"
mtu_ppp0="1492"
link_ppp0="eth1"
plugins_ppp0="pppoe"
pppd_ppp0="+ipv6 noipdefault defaultroute usepeerdns persist user user password pass"
|
Grazie di tutto,
L |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Tue Feb 24, 2015 7:43 pm Post subject: |
|
|
Non capisco perché usare due sottoreti distinte e non un bridge ed ancor meno perché impostare i dns in questo modo. Comunque:
Prova se | Code: | | route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0 |
risolve il problema.
Idem per l'altra sottorete.
| /etc/init.d/net: | config_eth0="192.168.1.254/0"
routes_eth0="192.168.1.0/0 via eth0" |
dovrebbe essere la configurazione corretta. Non sono sicuro della sintassi e non posso verificare per qualche giorno.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
sacchi
Tux's lil' helper
Joined: 28 May 2004
Posts: 104
|
| Posted: Tue Feb 24, 2015 10:11 pm Post subject: |
|
|
| djinnZ wrote: | | Non capisco perché usare due sottoreti distinte e non un bridge ed ancor meno perché impostare i dns in questo modo. |
Ho voluto separare la wifi pensando mi agevolasse nel fare traffic shaping... quello che passa da lì avrebbe la priorità minima.
Come vanno impostati i dns?
| djinnZ wrote: | Prova se | Code: | | route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0 |
risolve il problema.
Idem per l'altra sottorete. |
| Code: | iperf -c 192.168.1.50
------------------------------------------------------------
Client connecting to 192.168.1.50, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.1.254 port 54129 connected with 192.168.1.50 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 21.9 MBytes 18.3 Mbits/sec |
Non è cambiato nulla...
| djinnZ wrote: | | /etc/init.d/net: | config_eth0="192.168.1.254/0"
routes_eth0="192.168.1.0/0 via eth0" |
dovrebbe essere la configurazione corretta. Non sono sicuro della sintassi e non posso verificare per qualche giorno. |
Ti ringrazio, la sistemo.
L |
|
| Back to top |
|
|
sacchi
Tux's lil' helper
Joined: 28 May 2004
Posts: 104
|
| Posted: Wed Feb 25, 2015 10:20 am Post subject: |
|
|
Una cosa strana che ho notato è che, quando scarico molto dalla LAN, il serverino diventa molto lento e trovo valori occupati di cpu molto alti di ksoftirqd e di kworker.
Questo sia quando scarico contenuti da internet, sia quando scarico contenuti dal serverino stesso...
Addirittura, se li faccio insieme, tiro giù file via samba a solo 1MB/s...
Per me c'è qualche problema di configurazione del modulo e1000e... ricompilo il kernel mettendo e1000e come modulo poi gioco un po' con i parametri da passargli come dal sito https://gist.github.com/pklaus/319367 .
Ti tengo aggiornato!
Grazie,
L |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Wed Feb 25, 2015 10:39 am Post subject: |
|
|
Supponevo che anche le richieste verso la rete locale passassero per il default gw. Di qui il rallentamento.
Puoi anche provare staccando il modem. Prova con un trace a vedere cosa succede ai pacchetti. Se vanno a spasso verso l'esterno o sulla wifi.
I dns o li lasci impostare a pppd o usi /etc/resolv.conf. Quella sintassi è per il caso specifico in cui hai differenti dns (in genere locali) su differenti sottoreti.
Il traffic shaping per interfaccia e non per servizio o per ip è più ... "statico".
Per esempio potresti volere che il tuo portatile possa avere priorità assoluta indifferentemente dalla connessione usata. Assegni in dhcpd.conf lo stesso ip (basta mettere l'indirizzo ethernet sia della lan che della wifi) al dispositivo e dai precedenza a quell'ip. In più dhcpd ha qualche problema a gestire più sottoreti distinte.
L'esperienza mi ha insegnato che la strada più semplice è sempre la migliore.
Se passi al bridge vedi che la strada corretta è impostare il bridge solo sulla ethernet e lasciare che sia hostapd ad aggiungere la wlan al bridge (in hostapd.conf).
| Code: | config_eth1="null"
modules_wlan="ifconfig !iwconfig !wpa_supplicant"
config_wlan="null"
essid_net2="xxxxxxx"
# br0
bridge_br0="eth1"
config_br0="172.30.0.6/28"
routes_br0="default via 172.30.0.1
172.30.0.0/28 via 172.30.0.14" |
Male che vada fai una prova.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
sacchi
Tux's lil' helper
Joined: 28 May 2004
Posts: 104
|
| Posted: Wed Feb 25, 2015 12:56 pm Post subject: |
|
|
| djinnZ wrote: | Supponevo che anche le richieste verso la rete locale passassero per il default gw. Di qui il rallentamento.
Puoi anche provare staccando il modem. Prova con un trace a vedere cosa succede ai pacchetti. Se vanno a spasso verso l'esterno o sulla wifi. |
Ho rimosso i moduli p54pci e p54common, la wifi ora non esiste. Ragioniamo solo sulla ethernet cablata.
Ho verificato che i pacchetti non vadano in giro. Ho fatto un tcpdump sul serverino sia con un trasferimento samba sia con iperf alla macchina da cui sto scrivendo e ho dato in pasto il file a wireshark. Vedo solo pacchetti che vanno dall'ip del serverino all'ip della macchina con cui sto scrivendo, quindi tutto ok.
| djinnZ wrote: | | I dns o li lasci impostare a pppd o usi /etc/resolv.conf. Quella sintassi è per il caso specifico in cui hai differenti dns (in genere locali) su differenti sottoreti. |
Ora che me l'hai fatto ricordare... li avevo aggiunti perché pppd non me li impostava... comunque al momento non ci interessa.
Ho messo e1000e come modulo, non è cambiato nulla. Non ho giocato coi parametri da passare al modulo, perché vedo che quando metto in scarico qualcosa da internet, gli irq al secondo vanno da 150-200 a poco oltre 4000 (con "perf top")... e mi pare regionevole...
Smanettando, ho appunto conosciuto la potenza del comando perf...
Mi puoi aiutare a commentare questo report per cortesia?
L'ho fatto sia in idle sia quando un pc in lan scarica un file, e non cambia molto. Quello che cambia tantissimo è che, nel primo caso, la CPU lavora per lo 0.0-0.3% (da comando "top"), nel secondo caso schizza al 90% grazie a kworker e ksoftirqd.
| Code: | 78.38% ksoftirqd/0 [kernel.kallsyms] [k] ipt_do_table
|
--- ipt_do_table
|
|--99.84%-- iptable_filter_hook
| nf_iterate
| nf_hook_slow
| |
| |--99.79%-- ip_forward
| | ip_rcv_finish
| | ip_rcv
| | __netif_receive_skb_core
| | __netif_receive_skb
| | |
| | |--52.42%-- process_backlog
| | | net_rx_action
| | | __do_softirq
| | | |
| | | |--99.77%-- run_ksoftirqd
| | | | smpboot_thread_fn
| | | | kthread
| | | | ret_from_fork
| | | --0.23%-- [...]
| | |
| | --47.58%-- netif_receive_skb_internal
| | napi_gro_receive
| | e1000_receive_skb
| | e1000_clean_rx_irq
| | e1000e_poll
| | net_rx_action
| | __do_softirq
| | |
| | |--99.80%-- run_ksoftirqd
| | | smpboot_thread_fn
| | | kthread
| | | ret_from_fork
| | --0.20%-- [...]
| --0.21%-- [...]
--0.16%-- [...] |
Da ignorante capisco che il problema in parte sembrerebbe nel modulo e1000e...ma perché col livecd che usa lo stesso modulo funziona tutto bene???
Grazie ancora per la pazienza!
L
Last edited by sacchi on Wed Feb 25, 2015 7:32 pm; edited 1 time in total |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Wed Feb 25, 2015 4:18 pm Post subject: |
|
|
A tentoni sospetterei che ti potrebbe servire
CONFIG_IP_NF_TARGET_ULOG=N
NETFILTER_XT_TARGET_LOG=N
O qualcosa del genere.
Oppure le funzioni di risparmio energetico/acpi che nel livecd non dovrebbero proprio essere state abilitate.
Una rapida ricerca su internet riporta che CONFIG_INET_LRO=N e/o disabilitare nei parametri del modulo ASPM (non so se c'è) dovrebbe risolvere.
Forse non hai tutti i torti a smanettare con i parametri. male che vado con nomemodulo.parametro= in linea di comando te li rimetti anche sul builtin.
Qualcun altro pare che si sia rivolto al vecchio modulo driver (ma mi sembra una bestialità).
Di norma pppd/NM/o quel che è impostano resolv.conf
Hai solo usato un metodo desueto ed in genere viene impostato per interfaccia.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
sacchi
Tux's lil' helper
Joined: 28 May 2004
Posts: 104
|
| Posted: Wed Feb 25, 2015 7:31 pm Post subject: |
|
|
Ciao,
sono appena rientrato e ora non riesco a fare la prova che mi dici, ma prima di uscire ho trovato qualcosa di significativo!
Smanettando, ho staccato la eth1 dal modem ppp... Ho poi riavviato, ma shorewall non è partito appunto perché ppp0 era giù... e, con questa configurazione, iperf mi ha dato 980 megabit!
Samba non sono riuscito a provarlo perché mi dipende da ppp0 (sarebbe bello segare questa dipendenza...). Appena ho riattaccato il modem, le prestazioni sono crollate.
A questo punto è quasi certamente un problema legato a iptables, che è una cosa dove mi muovo malissimo. C'è qualcosa che posso postare per trovare l'inghippo?
Di nuovo un grazie infinito per l'aiuto!!
L |
|
| Back to top |
|
|
sacchi
Tux's lil' helper
Joined: 28 May 2004
Posts: 104
|
| Posted: Wed Feb 25, 2015 10:58 pm Post subject: [RISOLTO] iperf e valori molto bassi... |
|
|
SIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII!!!!!!!!
Il problema era che avevo una catena "dynamic" in iptables ultralunghissima, che veniva popolata dal firewall in maniera dinamica quando si tenta l'accesso a determinate porte in modo da blacklistarle.
Ho vuotato la catena e ora ho il gigabit con iperf e 110MB/s con samba!!!!!
GRAZIE DELLA PAZIENZA!
L |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Thu Feb 26, 2015 2:15 pm Post subject: |
|
|
Questo dimostra quanto siano utili i wizard del piffero... e le altre trovate da bimbominkia di RH ed M$ (o peggio ad imitazione di tali perversioni)
Aggiungi il risolto. Pensavo che fosse scontato disablitare il firewall in situazioni del genere...
Quanto ti ho indicato sembra essere comunque valido per la scheda che hai.
Se ti applichi un poco (tanto tutte queste complicazioni per un server SOHO non servono proprio a nulla) ed usi una configurazione decente del firewall (non le idiozie di questi wizard mascherasti da applicazione) con il compilatore jit abilitato vedrai la differenza.
Anche con uptime di svariati mesi.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
sacchi
Tux's lil' helper
Joined: 28 May 2004
Posts: 104
|
| Posted: Thu Feb 26, 2015 11:53 pm Post subject: |
|
|
Avevo sì fermato il firewall, ma ho scoperto che non serve a nulla perché shorewall si occupa solo di "tradurre" il suo setup per iptables... Non è un demone attivo.
Mi è venuto il dubbio perché con perf top si vede che la cpu esegue molto la ipt_do_table()...
Grazie ancora,
L |
|
| Back to top |
|
|
djinnZ
Advocate
Joined: 02 Nov 2006
Posts: 4831
Location: somewhere in L.O.S.
|
| Posted: Fri Feb 27, 2015 1:21 pm Post subject: |
|
|
| sacchi wrote: | | il suo setup |
del piffero | sacchi wrote: | | per iptables |
quando, in una installazione casalinga cose come il blocco dinamico delle porte non servono assolutamente a nulla. hai tre pc da controllare, blocchi tutto ed abiliti solo quello che ti serve, anche all'occorrenza.
Semplice, performante ed a prova di errori.
Shorewall introduce metodi assurdi e contorti.
_________________
scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
| Back to top |
|
|
|
Forum italiano (Italian)
