Newsgroup: it.tlc.gestori.fastweb
Titolo: Solo 1Mbit verso l'esterno...

Napoli, Fibra.
Dopo l'ennesiomo download a 117KByte/sec mi decido a chiamare l'192193 per
esporre il problema, faccio presente + volte che nella rete interna vado
benone ma che sembra che ci siano alcuni problemi verso il resto del mondo.
La signorina dall'altro capo pensa bene di leggermi tutte le soluzioni
pronte all'uso che includono:
-Controllare in risorse del sistema se c'è una x vicino alla scheda di rete
-disattivazione firewall che non ho
-disattivazione dell'antivirus che non ho
-pulizia di file temporanei (?)
-impostazione della protezione bassa in IE (??)
-cancellazione della cronologia (???)
-cancellazione dei cookie (?????)
ovviamente non si risolve nulla  ed io incacchiato un pochettino per
l'incompetenza e/o la non voglia di starmi ad ascoltare mi faccio avanti...
"Non è che fastweb limita le connessioni all'esterno ad 1Mbit ? perchè
questa è la velocità che raggiungo sempre, nulla di + nulla di meno." le
dico.
"Assolutamente no ! mi risponde, inoltrerò subito la sua richiesta a chi si
occupa di queste questioni", e continuava dicendo che non erano noti
problemi di sovraccarico di linee o di connettività in generale.
A questo punto mi sono adoperato un pò ed ho provato pathchar.
Esso è un programma che permette di testare le velocità di collegamento (la
banda disponibile in un dato momento) tra i vari hop per i quali passa la
connessione tra noi e un indirizzo remoto.
Manco a dirlo, ho avuto ragione, come dimostra l'output che incollo di
seguito.
root@ttyp0[pathchar]# ./pathchar 
ftp.unina.it
 -m 1500 -q 10 -Q 10
pathchar to 
ftp.unina.it
 (192.132.34.17)
doing 10 probes at each of 10 sizes (64 to 1500 by 156)
0 localhost
    | 4.5 Mb/s, 156 us (3.00 ms)
1 39.7.31.2 (39.7.31.2)
    | ?? b/s, 34 us (2.98 ms)
2 10.251.148.1 (10.251.148.1)
    | ?? b/s, 4 us (2.91 ms)
3 10.251.144.23 (10.251.144.23)
    | 72 Mb/s, 25 us (3.13 ms)
4 10.251.145.1 (10.251.145.1)
    | 275 Mb/s, -9 us (3.16 ms)
5 10.251.149.194 (10.251.149.194)
                                        -> 10.3.136.33 (98)
    | ?? b/s, -4 us (3.03 ms)
6?10.3.136.37 (10.3.136.37)
                                        -> 10.3.128.13 (99)
    | 230 Mb/s, 82 us (3.25 ms)
7?10.3.128.9 (10.3.128.9)
                                    -> 10.254.1.209 (99)
    | ?? b/s, 21 us (3.27 ms)
8?10.254.1.197 (10.254.1.197)
                                        -> 10.254.0.18 (98)
    | ?? b/s, 7.16 ms (17.6 ms)
9?10.254.0.22 (10.254.0.22)
                                          -> 59.59.59.82 (98)
    | 48 Mb/s, 110 us (18.0 ms)
10?59.59.59.58 (59.59.59.58)
    | ?? b/s, 202 us (18.3 ms)
11 59.51.3.34 (59.51.3.34)
    | 198 Mb/s, -466 us (17.4 ms), +q 1.58 ms (39.1 KB)
12 59.59.60.17 (59.59.60.17)
    | ?? b/s, 881 us (19.2 ms)
13 59.59.59.137 (59.59.59.137)
    | ?? b/s, -797 us (17.6 ms)
14 81.208.50.200 (81.208.50.200)
    | 77 Mb/s, 821 us (19.4 ms), +q 1.47 ms (14.1 KB), 3% dropped
15 
garr.mix-it.net
 (217.29.66.39)
    | 440 Mb/s, 4.26 ms (27.9 ms), +q 1.83 ms (101 KB)
