Newsgroup: it.tlc.provider
Titolo: Nuovo Provider a ROVIGO!

E' attivo un nuovo Provider Internet nella Provincia di Rovigo.
BORASO Internet Provider del Gruppo BORASO offre connettività internet
tramite rete infostrada ad alta velocità
per informazioni: 0425.760112  
in...@boraso.it

tramite rete infostrada ad alta velocità
Se ci diceste quale e' la velocita' delle vostre linee, chi e' il carrier e
quanti sono i modem vi fareste una pubblicita' migliore.
Davide Marcato.
----------------------------------------------------
| -- Freelance International Consultant
| -- Win32/MFC/COM Development & Training
| -- Technical Writer & Speaker
----------------------------------------------------
| -- Email: 
mar...@programmers.net
| -- Web: 
http://www.DavideMarcato.com
----------------------------------------------------

 per informazioni: 0425.760112  
in...@boraso.it

[151.99.49.66]
[CUT]
Il rallentamento sembra (ripeto: SEMBRA) avvenire tra due host della
rete Interbusiness... Indi sembra un problema di saturazione interno
alla rete di Telecom, anche se un singolo trace non e' sufficiente per
fornire risposte sensate...
Ciao
Luca
--
Luca Bruschi - 
I.NET
 S.p.A.
lucky[@]
Eru.INET.it
Togliere le parentesi [] per rispondere.

 writes:
|> azzo che velocità!!! e' peggio di un diesel !!!!!!!!!!
Pavesi lei mi delude!!!! Ma come fa a non accogersi di dov'e' il vero tappo?
|> C:\WINDOWS>tracert 
www.boraso.it
|> Tracing route to 
mail.boraso.it
 [192.106.127.3]
|>   1     3 ms     3 ms     3 ms  195.31.197.1
|>   2    89 ms    80 ms    37 ms  
r-no1-servitel.interbusiness.it
|> [151.99.120.13]
|>   3    40 ms    39 ms    40 ms  
r-to2-no1-b.interbusiness.it
|> [151.99.114.5]
|>   4    45 ms   100 ms    50 ms  
r-to4-fddi.interbusiness.it
 [151.99.5.4]
|>   5    42 ms    42 ms    65 ms  
r-mi7-to4-atm.interbusiness.it
|> [151.99.101.25]
|>   6    43 ms    43 ms    42 ms  
r-mi16-fe4.interbusiness.it
 [151.99.5.203]
|>   7   537 ms   851 ms  1103 ms  
r-nap4-mi16.interbusiness.it
|> [151.99.49.66]
Eccolo qui! Il router di Interbusiness che va sul MIX dell'AIIP.
|>   8   661 ms   412 ms   440 ms  
infostrada.mix.aiip.it
 [194.177.110.9]
|>   9     *      493 ms   724 ms  192.94.212.73
|>  10   638 ms   583 ms   667 ms  195.45.60.26
|>  11   598 ms   555 ms   644 ms  
mail.boraso.it
 [192.106.127.3]
Il resto dipende solo ed esclusivamente alla qualita' delle linee Telecom Italia
attestate al MIX, linee che tutti quanti sappiamo essere piu' che sature.
Best regards,
ivan
---
+==============================================================+
| Ivan Pintori - Security Engineer - UUNET WorldCom            |
| 332 The Science Park, Cambridge, England, CB4 4BZ            |
| Email: 
Ivan.P...@uk.uu.net
      WWW: 
http://www.uk.uu.net
 |
| Voice: 
+44-(0)1223-250100
          Fax: 
+44-(0)1223-250101
   |
+==============================================================+
 Le opinioni espresse sono le mie e non quelle dell'azienda
 All opinions are my own and not those of the company
PGP fingerprint =  8438 AB1C 985E BF8C  FBC2 7C72 064F 5E59  9FC6 0217

