# [RISOLTO] iperf e valori molto bassi...

## sacchi

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!

LLast edited by sacchi on Thu Feb 26, 2015 11:46 pm; edited 1 time in total

----------

## djinnZ

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.   :Twisted Evil: 

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.

----------

## sacchi

 *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

----------

## sabayonino

 *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

```
# 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.

----------

## djinnZ

 *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...  :Confused:  sabayonino... leggi meglio... non è abilitato di default) non ti scordare l'oldconfig. Perchè non è detto che il modulo per il westwood sia compilato.

 *sacchi wrote:*   

> ...

 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.

----------

## sabayonino

 *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

```
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

----------

## sacchi

 *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!!!

----------

## djinnZ

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.  :Wink:  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à.

----------

## sacchi

Ciao a tutti!

ok ho fatto delle prove.

A sistema avviato da settimane ho ottenuto questo mirabolante risultato:

```
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:

```
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:

```
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?  :Smile: 

Molte grazie,

L

----------

## sacchi

 *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

----------

## djinnZ

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?

----------

## sacchi

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?

```
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  
```

```
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

----------

## djinnZ

Sempre più strano.

Puoi postare /etc/conf.d/net?¹

¹senza commenti e se usi systemd e/o NM ... t'arrangi

----------

## sacchi

 *djinnZ wrote:*   

> Puoi postare /etc/conf.d/net?

 

Ciao!

Eccotelo qui, scremato dai commenti:

```
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

----------

## djinnZ

Non capisco perché usare due sottoreti distinte e non un bridge ed ancor meno perché impostare i dns in questo modo. Comunque:

Prova se 

```
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0
```

risolve il problema.

Idem per l'altra sottorete.

```
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.

----------

## sacchi

 *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 
> 
> ```
> route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0
> ```
> ...

 

```
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:*   

> 
> 
> ```
> config_eth0="192.168.1.254/0"
> 
> ...

 

Ti ringrazio, la sistemo.

L

----------

## sacchi

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

----------

## djinnZ

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).

```
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.

----------

## sacchi

 *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.

```
    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!

LLast edited by sacchi on Wed Feb 25, 2015 7:32 pm; edited 1 time in total

----------

## djinnZ

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.

----------

## sacchi

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

----------

## sacchi

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

----------

## djinnZ

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...  :Evil or Very Mad: 

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.

----------

## sacchi

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

----------

## djinnZ

 *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.

----------