16 
rt-mi2-rt-rm1.rm1.garr.net
 (193.206.134.14)
    | 384 Mb/s, 1.58 ms (31.1 ms), +q 1.39 ms (66.6 KB)
17 
rt-rm1-rt-na1.na1.garr.net
 (193.206.134.245)
    | 143 Mb/s, -553 us (30.1 ms), +q 1.10 ms (19.6 KB)
18 
unina-rt.na.garr.net
 (193.206.130.6)
    | ?? b/s, -166 us (29.6 ms)
19 
garr-gw-na1.unina.it
 (192.133.28.254)
    | 30 Mb/s, 793 us (31.6 ms), +q 1.47 ms (5.60 KB), 2% dropped
20 143.225.190.198 (143.225.190.198)
    | 12 Mb/s, 250 us (33.1 ms), +q 1.70 ms (2.54 KB), 14% dropped
21 
ftp.unina.it
 (192.132.34.17)
21 hops, rtt 28.8 ms (33.1 ms), bottleneck 4.5 Mb/s, pipe 18828 bytes
root@ttyp0[pathchar]#
Il log mostra chiaramente che a parte il test su localhost (4,5Mbit/sec
dovuto al fatto che la connessione è half-duplex [10Mbit/2-overhead]  )
in quel momento la banda a mia disposizione (e cioè il collo di bottiglia)
era rappresentato dalla comunicazione tra'hop numero 20 ed il 21 ed era pari
a 12Mbit/sec.
Ma il mio download non superava l' 1Mbit/sec nello stesso momento.
...A voi le dovute conclusioni
PS: se c'è qualcuno con una maggior dimestichezza nell'uso di pathchar che
mi potesse illustrare il significato  di output tipo "  -> 10.3.136.33 (98)
" visibile sugli hop 1-->9 glie ne sarei grato.
PPS: Inutile dire che avrei piacere di essere smentito.

 A questo punto mi sono adoperato un pò ed ho provato pathchar.
Secondo te la signorina cosa avrebbe dovuto fare? Fare a casaccio magari di
sua fantasia?
Non ha risolto al volo il problema quindi è incompentente...certo avrebbe
dovuto applicare tutte le sue conoscenze personali anzichè applicare quelle
che gli hanno fornito. Poi aggiungiamo che non voleva ascolatare uno che ne
sapeva più di lei.....certo ti ha seguito con pazienza ed ora non ti vuole
ascoltare......ah ecco che ti adoperi con pathcar...! Senti a me....quanto
chiami il call center mettiti l'animo in pace e segui le loro procedure poi
fai quello che vuoi ma in pieno spirito di collaborazione........che di
clienti saccenti ne ho piene le sfere....ne?!
Scherzi a parte...c'è tutto un mondo da quella parte della cornetta che
forse neanche riesci ad immaginere e l'unica persona con cui non te la devi
prendere...è proprio con chi ha il coraggio di risponderti.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

l'incompetenza e/o la non voglia di starmi ad ascoltare mi faccio avanti...
Scendi dal pero. Le scimmie ammaestrate dell'help desk di primo livello
di un ISP consumer non sono pagate per essere competenti, ma per leggere
il copione agli utenti.
Se ha veramente passato la tua segnalazione al livello superiore allora
ha svolto il proprio compito in maniera più che soddisfacente.
Naturalmente se si tratta di una questione commerciale piuttosto che
tecnica è ovvio che non riceverai risposta.
-- 
ciao,
Marco

 ha scritto nel messaggio 
news:3VQkd.4523$n%2.4...@tornado.fastwebnet.it...
vorrei esporti la mia esperienza personale:
premettendo che sono un (felice) abbonato adsl telecom, ti informo che da 
ormai 2-3 mesi quando un mio amico (siamo entrambi di roma) mi manda un file 
(lui è abbonato fibra) non riusciamo mai ad andare oltre i 20k. abbiamo 
provato tutti i vari programmi... messenger, mirc, svariati p2p...
ovviamente non vi sono altri trasferimenti file in corso, io non mando 
niente a nessuno e lui non manda niente a nessun altro. anche lui se invia 
(o scarica) un file a un altro abbonato fastweb non ha problemi di velocità.
a questo punto il sospetto che fastweb limiti (e di molto) le connessioni 
verso l'esterno diventa qualcosa di più di un semplice sospetto...

 ha scritto nel messaggio 