azzo che velocità!!! e' peggio di un diesel !!!!!!!!!!
Intervengo nuovamente, non perché me ne importi alcunché del provider
di Rovigo, né per accanirmi contro Roberto Pavesi che non ho la
fortuna di conoscere, ma solo perché magari a qualcuno interessa
vedere come in pochi minuti si possa fare una analisi abbastanza
precisa della velocità di connessione di un provider...
Prova eseguita intorno alle 18.30, indi in un momento di traffico
generale sulla rete abbastanza elevato.
Primo tentativo: ping con pacchetti "grossi" (1508 bytes).
Risultato:
----
mail.boraso.it
 PING Statistics----
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max = 518/538/640 ms
Tempo di risposta medio, ma packet loss nullo, il che è un ottimo
segno.
Ping con pacchetti "standard" (64 bytes):
----
mail.boraso.it
 PING Statistics----
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max = 64/275/408 ms
Tempo di risposta non entusiasmante, ma sempre 0% di paket loss...
probabilmente la banda non è eccessiva ma sicuramente le linee non
sono sature.
Traceroute:
traceroute to 
mail.boraso.it
 (192.106.127.3)
 1  
gw-mi-hotsb1.inet.it
 (194.20.8.21)  4 ms  2 ms  1 ms
 2  
fe0.gwi-mi.inet.it
 (194.185.7.252)  4 ms  3 ms  3 ms
 3  
infostrada.mix.aiip.it
 (194.177.110.9)  3 ms  4 ms  6 ms
 4  192.94.212.73 (192.94.212.73)  29 ms  21 ms  26 ms
 5  195.45.60.26 (195.45.60.26)  294 ms  282 ms  290 ms
 6  192.106.127.3 (192.106.127.3)  307 ms  312 ms  286 ms
Il rallentamento si ha tra gli hop 4 e 5. Il quinto host
(195.45.60.26) presumibilmente è il router che gestisce la CDN.
Possibile conclusione: il provider Boraso ha una linea a velocità
media (potrebbe essere una 128 Kbps, ma questa è MOLTO sparata a caso,
dipende da quanti client ci stanno lavorando sopra, insomma senza
altri dati in mano è un casino, ma ormai la ho scritta e non ho voglia
di cancellare :))) ), non satura. Infostrada ha al momento un buon
backbone nazionale.
Ripeto: io lavoro presso un provider ma questo mio intervento è
puramente speculativo... Non conosco Roberto Pavesi, a Rovigo ci sono
stato solo qualche volta ed ho peraltro ascoltato un bellissimo
concerto dei Solisti Veneti (non c'entra nulla, lo so, ma tanto per
dire che non ho nulla contro la città :)))) ), la mia mail non vuole
dimostrare nulla né a favore né contro nessuno. E' solo un esempio di
come si può condurre una SEMPLICISSIMA "indagine" sul funzionamento di
un provider, indagine che certamente porta a risultati comunque
opinabili.
Piccola nota: per me l'indagine era semplice perché ho un link diretto
con Infostrada; per chi ha diversa connettività una analisi del genere
potrebbe essere un po' più complessa e portare a risultati meno
chiari. Per intendersi: più "passi" compie il traceroute, più è
difficile quali linee hanno capacità adeguata e quali no.


Aggiungo al buon Lucky, che tanto mi e' simpatico :)))
On 9 Sep 1998, it was written:
Lucky>Primo tentativo: ping con pacchetti "grossi" (1508 bytes).
Lucky>Risultato:
Lucky>----
mail.boraso.it
 PING Statistics----
Lucky>100 packets transmitted, 100 packets received, 0% packet loss
Lucky>round-trip min/avg/max = 518/538/640 ms
ore 20:00 italiane, stesso size:
----
mail.boraso.it
 PING Statistics----
100 packets transmitted, 91 packets received, 9% packet loss
round-trip (ms)  min/avg/max = 542/640/1326
Tenete conto che e' fatto dall'inghilterra. 9% di loss va benissimo e i
tempi sono giusti per un pacchetto di 1508
Lucky>Ping con pacchetti "standard" (64 bytes):
Lucky>----
mail.boraso.it
 PING Statistics----
Lucky>100 packets transmitted, 100 packets received, 0% packet loss
Lucky>round-trip min/avg/max = 64/275/408 ms
Ora italiana 20:10, stesso size:
----
mail.boraso.it
 PING Statistics----
100 packets transmitted, 95 packets received, 5% packet loss
round-trip (ms)  min/avg/max = 82/127/218
C'e' un po' di perdita di pacchetti, ma in compenso i tempi sono ottimi
per un pacchetto da 64 bytes.
Lucky>Traceroute:
Lucky>
Lucky>traceroute to 
mail.boraso.it
 (192.106.127.3)
