lasciala a 1480.
ora ti saluto.
la notte porta consiglio.
fai un analisi dell’MTU, come nei post precedenti, mediante l’altro sistema operativo?
prova a mettere gli ip statici e prova a disattivare networkmanager
[virus]
Questo è il risultato di speedguide fatto su xp :
Tested on: 05.02.2008 06:21
IP address: 89.188.xxx.xxx
TCP options string: 020405a001010402
MSS: 1440
MTU: 1480
TCP Window: 65535 (NOT multiple of MSS)
RWIN Scaling: 0
Unscaled RWIN : 65535
Reccomended RWINs: 63360, 126720, 253440, 506880
BDP limit (200ms): 2621kbps (328KBytes/s)
BDP limit (500ms): 1049kbps (131KBytes/s)
MTU Discovery: ON
TTL: 100
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)
La cosa più evidente è il valore di "TCP Windows " che a 65535 rispetto ai 5760 di linux , stò provando a cercare di modificare questo valore , ma è un casino …
[mandela900]
gia provato ma non ho avuto nessun miglioramento 
posta l’output del comando ( da root) :
# cat /proc/sys/net/ipv4/tcp_window_scaling[quote=virus]
posta l’output del comando ( da root) :
# cat /proc/sys/net/ipv4/tcp_window_scalingIl tcp_window_scaling è impostato su 1 quindi è attivo ,
ho trovato anche questo interessante articolo
http://www.speedguide.net/read_articles.php?id=121
Impostando quei valori i download partano a velocità stratosferiche per poi abbasarsi fino ad arrivare fissi su 60/62 KiB/s .
Ho trovato anche questo articolo :
http://www.psc.edu/networking/projects/tcptune/#Linux
Che parla di una funzionalità implementata dal kernel 2.6.17 di autotuning del protocollo TCP .
Ho cambiato un fracasso di valori come indicato in quelle guide , ma il risultato non cambia …
mi sà che non ho speranze …
sono curioso di sapere come si comporta se dai un :
# echo 0 > /proc/sys/net/ipv4/tcp_window_scalingtesta la velocità e rifai il test precedente.
spero che la configurazione sia quella degli output precedenti.
[quote=virus]
sono curioso di sapere come si comporta se dai un :
# echo 0 > /proc/sys/net/ipv4/tcp_window_scalingtesta la velocità e rifai il test precedente.
spero che la configurazione sia quella degli output precedenti.[/quote]
A livello di velocità non cambia niente , l’unica differenza è che su SpeedGuide :
RWIN scaling = 0
Prova a guardare questa cosa che dice SpeedGuide :
Default TCP Receive Window (RWIN) = 5840
RWIN Scaling (RFC1323) = 0 bits
Unscaled TCP Receive Window = 5840
Under many Linux distributions readings in the Analyzer only show the Current TCP Window.
RWIN seems to be set to a very small number. If you’re on a broadband connection, consider using a larger value.
For optimum performance, consider changing RWIN to a multiple of MSS.
Other RWIN values that might work well with your current MTU/MSS:
506880 (MSS x 44 * scale factor of 8)
253440 (MSS x 44 * scale factor of 4)
126720 (MSS x 44 * scale factor of 2)
63360 (MSS x 44)
Ho provato in tutti i modi a aumentare il valore RWIN ma non cambia niente…
fammi dare un occhiata alla situazione:
[code]# cd /proc/sys/net/ipv4
for i in * ; do echo “$i”;cat $i;done
[/code]
posta l’output.
[quote=virus]
fammi dare un occhiata alla situazione:
[code]# cd /proc/sys/net/ipv4
for i in * ; do echo “$i”;cat $i;done
[/code]
posta l’output.[/quote]
cipso_cache_bucket_size
10
cipso_cache_enable
1
cipso_rbm_optfmt
0
cipso_rbm_strictvalid
1
conf
cat: conf: Is a directory
icmp_echo_ignore_all
0
icmp_echo_ignore_broadcasts
1
icmp_errors_use_inbound_ifaddr
0
icmp_ignore_bogus_error_responses
1
icmp_ratelimit
1000
icmp_ratemask
6168
igmp_max_memberships
20
igmp_max_msf
10
inet_peer_gc_maxtime
120
inet_peer_gc_mintime
10
inet_peer_maxttl
600
inet_peer_minttl
120
inet_peer_threshold
65664
ip_default_ttl
64
ip_dynaddr
0
ip_forward
0
ipfrag_high_thresh
262144
ipfrag_low_thresh
196608
ipfrag_max_dist
64
ipfrag_secret_interval
600
ipfrag_time
30
ip_local_port_range
32768 61000
ip_nonlocal_bind
0
ip_no_pmtu_disc
1
neigh
cat: neigh: Is a directory
route
cat: route: Is a directory
tcp_abc
0
tcp_abort_on_overflow
0
tcp_adv_win_scale
2
tcp_allowed_congestion_control
cubic reno
tcp_app_win
31
tcp_available_congestion_control
cubic reno
tcp_base_mss
512
tcp_congestion_control
cubic
tcp_dma_copybreak
4096
tcp_dsack
1
tcp_ecn
0
tcp_fack
1
tcp_fin_timeout
60
tcp_frto
2
tcp_frto_response
0
tcp_keepalive_intvl
75
tcp_keepalive_probes
9
tcp_keepalive_time
7200
tcp_low_latency
0
tcp_max_orphans
32768
tcp_max_ssthresh
0
tcp_max_syn_backlog
1024
tcp_max_tw_buckets
180000
tcp_mem
97440 129920 194880
tcp_moderate_rcvbuf
1
tcp_mtu_probing
1
tcp_no_metrics_save
0
tcp_orphan_retries
0
tcp_reordering
3
tcp_retrans_collapse
1
tcp_retries1
3
tcp_retries2
15
tcp_rfc1337
0
tcp_rmem
4096 87380 4194304
tcp_sack
1
tcp_slow_start_after_idle
1
tcp_stdurg
0
tcp_synack_retries
5
tcp_syncookies
1
tcp_syn_retries
5
tcp_timestamps
0
tcp_tso_win_divisor
3
tcp_tw_recycle
0
tcp_tw_reuse
0
tcp_window_scaling
0
tcp_wmem
4096 65536 4194304
tcp_workaround_signed_windows
0
Alcuni valori non sono quelli di default perché gli stò modificando runtime per vedere i cambiamenti ( tcp_wmem , scaling ,tcp_rmem )
vediamo questi:
# echo 4096 16384 4157440 > /proc/sys/net/ipv4/tcp_wmem
prova il test.
[quote=virus]
vediamo questi:
# echo 4096 16384 4157440 > /proc/sys/net/ipv4/tcp_wmem
prova il test.[/quote]
Non vi è alcuna differenza , avevo gia provato a modificare quei valori , inoltre ho provato ad installare anche mandriva ma fa esattamente la stessa cosa …
stiamo andando alla ceca.
ci sono due possilità:
-
la tua configurazione è scorretta, e noi non vediamo per qualche motivo il punto critico.
-
il tuo provider utilizza parametri di connessione “esotici”.
non possiamo andare avanti a tentativi.
proviamo a stilare una tabella di marcia.
fissiamo l’attenzione sul punto 2, sia a te che a me, sembra la situazione più probabile. Quindi:
a- raccogliere tutte le informazioni utili sui parametri di connessione del tuo provider, magari telefonando al servizio tecnico.
b- cercare un amico in zona che abbia il tuo stesso provider, presentarsi a casa sua con una live, e fare una prova.
c- se funziona bene, possiamo fissare l’attenzione sul tuo router (rileva i parametri con il comando del post #29).
d- se non funziona siamo sicuri che il problema risiede nei parametri di connessione (così eliminiamo il caso 1).
Credo che l’ipotesi più corretta sia la seconda , per due motivi :
1° Ho fatto diverse prove anche con distro dieverse lasciando i settaggi di default e provando poi a modificarli , senza ottenere alcun risultato .
2° La connessione che utilizzo è un po’ atipica , simile al wireless che si chiama hiperlan , in quanto dove abito non è coperto dall’adsl . Questa tecnologia utilizza un’antenna con un interfaccia radio e una ethernet che fa anche da router .
L’unico problema è che non saprei cosa chiedere al provider che mi fornisce il servizio …
Mi stai dicendo che quella che fino al post precedente chiamavi Adsl è una Hiperlan?
Questo dovrebbe chiarire tutto.
vuoi darci le specifiche di quello che tu chiami “router”?
modello - produttore - e quanto altro hai a disposizione.
ps: modifico il titolo della discussione in Hiperlan…
[quote=virus]
Mi stai dicendo che quella che fino al post precedente chiamavi Adsl è una Hiperlan?
Questo dovrebbe chiarire tutto.
vuoi darci le specifiche di quello che tu chiami “router”?
modello - produttore - e quanto altro hai a disposizione.
ps: modifico il titolo della discussione in Hiperlan…[/quote]
In realtà la cosa è trasparente perché il collegamento arriva dall’antenna tramite ethernet .
Comunque visto che il provider non è molto chiaro su ciò che ci ha dato , le info che ho raccolto sono queste :
-
Antenna :
http://www.mikrotik.com/pricelist.php?sect=3#product18 -
Sulla scheda gira un sistema che si chiama “RouterOS”
http://www.mikrotik.com/
Queste purtroppo sono le uniche informazioni che ho …
Sicuramente è trasparente, altrimenti non ti andrebbe il collegamento.
Ma è altamente probabile che questo “router” non rispetti gli standard Lan come tu stesso hai convenuto.
non hai informazioni più specifiche ?
mi trovi il tuo sul sito del produttore ?
è possibile rilevare le impostazioni di questa scheda?
[quote]
non hai informazioni più specifiche ?[/quote]
Purtroppo no , ma ho mandato una richiesta al provider per averle
Il modello da questo sito http://www.mikrotik.com/pricelist.php?sect=3#product18
è il RIC/522T
La gestione di quel apparato avviene solo dal provider , ho provato a fare delle scansioni su possibili porte aperte , ma non ne risultano .
Ho fatto alcune ricerche , tra persone che utilizzano il mio stesso servizio , e linux , e loro non hanno questo tipo di problema , a questo punto mi sa che sia colpa dell’antenna/router .
Grazzie mille a tutti per le risposte e scusate se vi ho fatto perdere tempo .
proviamo a darti qualche altro input: per le Hiperlan c’è un forte decadimento di segnale quando i collegamenti non sono a vista. Questo aspetto è stato sempre considerato?
p.s.: avendo tu detto questo:
pensavo che magari, per coincidenza, durante queste prove ci sono stati degli ostacoli frapposti che stai sottovalutando