news:u7Tkd.311903$35.14...@news4.tin.it...
aggiungo al mio post precedente questo link, che secondo me riassume un pò 
la situazione:
http://www.p2pforum.it/forum/showthread.php?threadid=20516
 

 ha svolto il proprio compito in maniera piů che soddisfacente.
E se chi di dovere ignora tale segnalazione ...vai di reclami sulla my
fastpage!



Permettimi di dissentire,
1) non sei nella posizione di parlare di "clienti saccenti",
2) se ne hai piene le sfere non leggere, o se lavori al 192193, licenziati.
- Premesso che le due premesse fossero in tono scherzoso
ultima e non meno importante:
"il coraggio di risponderti"????
wè, mica parliamo del 187 o della Vodafone, che come niente
ti chiudono il telefono in faccia,
il 192193 è un servizio con le palle
e deve solo migliorare ed uniformarsi meglio.. 

 il copione agli utenti.
*
alcuni perņ competenti lo sono,
speriamo non li caccino via..

 e deve solo migliorare ed uniformarsi meglio..
Stai blaterando a vanvera...e non hai capito il senso del mio intervento.
Rileggi per favore!
P.S.; 192193 e gli altri che hai nominato hanno le paxxe..se a qualcuno
mancano non è certo a chi risponde al tel!



? uhmm
parliamo due lingue diverse mi sa 

 che gli hanno fornito.
Se io ti dico che navigo nella rete interna e tu mi fai controllare che la
scheda di rete funziona,
c'è qualcosa che non va (incompetenza)
Se io ti dico (appurato che non hai le conoscenze necessarie) che il
problema non è il mio e tu mi fai controllare i cookie di IE allora vuol
dire che non mi stai nemmeno a sentire.
Ad ogni modo non mi sembra di aver insultato o denigrato la gentile
signorina, ho semplicemente espresso i fatti così come sono andati.
Anche se non si è capito bene il tono della tua risposta (ironico ?) cmq il
mio obiettivo non era lamentarmi, ma portare a conoscenza di tutti un fatto
che immaginavo avrebbe potuto interessare parecchi di voi, visto che il
problema è generalizzato a molte città.
Saluti.

 divento!
Mi sfugge quando io avrei fatto una cosa del genere, se è anche a me che ti
rivolgi.

 ha scritto nel messaggio
news:GeTkd.158368$b5.78...@news3.tin.it...

Interesannte, quindi il problema è già noto da un pò... si vede che essendo
nuovo cliente mi hanno fatto annusare i 10Mbit massimi e poi hanno deciso di
tagliare.
Cmq riflettendo meglio anche su quello che hai scritto te... la fibra serve
anche guardare la videostation, quindi immagina cosa succederebbe alla
nostra TV se nel frattempo si scaricassero un paio di file alla volta senza
limitazioni... Blocco della ricezione dello stream e telefono bloccato.
Forse all'utenza media conviene una scelta del genere, chissà.

 ha svolto il proprio compito in maniera più che soddisfacente.
Sono d'accordo, ma la tiritera dei controlli di default, quando è chiaro che
non servono a nulla si potrebbe evitare ogni volta che si chiama l'help
desk.
La trovo una inutile perdita di tempo, tutto qua.

 La trovo una inutile perdita di tempo, tutto qua.
Ciao,
io ho avuto "l'onore" di parlare piů volte con i tecnici che sono dietro al 
192193 (tutti con accento toscano), i quali mi hanno detto che secondo loro 
non ci sono problemi di sorta per gli sfigati come noi e che i loro router 
sono settati in maniera ottimale e che non ci sono limitazioni di sorta.
Pur tuttavia, non mi sono sembrati molto convincenti, anche volutamente.... 
;-)
Ciao
Enrico

 fastpage!