Lucky> 1  
gw-mi-hotsb1.inet.it
 (194.20.8.21)  4 ms  2 ms  1 ms
Lucky> 2  
fe0.gwi-mi.inet.it
 (194.185.7.252)  4 ms  3 ms  3 ms
Lucky> 3  
infostrada.mix.aiip.it
 (194.177.110.9)  3 ms  4 ms  6 ms
Lucky> 4  192.94.212.73 (192.94.212.73)  29 ms  21 ms  26 ms
Lucky> 5  195.45.60.26 (195.45.60.26)  294 ms  282 ms  290 ms
Lucky> 6  192.106.127.3 (192.106.127.3)  307 ms  312 ms  286 ms
traceroute to 
mail.boraso.it
 (192.106.127.3), 30 hops max, 40 byte packets
 1  
fe0-1-0.cr1.cambridge.pipex.net
 (158.43.128.192)  1.66 ms  0.923 ms 
0.843 ms
 2  
fe1-1-0.cr2.cambridge.pipex.net
 (158.43.254.74)  1.125 ms  1.275 ms 
1.072 ms
 3  
pos4-0-0.cr2.doc.london.pipex.net
 (158.43.254.2)  3.413 ms  3.153 ms 
3.574 ms
 4  
fe0-0-0.br1.doc.london.pipex.net
 (158.43.195.3)  4.167 ms  4.044 ms 
4.824 ms
 5  
POS1-0-0.GW1.LND1.Alter.Net
 (146.188.5.41)  3.832 ms  4.909 ms  4.847 
ms
 6  
321.ATM0-0-0.CR1.LND1.Alter.Net
 (146.188.2.169)  4.808 ms  4.042 ms 
4.733 ms
 7  
267.Hssi6-0.CR1.MLN2.Alter.Net
 (146.188.5.246)  26.123 ms  26.838 ms 
25.185 ms
 8  
Fddi0-0.GW1.MLN2.Alter.Net
 (146.188.31.35)  33.942 ms  25.79 ms 34.251
ms
 9  146.188.32.46 (146.188.32.46)  90.168 ms  97.057 ms  79.949 ms
10  
gw1-ii.iunet.it
 (192.106.7.130)  45.423 ms  29.543 ms  29.928 ms
11  195.45.60.26 (195.45.60.26)  96.887 ms  96.206 ms  92.143 ms
12  192.106.127.3 (192.106.127.3)  116.362 ms  83.344 ms  88.24 ms
Come potete vedere dalla UUNET in inghilterra (uno dei punti di uscita per
l'estero della Infostrada) il traffico e' regolare fino al provider, ed il
che e' ottimo: Vuol dire che Infostrada non e' satura, ne e' saturo il
provider in questione.
Per concludere, a volte le cose vanno male non tanto per colpa del
provider a cui ci si collega, ma per colpa dell'altro capo della catena.
In questo caso non mi sembra che le prestazioni del provider di Rovigo
siano negative, anzi, tutt'altro!


 della catena.
Sai: mi sento un po' preso in giro. :-(
-- 
Ciao da Villo   (PGP 2.6.3i key available)
Address *PRIMARIO*: Luca Villani, 2:332/403.71  su Fidonet
AKA:    
villo+...@tuttocitta.it
AKA: 
lvillan...@geocities.com
AKA:   
lucavi...@usa.net
(Per rispondere via e-mail togliere +nospam da ogni address)
(To reply via e-mail remove +nospam in all address)

>======================  FINE  ======================<
Mi pare che questo trace "parta" già abbastanza lento... Temo che la
saturazione fosse sulla tua linea :) Una prova da fare sarebbe pingare
con pacchetti da 1500 bytes tutti gli host del trace uin successione,
per vedere dove inizia il degrado delle prestazioni; in questo modo
individui la tratta satura. Se da lì in poi le prestazioni rimangono
"costantemente degradate", ovvero non sono buone ma non peggiorano
nemmeno, significa quantomeno che non ci sono tratte successive messe
peggio :)


 tutti gli host del trace uin successione,
