Apr=E8s les diff=E9rentes batailles que se sont livr=E9s les internautes =
pour=20
obtenir de meilleurs pings (notamment le site Low Ping Wanted) avec=20
leurs connexions ADSL, les FAI se devaient de r=E9agir. Le combat semble =
porter ses fruits car depuis plusieurs semaines, les FAI mettent =E0=20
l'=E9tude une option permettant de r=E9duire les pings.
Un tel proc=E9d=E9 permet bien s=FBr d'obtenir un meilleur confort dans l=
es=20
jeux on-line mais qui peut aussi s'av=E9rer utile par la navigation sur=20
Internet, le temps d'acc=E8s au service pouvant =EAtre r=E9duit. Cette op=
tion=20
se pr=E9senterait sous la forme d'un service qui d=E9sactiverait le mode =
"Fastpath", service de contr=F4le des erreurs activ=E9 par d=E9faut sur l=
a=20
quasi totalit=E9 des offres ADSL. Il peut en effet arriver que les donn=E9=
es=20
soient l=E9g=E8rement alt=E9r=E9es entre le d=E9part (central ou Dslams) =
et votre=20
PC. Ce ph=E9nom=E8ne s'av=E8re augmenter plus vous vous trouvez =E9loign=E9=
s du=20
central.
Malheureusement, ce service qui int=E9resse bon nombre d'internautes sera=
=20
payant : =E0 l'heure actuelle, on parle de 3 =E0 5 EUR par mois selon les=
=20
FAI qui =E9tudient cette option. Quand on sait que Free propose cette=20
option depuis d=E9j=E0 quelques mois sans surtaxe, on se demande pourquoi=
il=20
faudrait payer un tel prix. Il ne reste plus qu'=E0 attendre les=20
d=E9lib=E9rations finales des FAI incrimin=E9s.
Outre ceci, nous tenions =E0 vous informer que la mise =E0 jour des Dslam=
s=20
de type Alcatel =E9tait cens=E9e intervenir actuellement. Celle-ci devait=
=20
permettre de passer du mode "Interleave High" =E0 "Interleave Medium",=20
soit une diminution sensible du ping (environ 10-20ms, soit 50ms sous=20
dos) ; cependant, ce changement de mode ne permettra pas d'obtenir un=20
gain =E9quivalent =E0 la d=E9sactivation totale du FastPath. Quoiqu'il en=
=20
soit, suite =E0 quelques probl=E8mes, cette mise =E0 jour a =E9t=E9 repou=
ss=E9e =E0 la=20
premi=E8re quinzaine d'octobre. Nous ne manquerons pas de vous tenir=20
inform=E9s de la suite des =E9v=E8nements.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Martin Lafaix
manali (fo) wrote:
Quand on sait que Free propose cette option
C'est faux. En zone dégroupée, free utilise *aussi* l'interleaved. Cela donne certes du 20-30ms comme ping, mais ce n'est *pas* du fastpath. -- Martin Lafaix Team OS/2 http://lafaix.online.fr
manali (fo) wrote:
Quand on sait que Free propose cette
option
C'est faux. En zone dégroupée, free utilise *aussi* l'interleaved.
Cela donne certes du 20-30ms comme ping, mais ce n'est *pas* du fastpath.
--
Martin Lafaix <lafaix@online.fr>
Team OS/2
http://lafaix.online.fr
C'est faux. En zone dégroupée, free utilise *aussi* l'interleaved. Cela donne certes du 20-30ms comme ping, mais ce n'est *pas* du fastpath. -- Martin Lafaix Team OS/2 http://lafaix.online.fr
Valoche
gain équivalent à la désactivation totale du FastPath. Quoiqu'il en
Bah en fait il faut désactiver l'interleave pour être en fastpath ;-) Mébon...
Valoche
gain équivalent à la désactivation totale du FastPath. Quoiqu'il en
Bah en fait il faut désactiver l'interleave pour être en fastpath ;-)
Mébon...
gain équivalent à la désactivation totale du FastPath. Quoiqu'il en
Bah en fait il faut désactiver l'interleave pour être en fastpath ;-) Mébon...
Valoche
olafkewl
On Wed, 17 Sep 2003 09:55:49 +0200, "manali (fo)" wrote:
Après les différentes batailles que se sont livrés les internautes pour obtenir de meilleurs pings (notamment le site Low Ping Wanted) avec leurs connexions ADSL, les FAI se devaient de réagir. Le combat semble porter ses fruits car depuis plusieurs semaines, les FAI mettent à l'étude une option permettant de réduire les pings.
[...] ping -c 5 213.36.80.1 PING 213.36.80.1 (213.36.80.1) 56(84) bytes of data. 64 bytes from 213.36.80.1: icmp_seq=1 ttl$5 time$.0 ms 64 bytes from 213.36.80.1: icmp_seq=2 ttl$5 time .4 ms 64 bytes from 213.36.80.1: icmp_seq=3 ttl$5 time.7 ms 64 bytes from 213.36.80.1: icmp_seq=4 ttl$5 time".7 ms 64 bytes from 213.36.80.1: icmp_seq=5 ttl$5 time!.1 ms
--- 213.36.80.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4021ms rtt min/avg/max/mdev = 19.729/21.649/24.092/1.595 ms
depuis une cnx degroupée free (qd elle veut bien marcher) sur le dns de tiscali
Après les différentes batailles que se sont livrés les internautes pour
obtenir de meilleurs pings (notamment le site Low Ping Wanted) avec
leurs connexions ADSL, les FAI se devaient de réagir. Le combat semble
porter ses fruits car depuis plusieurs semaines, les FAI mettent à
l'étude une option permettant de réduire les pings.
[...]
ping -c 5 213.36.80.1
PING 213.36.80.1 (213.36.80.1) 56(84) bytes of data.
64 bytes from 213.36.80.1: icmp_seq=1 ttl$5 time$.0 ms
64 bytes from 213.36.80.1: icmp_seq=2 ttl$5 time .4 ms
64 bytes from 213.36.80.1: icmp_seq=3 ttl$5 time.7 ms
64 bytes from 213.36.80.1: icmp_seq=4 ttl$5 time".7 ms
64 bytes from 213.36.80.1: icmp_seq=5 ttl$5 time!.1 ms
--- 213.36.80.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4021ms
rtt min/avg/max/mdev = 19.729/21.649/24.092/1.595 ms
depuis une cnx degroupée free (qd elle veut bien marcher) sur le dns
de tiscali
On Wed, 17 Sep 2003 09:55:49 +0200, "manali (fo)" wrote:
Après les différentes batailles que se sont livrés les internautes pour obtenir de meilleurs pings (notamment le site Low Ping Wanted) avec leurs connexions ADSL, les FAI se devaient de réagir. Le combat semble porter ses fruits car depuis plusieurs semaines, les FAI mettent à l'étude une option permettant de réduire les pings.
[...] ping -c 5 213.36.80.1 PING 213.36.80.1 (213.36.80.1) 56(84) bytes of data. 64 bytes from 213.36.80.1: icmp_seq=1 ttl$5 time$.0 ms 64 bytes from 213.36.80.1: icmp_seq=2 ttl$5 time .4 ms 64 bytes from 213.36.80.1: icmp_seq=3 ttl$5 time.7 ms 64 bytes from 213.36.80.1: icmp_seq=4 ttl$5 time".7 ms 64 bytes from 213.36.80.1: icmp_seq=5 ttl$5 time!.1 ms
--- 213.36.80.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4021ms rtt min/avg/max/mdev = 19.729/21.649/24.092/1.595 ms
depuis une cnx degroupée free (qd elle veut bien marcher) sur le dns de tiscali
Remy Moulin
olafkewl wrote:
On Wed, 17 Sep 2003 09:55:49 +0200, "manali (fo)"
[Snip pings de ouf! ] 5 packets transmitted, 5 received, 0% packet loss, time 4021ms rtt min/avg/max/mdev = 19.729/21.649/24.092/1.595 ms
depuis une cnx degroupée free (qd elle veut bien marcher) sur le dns de tiscali
Il y a plusieurs explications à ça :
1°) Free Dégroupé utilise l'encapsulation ATM la plus simple possible : VCMUX.
2°) Ils n'utilisent pas PPP : une couche en moins. C'est directement de l'IP sur ATM.
3°) Ils utilisent un /Interleave/ moindre de celui de France Telecom (à ce propos : France Telecom est il au max d'Interleave, ou c'est possible de faire pire ?)
4°) A l'échelle de mesure du ping (le ms), au vu de la taille du paquet ping standard avec en-têtes ATM, IP et ICMP et les vitesses ADSL, le temps de traversé de la partie ADSL n'est pas négligeable :
Taille paquet : IP 20 + ICMP 8 + Buffer 32 = 60 octets; plus la taille utilisée pour l'encapsulation ATM : AAL5 + 8 octets, VCMUX + 0 octets, Taille : 68, divisé en 2 cellules de contenance 48 octets, ayant 5 octets d'en-tête par cellule, ce qui donne 106 octets ATM transportés ou 848 bits ATM. Ouf.
En ADSL 128 /moyen/ débit : 96 kbit/s l'aller et 160 kbit/s le retour : 8,83ms l'aller + 5,3ms le retour = 14,13 ms
En ADSL 512/128 classique : 160 kbit/s l'aller et 608 kbits/s le retour : soit 5,3 ms l'aller +1,4 ms retour = 6,7 ms (En grossisant le ping avec le paramètre -l <taille de buffer>, sur ma ligne 512/128, j'ai pu voir expérimentalement le ping 'gonfler' par palliers de 3,7 ms (environ), à chaque fois qu'une cellule ATM supplémentaire était requise pour transporter le paquet IP, c'est pas très loin des 3,35ms par paquet que donne ce calcul théorique)
En ADSL Free : 384 kbit/s l'aller (c'est ça ?) et 2400 kbit/s le retour : 2,2ms l'aller + 0,35ms le retour = 2,6 ms
5°) Laissé blanc pour un éventuel commentaire de la part des Gourous de Free... (Leurs trucs & astuces pour améliorer les latences ?)
Bref... Tout ça additionné, ça donne un réseau plus 'nerveux', forcément !
-- Herm
olafkewl wrote:
On Wed, 17 Sep 2003 09:55:49 +0200, "manali (fo)"
[Snip pings de ouf! ]
5 packets transmitted, 5 received, 0% packet loss, time 4021ms
rtt min/avg/max/mdev = 19.729/21.649/24.092/1.595 ms
depuis une cnx degroupée free (qd elle veut bien marcher) sur le dns
de tiscali
Il y a plusieurs explications à ça :
1°) Free Dégroupé utilise l'encapsulation ATM la plus simple possible :
VCMUX.
2°) Ils n'utilisent pas PPP : une couche en moins. C'est directement de l'IP
sur ATM.
3°) Ils utilisent un /Interleave/ moindre de celui de France Telecom (à ce
propos : France Telecom est il au max d'Interleave, ou c'est possible de
faire pire ?)
4°) A l'échelle de mesure du ping (le ms), au vu de la taille du paquet ping
standard avec en-têtes ATM, IP et ICMP et les vitesses ADSL, le temps de
traversé de la partie ADSL n'est pas négligeable :
Taille paquet : IP 20 + ICMP 8 + Buffer 32 = 60 octets; plus la taille
utilisée pour l'encapsulation ATM : AAL5 + 8 octets, VCMUX + 0 octets,
Taille : 68, divisé en 2 cellules de contenance 48 octets, ayant 5 octets
d'en-tête par cellule, ce qui donne 106 octets ATM transportés ou 848 bits
ATM. Ouf.
En ADSL 128 /moyen/ débit : 96 kbit/s l'aller et 160 kbit/s le retour :
8,83ms l'aller + 5,3ms le retour = 14,13 ms
En ADSL 512/128 classique : 160 kbit/s l'aller et 608 kbits/s le retour :
soit 5,3 ms l'aller +1,4 ms retour = 6,7 ms
(En grossisant le ping avec le paramètre -l <taille de buffer>, sur ma
ligne 512/128, j'ai pu voir expérimentalement le ping 'gonfler' par palliers
de 3,7 ms (environ), à chaque fois qu'une cellule ATM supplémentaire était
requise pour transporter le paquet IP, c'est pas très loin des 3,35ms par
paquet que donne ce calcul théorique)
En ADSL Free : 384 kbit/s l'aller (c'est ça ?) et 2400 kbit/s le retour :
2,2ms l'aller + 0,35ms le retour = 2,6 ms
5°) Laissé blanc pour un éventuel commentaire de la part des Gourous de
Free... (Leurs trucs & astuces pour améliorer les latences ?)
Bref... Tout ça additionné, ça donne un réseau plus 'nerveux', forcément !
[Snip pings de ouf! ] 5 packets transmitted, 5 received, 0% packet loss, time 4021ms rtt min/avg/max/mdev = 19.729/21.649/24.092/1.595 ms
depuis une cnx degroupée free (qd elle veut bien marcher) sur le dns de tiscali
Il y a plusieurs explications à ça :
1°) Free Dégroupé utilise l'encapsulation ATM la plus simple possible : VCMUX.
2°) Ils n'utilisent pas PPP : une couche en moins. C'est directement de l'IP sur ATM.
3°) Ils utilisent un /Interleave/ moindre de celui de France Telecom (à ce propos : France Telecom est il au max d'Interleave, ou c'est possible de faire pire ?)
4°) A l'échelle de mesure du ping (le ms), au vu de la taille du paquet ping standard avec en-têtes ATM, IP et ICMP et les vitesses ADSL, le temps de traversé de la partie ADSL n'est pas négligeable :
Taille paquet : IP 20 + ICMP 8 + Buffer 32 = 60 octets; plus la taille utilisée pour l'encapsulation ATM : AAL5 + 8 octets, VCMUX + 0 octets, Taille : 68, divisé en 2 cellules de contenance 48 octets, ayant 5 octets d'en-tête par cellule, ce qui donne 106 octets ATM transportés ou 848 bits ATM. Ouf.
En ADSL 128 /moyen/ débit : 96 kbit/s l'aller et 160 kbit/s le retour : 8,83ms l'aller + 5,3ms le retour = 14,13 ms
En ADSL 512/128 classique : 160 kbit/s l'aller et 608 kbits/s le retour : soit 5,3 ms l'aller +1,4 ms retour = 6,7 ms (En grossisant le ping avec le paramètre -l <taille de buffer>, sur ma ligne 512/128, j'ai pu voir expérimentalement le ping 'gonfler' par palliers de 3,7 ms (environ), à chaque fois qu'une cellule ATM supplémentaire était requise pour transporter le paquet IP, c'est pas très loin des 3,35ms par paquet que donne ce calcul théorique)
En ADSL Free : 384 kbit/s l'aller (c'est ça ?) et 2400 kbit/s le retour : 2,2ms l'aller + 0,35ms le retour = 2,6 ms
5°) Laissé blanc pour un éventuel commentaire de la part des Gourous de Free... (Leurs trucs & astuces pour améliorer les latences ?)
Bref... Tout ça additionné, ça donne un réseau plus 'nerveux', forcément !
-- Herm
Serge
Outre ceci, nous tenions à vous informer que la mise à jour des Dslams de type Alcatel était censée intervenir actuellement. Celle-ci devait permettre de passer du mode "Interleave High" à "Interleave Medium", soit une diminution sensible du ping (environ 10-20ms, soit 50ms sous dos)
Le ping depend de l'os maintenant?? lol :))
Outre ceci, nous tenions à vous informer que la mise à jour des Dslams
de type Alcatel était censée intervenir actuellement. Celle-ci devait
permettre de passer du mode "Interleave High" à "Interleave Medium",
soit une diminution sensible du ping (environ 10-20ms, soit 50ms sous
dos)
Outre ceci, nous tenions à vous informer que la mise à jour des Dslams de type Alcatel était censée intervenir actuellement. Celle-ci devait permettre de passer du mode "Interleave High" à "Interleave Medium", soit une diminution sensible du ping (environ 10-20ms, soit 50ms sous dos)
Le ping depend de l'os maintenant?? lol :))
mirak
Remy Moulin wrote:
olafkewl wrote:
On Wed, 17 Sep 2003 09:55:49 +0200, "manali (fo)"
[Snip pings de ouf! ] 5 packets transmitted, 5 received, 0% packet loss, time 4021ms rtt min/avg/max/mdev = 19.729/21.649/24.092/1.595 ms
depuis une cnx degroupée free (qd elle veut bien marcher) sur le dns de tiscali
Il y a plusieurs explications à ça :
1°) Free Dégroupé utilise l'encapsulation ATM la plus simple possible : VCMUX.
2°) Ils n'utilisent pas PPP : une couche en moins. C'est directement de l'IP sur ATM.
3°) Ils utilisent un /Interleave/ moindre de celui de France Telecom (à ce propos : France Telecom est il au max d'Interleave, ou c'est possible de faire pire ?)
Au max ils sont. Sur eci ça va encore, sur alcatel c'est trop.
4°) A l'échelle de mesure du ping (le ms), au vu de la taille du paquet ping standard avec en-têtes ATM, IP et ICMP et les vitesses ADSL, le temps de traversé de la partie ADSL n'est pas négligeable :
Taille paquet : IP 20 + ICMP 8 + Buffer 32 = 60 octets; plus la taille utilisée pour l'encapsulation ATM : AAL5 + 8 octets, VCMUX + 0 octets, Taille : 68, divisé en 2 cellules de contenance 48 octets, ayant 5 octets d'en-tête par cellule, ce qui donne 106 octets ATM transportés ou 848 bits ATM. Ouf.
En ADSL 128 /moyen/ débit : 96 kbit/s l'aller et 160 kbit/s le retour : 8,83ms l'aller + 5,3ms le retour = 14,13 ms
En ADSL 512/128 classique : 160 kbit/s l'aller et 608 kbits/s le retour : soit 5,3 ms l'aller +1,4 ms retour = 6,7 ms (En grossisant le ping avec le paramètre -l <taille de buffer>, sur ma ligne 512/128, j'ai pu voir expérimentalement le ping 'gonfler' par palliers de 3,7 ms (environ), à chaque fois qu'une cellule ATM supplémentaire était requise pour transporter le paquet IP, c'est pas très loin des 3,35ms par paquet que donne ce calcul théorique)
En ADSL Free : 384 kbit/s l'aller (c'est ça ?) et 2400 kbit/s le retour : 2,2ms l'aller + 0,35ms le retour = 2,6 ms
5°) Laissé blanc pour un éventuel commentaire de la part des Gourous de Free... (Leurs trucs & astuces pour améliorer les latences ?)
Bref... Tout ça additionné, ça donne un réseau plus 'nerveux', forcément !
Un ping de 10 ça m'empechera pas de me prendre des bralnées a counter lol
Remy Moulin wrote:
olafkewl wrote:
On Wed, 17 Sep 2003 09:55:49 +0200, "manali (fo)"
[Snip pings de ouf! ]
5 packets transmitted, 5 received, 0% packet loss, time 4021ms
rtt min/avg/max/mdev = 19.729/21.649/24.092/1.595 ms
depuis une cnx degroupée free (qd elle veut bien marcher) sur le dns
de tiscali
Il y a plusieurs explications à ça :
1°) Free Dégroupé utilise l'encapsulation ATM la plus simple possible :
VCMUX.
2°) Ils n'utilisent pas PPP : une couche en moins. C'est directement de l'IP
sur ATM.
3°) Ils utilisent un /Interleave/ moindre de celui de France Telecom (à ce
propos : France Telecom est il au max d'Interleave, ou c'est possible de
faire pire ?)
Au max ils sont.
Sur eci ça va encore, sur alcatel c'est trop.
4°) A l'échelle de mesure du ping (le ms), au vu de la taille du paquet ping
standard avec en-têtes ATM, IP et ICMP et les vitesses ADSL, le temps de
traversé de la partie ADSL n'est pas négligeable :
Taille paquet : IP 20 + ICMP 8 + Buffer 32 = 60 octets; plus la taille
utilisée pour l'encapsulation ATM : AAL5 + 8 octets, VCMUX + 0 octets,
Taille : 68, divisé en 2 cellules de contenance 48 octets, ayant 5 octets
d'en-tête par cellule, ce qui donne 106 octets ATM transportés ou 848 bits
ATM. Ouf.
En ADSL 128 /moyen/ débit : 96 kbit/s l'aller et 160 kbit/s le retour :
8,83ms l'aller + 5,3ms le retour = 14,13 ms
En ADSL 512/128 classique : 160 kbit/s l'aller et 608 kbits/s le retour :
soit 5,3 ms l'aller +1,4 ms retour = 6,7 ms
(En grossisant le ping avec le paramètre -l <taille de buffer>, sur ma
ligne 512/128, j'ai pu voir expérimentalement le ping 'gonfler' par palliers
de 3,7 ms (environ), à chaque fois qu'une cellule ATM supplémentaire était
requise pour transporter le paquet IP, c'est pas très loin des 3,35ms par
paquet que donne ce calcul théorique)
En ADSL Free : 384 kbit/s l'aller (c'est ça ?) et 2400 kbit/s le retour :
2,2ms l'aller + 0,35ms le retour = 2,6 ms
5°) Laissé blanc pour un éventuel commentaire de la part des Gourous de
Free... (Leurs trucs & astuces pour améliorer les latences ?)
Bref... Tout ça additionné, ça donne un réseau plus 'nerveux', forcément !
Un ping de 10 ça m'empechera pas de me prendre des bralnées a counter lol
[Snip pings de ouf! ] 5 packets transmitted, 5 received, 0% packet loss, time 4021ms rtt min/avg/max/mdev = 19.729/21.649/24.092/1.595 ms
depuis une cnx degroupée free (qd elle veut bien marcher) sur le dns de tiscali
Il y a plusieurs explications à ça :
1°) Free Dégroupé utilise l'encapsulation ATM la plus simple possible : VCMUX.
2°) Ils n'utilisent pas PPP : une couche en moins. C'est directement de l'IP sur ATM.
3°) Ils utilisent un /Interleave/ moindre de celui de France Telecom (à ce propos : France Telecom est il au max d'Interleave, ou c'est possible de faire pire ?)
Au max ils sont. Sur eci ça va encore, sur alcatel c'est trop.
4°) A l'échelle de mesure du ping (le ms), au vu de la taille du paquet ping standard avec en-têtes ATM, IP et ICMP et les vitesses ADSL, le temps de traversé de la partie ADSL n'est pas négligeable :
Taille paquet : IP 20 + ICMP 8 + Buffer 32 = 60 octets; plus la taille utilisée pour l'encapsulation ATM : AAL5 + 8 octets, VCMUX + 0 octets, Taille : 68, divisé en 2 cellules de contenance 48 octets, ayant 5 octets d'en-tête par cellule, ce qui donne 106 octets ATM transportés ou 848 bits ATM. Ouf.
En ADSL 128 /moyen/ débit : 96 kbit/s l'aller et 160 kbit/s le retour : 8,83ms l'aller + 5,3ms le retour = 14,13 ms
En ADSL 512/128 classique : 160 kbit/s l'aller et 608 kbits/s le retour : soit 5,3 ms l'aller +1,4 ms retour = 6,7 ms (En grossisant le ping avec le paramètre -l <taille de buffer>, sur ma ligne 512/128, j'ai pu voir expérimentalement le ping 'gonfler' par palliers de 3,7 ms (environ), à chaque fois qu'une cellule ATM supplémentaire était requise pour transporter le paquet IP, c'est pas très loin des 3,35ms par paquet que donne ce calcul théorique)
En ADSL Free : 384 kbit/s l'aller (c'est ça ?) et 2400 kbit/s le retour : 2,2ms l'aller + 0,35ms le retour = 2,6 ms
5°) Laissé blanc pour un éventuel commentaire de la part des Gourous de Free... (Leurs trucs & astuces pour améliorer les latences ?)
Bref... Tout ça additionné, ça donne un réseau plus 'nerveux', forcément !
Un ping de 10 ça m'empechera pas de me prendre des bralnées a counter lol
olafkewl
On Thu, 18 Sep 2003 13:07:06 +0200, Serge wrote:
Le ping depend de l'os maintenant?? lol :))
l'os et la couche tcp de l'os peuvent jouer, bien sur !
On Thu, 18 Sep 2003 13:07:06 +0200, Serge <serge@nospam.kilio.net>
wrote:
Le ping depend de l'os maintenant?? lol :))
l'os et la couche tcp de l'os peuvent jouer, bien sur !
l'os et la couche tcp de l'os peuvent jouer, bien sur !
Remy Moulin
mirak wrote:
Au max ils sont. Sur eci ça va encore, sur alcatel c'est trop.
Bonsoir,
Ah bon... Donc c'est une bonne nouvelle : quelle que soit la modif qu'ils tentent, ça ne peut être pire ;-)
(Vous savez, l'histoire du verre 1/2 plein ou 1/2 vide)...
4°) A l'échelle de mesure du ping (le ms), au vu de la taille du paquet ping standard avec en-têtes ATM, IP et ICMP et les vitesses ADSL, le temps de traversé de la partie ADSL n'est pas négligeable :
Taille paquet : IP 20 + ICMP 8 + Buffer 32 = 60 octets; plus la taille utilisée pour l'encapsulation ATM : AAL5 + 8 octets, VCMUX + 0 octets, Taille : 68, divisé en 2 cellules de contenance 48 octets, ayant 5 octets d'en-tête par cellule, ce qui donne 106 octets ATM transportés ou 848 bits ATM. Ouf.
Oops, p'tit gourage de ma part, mais sans influence sur le résultat final :
La taille ATM des données des offres 128 et 512 intègre PPP, puisqu'au minimum, on utilise PPPoA. Pour Free dégroupé, y'a pas PPP.
Donc : - Hors Free dégroupé : Taille du paquet IP ping "standard" : 20+8+32 = 60 octets Taille du paquet PPP : 60 + 2 = 62 octets Taille AAL5 en VCMUX : 62 + 8 + 0 = 70 octets Nb de cellules ATM nécessaires : 70 / 48 = 1,45..., donc 2 cellules Taille ATM : 2 * 53 octets = 106 octets = 848 bits.
- Avec Free dégroupé : Taille du paquet IP ping "standard" : 20+8+32 = 60 octets Taille AAL5 en VCMUX : 60 + 8 + 0 = 68 octets Nb de cellules ATM nécessaires : 68 / 48 = 1,41..., donc 2 cellules Taille ATM : 2 * 53 octets = 106 octets = 848 bits.
... juste par souci de complétude...
Je me demande bien combien fait un ping chez Free dégroupé quand le paquet est à la taille maximale...
Un ping -l 1472 <serveur proche> (ça teste le MTU 1500 qui consomme 32 cellules. Normalement équivalent à un ping -l 1453, mais un poil supérieur à ping -l 1452 (31 cellules) ).
A vue de nez, 70 ms ?
Un ping de 10 ça m'empechera pas de me prendre des bralnées a counter lol
Ah, là... La technique à ses limites, hein ... :-D
-- Herm
mirak wrote:
Au max ils sont.
Sur eci ça va encore, sur alcatel c'est trop.
Bonsoir,
Ah bon... Donc c'est une bonne nouvelle : quelle que soit la modif qu'ils
tentent, ça ne peut être pire ;-)
(Vous savez, l'histoire du verre 1/2 plein ou 1/2 vide)...
4°) A l'échelle de mesure du ping (le ms), au vu de la taille du
paquet ping standard avec en-têtes ATM, IP et ICMP et les vitesses
ADSL, le temps de traversé de la partie ADSL n'est pas négligeable :
Taille paquet : IP 20 + ICMP 8 + Buffer 32 = 60 octets; plus la
taille utilisée pour l'encapsulation ATM : AAL5 + 8 octets, VCMUX +
0 octets, Taille : 68, divisé en 2 cellules de contenance 48 octets,
ayant 5 octets d'en-tête par cellule, ce qui donne 106 octets ATM
transportés ou 848 bits ATM. Ouf.
Oops, p'tit gourage de ma part, mais sans influence sur le résultat final :
La taille ATM des données des offres 128 et 512 intègre PPP, puisqu'au
minimum, on utilise PPPoA. Pour Free dégroupé, y'a pas PPP.
Donc :
- Hors Free dégroupé :
Taille du paquet IP ping "standard" : 20+8+32 = 60 octets
Taille du paquet PPP : 60 + 2 = 62 octets
Taille AAL5 en VCMUX : 62 + 8 + 0 = 70 octets
Nb de cellules ATM nécessaires : 70 / 48 = 1,45..., donc 2 cellules
Taille ATM : 2 * 53 octets = 106 octets = 848 bits.
- Avec Free dégroupé :
Taille du paquet IP ping "standard" : 20+8+32 = 60 octets
Taille AAL5 en VCMUX : 60 + 8 + 0 = 68 octets
Nb de cellules ATM nécessaires : 68 / 48 = 1,41..., donc 2 cellules
Taille ATM : 2 * 53 octets = 106 octets = 848 bits.
... juste par souci de complétude...
Je me demande bien combien fait un ping chez Free dégroupé quand le paquet
est à la taille maximale...
Un ping -l 1472 <serveur proche> (ça teste le MTU 1500 qui consomme 32
cellules. Normalement équivalent à un ping -l 1453, mais un poil supérieur à
ping -l 1452 (31 cellules) ).
A vue de nez, 70 ms ?
Un ping de 10 ça m'empechera pas de me prendre des bralnées a
counter lol
Ah, là... La technique à ses limites, hein ... :-D
Au max ils sont. Sur eci ça va encore, sur alcatel c'est trop.
Bonsoir,
Ah bon... Donc c'est une bonne nouvelle : quelle que soit la modif qu'ils tentent, ça ne peut être pire ;-)
(Vous savez, l'histoire du verre 1/2 plein ou 1/2 vide)...
4°) A l'échelle de mesure du ping (le ms), au vu de la taille du paquet ping standard avec en-têtes ATM, IP et ICMP et les vitesses ADSL, le temps de traversé de la partie ADSL n'est pas négligeable :
Taille paquet : IP 20 + ICMP 8 + Buffer 32 = 60 octets; plus la taille utilisée pour l'encapsulation ATM : AAL5 + 8 octets, VCMUX + 0 octets, Taille : 68, divisé en 2 cellules de contenance 48 octets, ayant 5 octets d'en-tête par cellule, ce qui donne 106 octets ATM transportés ou 848 bits ATM. Ouf.
Oops, p'tit gourage de ma part, mais sans influence sur le résultat final :
La taille ATM des données des offres 128 et 512 intègre PPP, puisqu'au minimum, on utilise PPPoA. Pour Free dégroupé, y'a pas PPP.
Donc : - Hors Free dégroupé : Taille du paquet IP ping "standard" : 20+8+32 = 60 octets Taille du paquet PPP : 60 + 2 = 62 octets Taille AAL5 en VCMUX : 62 + 8 + 0 = 70 octets Nb de cellules ATM nécessaires : 70 / 48 = 1,45..., donc 2 cellules Taille ATM : 2 * 53 octets = 106 octets = 848 bits.
- Avec Free dégroupé : Taille du paquet IP ping "standard" : 20+8+32 = 60 octets Taille AAL5 en VCMUX : 60 + 8 + 0 = 68 octets Nb de cellules ATM nécessaires : 68 / 48 = 1,41..., donc 2 cellules Taille ATM : 2 * 53 octets = 106 octets = 848 bits.
... juste par souci de complétude...
Je me demande bien combien fait un ping chez Free dégroupé quand le paquet est à la taille maximale...
Un ping -l 1472 <serveur proche> (ça teste le MTU 1500 qui consomme 32 cellules. Normalement équivalent à un ping -l 1453, mais un poil supérieur à ping -l 1452 (31 cellules) ).
A vue de nez, 70 ms ?
Un ping de 10 ça m'empechera pas de me prendre des bralnées a counter lol
Ah, là... La technique à ses limites, hein ... :-D
-- Herm
çmoi
et oui , c'est toujours moins bon avec windaube et micraube
et oui , c'est toujours moins bon avec windaube et micraube