Quelli te li raccomando... Hanno chiamato l'altro giorno a casa mia 
tutti tronfi per chiedere se avevo risolto il problema... Ci ho pensato 
un pò su ed effettivamente circa 6 (dicansi SEI) mesi fa devo aver 
lamentato l'irraggiungibilità di un paio di siti attraverso la MFP.. ma 
ormai non mi ricordo più nemmeno quali e comunque non mi interessa più. 
Dovevano funzionare allora, non oggi! :-)
-- 
,.-°^MARCK^°-.,
Il Comune di Capraia considera i subacquei dannosi per l'ambiente:
http://www.liberisub.it
 -- My website: 
www.marck.tk

 ha scritto nel messaggio 
news:cn1pnt$ta4$1...@news.unina.it...

A questo punto è molto meglio un reclamo fatto da web,
ti eviti la tiritera e hai le stesse identiche possibilità di
risolvere il problema.
Quantomeno c'è qualcosa di scritto.. 

 (98) " visibile sugli hop 1-->9 glie ne sarei grato.
Ved. documentazione (linkata sopra) per pathchar = e' dovuto alla 
presenza di ICMP reply - time exceeded in seguito a variazione dell'IP
sorgente di risposta.
-- 
|Ż \/Ż | /Ż\ /Ż__/Ż__|-<|> * FAQ 2.0 ITGF it.tlc.gestori.fastweb <|
|Ż|\/|Ż|/Ż_Ż\|(__\__ \-<|> * URL  :  
http://plany.fasthosting.it
 <|
|_|  |_/_/ \_\___|___/-<|> * ----------------------------------- <|
|>- MagLev / Shanghai -<|> * URL  :  
http://www.maglev2004.cn
 ___<|

Macs... detto tra noi
Non ti pare strano che il flusso udp sia una bella retta costante fissa a
1200KBYTE/SEC
mentre quello tcp sia una sega con il primo dente che tocca i 600 e gli
altri solo i 150 ?
test da iperf.
Fatta la legge trovato l'inganno, non mi lamento piů, ma mi sto adoperando.

 test da iperf.
Senza informazioni sulle dimensioni TCP Window usate per le prove, puo'
non stupirmi ;) = variando la finestra con il parametro -w da 32k a 128k
si possono riscontrare notevoli differenze nei risultati su TCP.
Inoltre, per determinare le dimensioni ottimali TCP Window (da impostare
poi come RWIN del sistema) puo' essere utile l'effettuazione di test su
flussi paralleli con lo switch -P seguito dal numero di connessioni.
Ulteriori info nella documentazione iperf :
==
- 
http://dast.nlanr.net/Projects/Iperf/iperfdocs_1.7.0.html



Flussi paralleli ?
Bene, nelle connessioni tcp (ciò che avvalora la tesi che fastweb le limiti)
si ha un incremento
della velocità praticamente proporzionale al numero delle connessioni.
Per quanto riguarda l'udp, poco cambia invece.
Dai 1150K con 1 connessione (!!!!) si arriva a non + di 1220 con 3 o +
connessioni.
PS: la retta è sempre e comunque COSTANTE.
Non credo rimanga molto da dire... Fastweb mi limita la singola connessione
TCP al di fuori della sua rete a 1Mbit, punto.
Per curiosità macs, tu hai fibra o adsl ?
Nel caso di un'adsl >=2mbit non accusi gli stessi disagi ?
Mi sa che incapsulo tutto in udp e passo per l'ufficio...

 Per curiositŕ macs, tu hai fibra o adsl ?
Dove sono adesso non c'e' FastWeb, sebbene in ufficio usufruisca di una
connessione in fibra a 100Mbit, ma con qualche problema di latenza verso
l'esterno.


 tuo POP di appartenenza piuttosto che alla tua singola utenza.
Non credo sia un problema legato al pop o alla mia singola utenza,
immagino sia generalizzato a TUTTI gli utenti residenziali, I buisness si
mormora di no.
Questo perchè:
1- Ho un altro pc in casa fresco di installazione che ha i miei stessi
problemi,
2 - Ho chiesto ad un amico di bologna:"ma tu a quanto scarichi fuori dalla
rete ?"
"Non + di 100K/S" mi ha risposto.
3 - Ci sono altri vari messaggi sul NG anche da roma o milano che lamentano
lo stesso problema
Ad ogni modo ho anche immaginato il perchè FW adotti tale strategia.
Se solo si riuscisse a saturare la banda con una singola connessione si
avrebbero:
1- VS bloccata
2- Telefono muto
Comunque Posto i test, tutti con TCPWindow di 251Kbyte (Il miglior valore
che ho trovato)
C:\Documents and Settings\administrator>iperf -c 
iperf.wiscnet.net
 -i 1