Questa sera la eseguo, ma mi immagino gia` i risultati.


======================  FINE  ======================<
A questo punto e` superfluo farne altri. :-(
Diciamo che dal pop di Ferrara la situazione e` pessima: non ci
sono packet loss, certo, ma questi valori di ping mi sembrano un
po' troppo alti, per essere sulla rete interna infostrada. :-(((


dire di IOL stessa. :-|
Il dubbio che andassi su commutata mi č venuto dopo aver postato la
risposta :) Nelle valutazioni di traffico tieni presente che un modem
28.8 / 33.6 introduce tra i 150 e i 200 ms di "ritardo" sistematico,
quindi il traceroute riportato non č poi cosě malvagio... prova a
"pingare" sistematicamente il tuo gateway e vedi cosa succede; questo
ti dŕ un parametro sul funzionamento del tuo modem.


po' troppo alti, per essere sulla rete interna infostrada. :-(((
Scusa ma devo correggerti: mi pare che tu abbia pingato l'Access
Server cui sei collegato... In pratica hai testato l'efficenza del tuo
modem e della linea telefonica... In questo IOL non c'entra :)


modem e della linea telefonica... In questo IOL non c'entra :)
E' pressoche' impossibile che abbia un ping da quasi un secondo con il suo
access server diretto, dai :-)
Secondo me prima di arrivare a quella destinazione passa per qualche altra
linea...


linea...
In questo caso ha tagliato un pezzo del traceroute :) Comunque non ho
idea di come reagisca un modem a un ping con pacchetti da 1500 bytes,
non ci ho mai provato e al momento non ho un modem sottomano; con
pacchetti "classici" da 64 bytes ho sempre visto risposte comprese tra
i 150 e i 250 ms. Visto che il primo hop del traceroute riportava
tempi dell'ordine dei 200 ms, mi pare che abbia un modem lento (e/o
una linea telefonica trucida), ma questo non si può imputare al
provider... Tutto qui :)


provider... Tutto qui :)
Io con una CDF a 26400 bps arrivavo all'access server in 130-135 ms!


A questo punto e` superfluo farne altri. :-(
Ma con pacchetti di 1500 byte (circa 15.000 bit) ed un modem a 14.400 b/s e
compressione inserita(?) cosa ti aspettavi? Prova con il pacchetto standard
(~50 byte) vedrai che ritroverai i 200 ms.
Vai tranquillo che e' tutto regolare, almeno fino lě.
PS - Avro' detto una cavolata?
Ciao.
Orion 

 qualche altra linea...
A questo punto, non lo so piu`... :-(


 linea...
Invece e' estremamente plausibile.
Conta 100ms di round trip dovuti ad algoritmi di compressione/ecc e delay della
linea. Aggiungi che per trasferire 1500 bytes a 33600 bps ci vogliono 350 ms,
fai le somme e vedrai che 800ms sono piu' che normali.
Ciao.
-- 
 Daniele
-------------------------------------------------------------------------------
Your job is being a professor and researcher: That's one hell of a good excuse
for some of the brain-damages of minix.
(Linus Torvalds to Andrew Tanenbaum)
-------------------------------------------------------------------------------
 Se telecom italia aggiungesse uno scatto al giorno ad ogni abbonato, dal
 primo Gennaio avrebbe rubato 809.988.000.000 Lire.
-------------------------------------------------------------------------------
 Daniele Orlandi - Utility Line Italia - 
http://www.orlandi.com
 Via Mezzera 29/A - 20030 - Seveso (MI) - Italy
-------------------------------------------------------------------------------

fai le somme e vedrai che 800ms sono piu' che normali.
Mah...ho appena provato (20.26, ora trafficata), 33600 bps, e pur usando un
nodo virtuale Infostrada (che rallenta l'accesso, come dicevo) un ping da
1500 bytes impiega 600-700 ms. Mi sembra strano il valore di 1000 ms senza
reti virtuali di mezzo!
Comunque potresti anche avere ragione, io mi baso solo sulle mie
rilevazioni dirette.


 reti virtuali di mezzo!
Erano 800ms e con un 14.400 :^)
Ciao!
-- 
 Daniele
-------------------------------------------------------------------------------
Why use Windows, since there is a door?
(By 
fac...@galileo.rhein-neckar.de
, Andre Fachat)
-------------------------------------------------------------------------------
 Se telecom italia aggiungesse uno scatto al giorno ad ogni abbonato, dal
 primo Gennaio avrebbe rubato 817.794.000.000 Lire.


Erano 800ms e con un 14.400 :^)
Hai ragione, era un 14.400! Allora si', tutto torna :-))