------------------------------------------------------------
Client connecting to 
iperf.wiscnet.net
, TCP port 5001
TCP window size:  251 KByte (default)
------------------------------------------------------------
[656] local 39.7.31.90 port 1055 connected with 205.213.110.244 port 5001
[ ID] Interval       Transfer     Bandwidth
[656]  0.0- 1.0 sec   280 KBytes  2.29 Mbits/sec
[656]  1.0- 2.0 sec  32.0 KBytes   262 Kbits/sec
[656]  2.0- 3.0 sec  16.0 KBytes   131 Kbits/sec
[656]  3.0- 4.0 sec  8.00 KBytes  65.5 Kbits/sec
[656]  4.0- 5.0 sec  48.0 KBytes   393 Kbits/sec
[656]  5.0- 6.0 sec  88.0 KBytes   721 Kbits/sec
[656]  6.0- 7.0 sec   120 KBytes   983 Kbits/sec
[656]  7.0- 8.0 sec  24.0 KBytes   197 Kbits/sec
[656]  8.0- 9.0 sec   104 KBytes   852 Kbits/sec
[656]  9.0-10.0 sec  56.0 KBytes   459 Kbits/sec
[656]  0.0-17.6 sec   784 KBytes   364 Kbits/sec
Come si vede Parte a 2.29Mbit e poi scende rapidamente.
C:\Documents and Settings\administrator>iperf -c 
iperf.wiscnet.net
 -P 10
------------------------------------------------------------
Client connecting to 
iperf.wiscnet.net
, TCP port 5001
TCP window size:  251 KByte (default)
------------------------------------------------------------
[656] local 39.7.31.90 port 1062 connected with 205.213.110.244 port 5001
.
.
.
[480] local 39.7.31.90 port 1071 connected with 205.213.110.244 port 5001
[ ID] Interval       Transfer     Bandwidth
[640]  0.0-16.5 sec   648 KBytes   321 Kbits/sec
[580]  0.0-17.1 sec   976 KBytes   467 Kbits/sec
[500]  0.0-17.8 sec  1.74 MBytes   821 Kbits/sec
[620]  0.0-17.8 sec  2.05 MBytes   964 Kbits/sec
[480]  0.0-17.9 sec   712 KBytes   325 Kbits/sec
[656]  0.0-18.7 sec   752 KBytes   330 Kbits/sec
[540]  0.0-19.0 sec  1.32 MBytes   584 Kbits/sec
[600]  0.0-19.4 sec  1.05 MBytes   452 Kbits/sec
[560]  0.0-19.9 sec   992 KBytes   408 Kbits/sec
[520]  0.0-24.2 sec   512 KBytes   174 Kbits/sec
[SUM]  0.0-24.2 sec  10.6 MBytes  3.70 Mbits/sec
La somma delle 10 connessioni adesso è 3.7Mbit/sec, con questo server
l'aumento non è proporzionale, cmq da 1Mbit a 3,70 è un bel passo.
Adesso passo ai test UDP:
C:\Documents and Settings\administrator>iperf -u -c 
iperf.wiscnet.net
 -b
100m -i
 1
------------------------------------------------------------
Client connecting to 
iperf.wiscnet.net
, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  251 KByte (default)
------------------------------------------------------------
[656] local 39.7.31.90 port 1080 connected with 205.213.110.244 port 5001
[ ID] Interval       Transfer     Bandwidth
[656]  0.0- 1.0 sec  1.08 MBytes  9.09 Mbits/sec
[656]  1.0- 2.0 sec  1.08 MBytes  9.08 Mbits/sec
[656]  2.0- 3.0 sec  1.08 MBytes  9.03 Mbits/sec
[656]  3.0- 4.0 sec  1.08 MBytes  9.09 Mbits/sec
[656]  4.0- 5.0 sec  1.08 MBytes  9.08 Mbits/sec
[656]  5.0- 6.0 sec  1.08 MBytes  9.03 Mbits/sec
[656]  6.0- 7.0 sec  1.08 MBytes  9.09 Mbits/sec
[656]  7.0- 8.0 sec  1.08 MBytes  9.07 Mbits/sec
[656]  8.0- 9.0 sec  1.08 MBytes  9.04 Mbits/sec
[656]  9.0-10.0 sec  1.08 MBytes  9.08 Mbits/sec
[656]  0.0-10.0 sec  10.8 MBytes  9.06 Mbits/sec
read failed: Connection reset by peer
9Mbit/sec.
Udp in parallelo con -P 10
[SUM]  2.0- 3.0 sec  1.13 MBytes  9.50 Mbits/sec
 ...come dicevo è un incremento + che marginale.
http://netspeed.stanford.edu/
 :
TCP/Web100 Network Diagnostic Tool v5.2.1e
click START to begin
Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
running 10s outbound test (client to server) . . . . . 844.14Kb/s
running 10s inbound test (server to client) . . . . . . 133.73kb/s
The slowest link in the end-to-end path is a 10 Mbps Ethernet subnet
Information: Other network traffic is congesting the link
click START to re-test
...Uno schifo !
Posto anche 3 immagini riferite rispettivamente a:
- Un file scaricato normalmente (c'è da dire che oggi viaggiavo ad una media
di 1,2Mbit invece che uno).
http://usera.imagecave.com/kokoko3k/Ftp.jpg
- La connessione di iperf TCP
http://usera.imagecave.com/kokoko3k/Tcp.jpg
- La connessione di iperf UDP
http://usera.imagecave.com/kokoko3k/Udp.jpg
Se serve altro, sono a disposizione.
PS: Napoli (Zona Vomero) Fibra.

 Se serve altro, sono a disposizione.
Fammi sapere, che io intanto raccolgo altri dati -> in merito sono
invitati anche gli altri utenti del newsgroup, dato che la questione
dovrebbe interessare anche alcuni di loro.


Ecco il risultato dei test:
C:\Documents and Settings\administrator>iperf -c 
iperf.wiscnet.net
 -w 128k
------------------------------------------------------------
Client connecting to 
iperf.wiscnet.net
, TCP port 5001
TCP window size:  128 KByte
------------------------------------------------------------
[656] local 39.7.31.90 port 1034 connected with 205.213.110.244 port 5001
[ ID] Interval       Transfer     Bandwidth
[656]  0.0-11.4 sec  1.69 MBytes  1.25 Mbits/sec
C:\Documents and Settings\administrator>iperf -c 
netspeed.stanford.edu
 -w
128k
------------------------------------------------------------
Client connecting to 
netspeed.stanford.edu
, TCP port 5001
TCP window size:  128 KByte
------------------------------------------------------------
[652] local 39.7.31.90 port 1037 connected with 171.66.6.36 port 5001
[ ID] Interval       Transfer     Bandwidth
[652]  0.0-12.2 sec   464 KBytes   311 Kbits/sec
C:\Documents and Settings\administrator>iperf -c 
iperf.wiscnet.net
 -w
128k -P 4
------------------------------------------------------------
Client connecting to 
iperf.wiscnet.net
, TCP port 5001
TCP window size:  128 KByte
------------------------------------------------------------
[656] local 39.7.31.90 port 1038 connected with 205.213.110.244 port 5001
[640] local 39.7.31.90 port 1039 connected with 205.213.110.244 port 5001
[620] local 39.7.31.90 port 1040 connected with 205.213.110.244 port 5001
[600] local 39.7.31.90 port 1041 connected with 205.213.110.244 port 5001
[ ID] Interval       Transfer     Bandwidth
[656]  0.0-11.4 sec   736 KBytes   528 Kbits/sec
[600]  0.0-13.9 sec  1.95 MBytes  1.17 Mbits/sec
[640]  0.0-14.0 sec  1.34 MBytes   807 Kbits/sec
[620]  0.0-17.7 sec  1.05 MBytes   495 Kbits/sec
[SUM]  0.0-17.7 sec  5.05 MBytes  2.39 Mbits/sec
C:\Documents and Settings\administrator>iperf -c 
netspeed.stanford.edu
 -w
128k -
P 4
------------------------------------------------------------
Client connecting to 
netspeed.stanford.edu
, TCP port 5001
TCP window size:  128 KByte
------------------------------------------------------------
[656] local 39.7.31.90 port 1042 connected with 171.66.6.36 port 5001
[640] local 39.7.31.90 port 1043 connected with 171.66.6.36 port 5001
[620] local 39.7.31.90 port 1044 connected with 171.66.6.36 port 5001
[600] local 39.7.31.90 port 1045 connected with 171.66.6.36 port 5001
[ ID] Interval       Transfer     Bandwidth
[656]  0.0-13.8 sec   568 KBytes   338 Kbits/sec
[640]  0.0-16.7 sec   464 KBytes   228 Kbits/sec
[620]  0.0-16.7 sec   384 KBytes   189 Kbits/sec
[600]  0.0-16.7 sec  1.03 MBytes   519 Kbits/sec
[SUM]  0.0-16.7 sec  2.41 MBytes  1.21 Mbits/sec
C:\Documents and Settings\administrator>iperf -c 
iperf.wiscnet.net
 -u -b
10m -l
32k -w 128k
------------------------------------------------------------
Client connecting to 
iperf.wiscnet.net
, UDP port 5001
Sending 32768 byte datagrams
UDP buffer size:  128 KByte
------------------------------------------------------------
[656] local 39.7.31.90 port 1047 connected with 205.213.110.244 port 5001
[ ID] Interval       Transfer     Bandwidth
[656]  0.0-10.0 sec  10.9 MBytes  9.12 Mbits/sec
read failed: Connection reset by peer
C:\Documents and Settings\administrator>iperf -c 
netspeed.stanford.edu
 -u -b
10m
 -l 32k -w 128k
------------------------------------------------------------
Client connecting to 
netspeed.stanford.edu
, UDP port 5001
Sending 32768 byte datagrams
UDP buffer size:  128 KByte
------------------------------------------------------------
[656] local 39.7.31.90 port 1048 connected with 171.66.6.36 port 5001
[ ID] Interval       Transfer     Bandwidth
[656]  0.0-10.0 sec  10.9 MBytes  9.12 Mbits/sec
[656] WARNING: did not receive ack of last datagram after 10 tries.
[656] Sent 349 datagrams
...Il telefono metre testo l'udp non funziona
Vlc in stream si blocca, policy Qos, prioritizzazioni e reti overlay
apposite sembrano non servire a nulla.

 apposite sembrano non servire a nulla.
Strano il discorso del telefono mentre fai il test su UDP -> ti fa lo
stesso abbassando -b da 10m a 5m ? Per quanto riguarda invece il fatto
che si blocchi VLC in corrispondenza del test UDP di iperf e' normale.


 Migliora, ma speravo in un valore doppio -> a questo punto ti chiedo
E pensare che, UDP a parte, io non arrivo neppure a quei valori, questo 
indipendentemente dal PC in uso (Linux o Windows). Ovviamente sono in fibra.
-- 
Formerly known as Loric

 stesso abbassando -b da 10m a 5m ?
No.
Ecco i test:
http://plany.fasthosting.it/test/speedtest.html
752KB/Sec
http://meter.mclink.it/applet.html
D:1713Kbps
U:4133Kbps
http://help.virgilio.it/velox/
1805Kbps
http://digilander.libero.it/pabasoftware/speedtest/
6713kbps
Web100:
http://miranda.ctd.anl.gov:7123/
Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
running 10s outbound test (client to server) . . . . . 656.79Kb/s
running 10s inbound test (server to client) . . . . . . 716.79kb/s
The slowest link in the end-to-end path is a 10 Mbps Ethernet subnet
Information: Other network traffic is congesting the link
Dettagli:
bw = 0.72 based on packet size = 10Kbits, RTT = 224.54msec, and loss =
0.004137931034482759
The theoretical network limit is 0.72 Mbps
The transmit buffer (63.0 KByte) limits the application to 2.22 Mbps
Your receive buffer (250.0 KByte) limits the application to 8.73 Mbps
The network based flow control limits the application to 4.17 Mbps
Client Data reports link is 'Ethernet', Client Acks report link is
'Ethernet'
Server Data reports link is 'OC-12', Server Acks report link is 'T1'
C'è da dire che da quando ho chiamato di nuovo oggi ed ho parlato conn
qualcuno che ne capisse un minimo ho notato un aumento nella prestazione del
90% (120K->220K) o è solo un caso.
Ad ogni modo spero che i dati possano esserti utili.
Cosa ne deduci ?

 Cosa ne deduci ?
Che c'e' qualcosa che non va, ma non si tratta di una policy generale. 
Cio' e' confermato dai risultati raccolti da altri utenti -> ti allego
sotto per esempio la tabella di una prova effettuata un'ora dopo il tuo
post da un'utenza su fibra della MAN di Milano (dati in Kbit/s) :
==
FastHosting : 8196
Libero/Wind : 7352
Tin/IB      : 5543
Mc-Link     : 5812 (upload 3026)
Il mio suggerimento e' quello di riprovare un'altra volta i 4 tester 
indicati sopra, eventualmente variando RWIN a 128KB e Tcp1323opts a 3.
Se la situazione non dovesse variare, avresti sufficiente materiale per
spedire un report all'assistenza tecnica FastWeb e chiedere un controllo
sulla tua utenza, assodato che a quel punto avresti fatto tutte le
possibili verifiche/ottimizzazioni sui tuoi computer. 


 indicati sopra, eventualmente variando RWIN a 128KB e Tcp1323opts a 3.
Interessante,, credevo che Tcp1323opts potesse assumere solo valori 0 o 1
(scalabile o meno)...
cosa implica impostare il parametro a 3 ?

 
No, se è una questione commerciale che lo dicano : qua è cosi' tagliamo 
la banda..
  Ti va bene ok ? Non ve bene ? Disdici e vattene
Non negare tutto ogni volta che si tocca l'argomento della banda sul NAT 
e come viene gestita


Mi scuso, ho errato a fare il test, rimangio tutto, però mi sorge una
domanda:
Perchè se do:
iperf -u -c host -i 1 -b 10m (10megabit) la punta massima è 6Mbit
mentre con -b 100m si raggiungono i 9 ?

 
Uhm, strano:
H:\>iperf -c 
iperf.wiscnet.net
 -u -b 10m -l 32k -w 128k
------------------------------------------------------------
Client connecting to 
iperf.wiscnet.net
, UDP port 5001
Sending 32768 byte datagrams
UDP buffer size:  128 KByte
------------------------------------------------------------
[1908] local 192.168.1.2 port 1402 connected with 205.213.110.244 port 5001
[ ID] Interval       Transfer     Bandwidth
[1908]  0.0-10.0 sec  12.0 MBytes  10.0 Mbits/sec
read failed: Connection reset by peer


 mentre con -b 100m si raggiungono i 9 ?
Questo succede perche' c'e' un limite di convergenza nell'ottimizzazione
dei datagrammi UDP -> lo scopo del test UDP e' in realta' quello di
definire l'UDP Datagram size in funzione della banda utilizzata e della
dimensione dei pacchetti utilizzati.
Il test UDP torna utile per esempio quando si vuole mettere in piedi una
connessione su UDP Encapsulation (ved. VPN), riservandole una precisa 
porzione di banda.


Sei un pozzo di scienze, tnx ;)
A proposito di vpn (in caso affermativo se ti va apro un thread), hai
esperienza con cipe con client e server lato windows ?
vorrei provare a vedere cosa succede se incapsulo in udp ed accedo ad una
lan all'uni.

 una lan all'uni.
Ti confermo il funzionamento di CIPE dietro al NAT dinamico delle
connessioni base FastWeb su CPE -> se ti servono alcune indicazioni 
sulla configurazione prova a guardare questo topic sul forum di
fastwebnet.org
 :
==
- 
http://www.forum.fastwebnet.org/viewtopic.php?t=865


 ==
Si, mi ci ero già imbattuto, ma purtroppo si parla solo del lato
client (su windows)
a me entrambi gli endpoint sono win32.