[Luigi_B]

Bonjour.

Je viens de vérifier votre accès et le monitoring du ping, je ne constate pas ces montées, il est peu probable que ce soit provoqué par l'IPV6, ce serait facile à reproduire si vous réactivez et que ce phénomène réapparait.

N'hésitez pas alors à nous remonter si c'est le cas.

Cordialement.

Luigi.B

[galettebretonne]

Bizarre. Donc en mode dual stack (IPv6 + IPv4) le routeur est plus lent ?
Pour activer l'optimization sur les ACK TCP.
:ipqos queue config ackfiltering enabled

Je trouve ça bizarre aussi. Après je ne suis absolument pas sur que ça soit bien ça (méfiance aux coincidences). Mais je ne suis pas motivé pour aller chercher plus loin. Je fais suffisament de troubleshooting dans mon job pour ne pas en faire en plus pour le plaisir à la maison . Merci en tout cas pour le conseil sur l'optim ACK TCP. J'essaierai à l'occasion.

[Stuntman]

Je suis bien d'accord sur le côté logique de la chose. C'est le niveau de perturbation qui m'étonne. Je devrais dire qui m'étonnais car j'avais un ping qui montait à plus de 300ms et un download quasi bloqué lors d'un upload au max de la vitesse possible chez moi (env 100ko/s). Et tout à l'heure par acquis de conscience j'ai refait un petit test: et là bonne surprise, le ping ne monte plus qu'à 100ms et le download n'est plus bloqué. La seule modif sur mon install il y a quelques jours: je suis repassé en IPV4 sur le TG788 pour compatibilité avec netflix. Je me demande si il y a vraiment un lien avec l'amélioration (je ne vois pas trop mais qui sait ?). Les caractéristiques de la ligne pour info:

{Administrator}=>xdsl info expand=enabled
Physical Layer Statistics:

Modem state: up
Up time (Days hh:mm:ss): 22 jours, 11:45:13
xDSL Standard: ITU-T G.992.5 Annex A (ADSL2+ over POTS)
xDSL Annex: Annex A
Channel Mode: Interleaved

Number of reset: 0

Chipset Vendor info (G.994.1): Local Remote
Country code: B500 B500
ID: BDCM IFTN
Specific: 0000 71B3

System Vendor info (showtime): Local Remote
Country code: 0F00 0000
ID: TMMB ----
Specific: 3C61 0000

Bearers generic info DS US
Payload rate [kbps]: 16675 1019
Attenuation [dB]: 20.5 6.5
Margins [dB]: 6.0 14.4
Output power [dBm]: 0.0 12.7

Number of bearers: 1
Bearer 0 DS US
INP [DMT symbols]: 0.58 0.68
Delay [ms]: 7.50 3.98
Depth []: 64 0.00
R: 10 0

G.997.1 Statistics (Current):

Failures:
Line failures Near end
Loss of signal (LOS): 0
Loss of frame (LOF): 0
Loss of power (LPR): 0

Performance monitoring:
Line PM: Near end
Error second (ES): 1390

Channel PM: Near end Far end
Bearer 0:
Code Violation (CV): 2835 3
FEC: 245343 25

ATM data path PM: Near end Far end
Bearer 0:
HEC violation count (HEC): 80558 1

G.997.1 Statistics (last 15 minutes):

Failures:
Line failures Near end
Loss of signal (LOS): 0
Loss of frame (LOF): 0
Loss of power (LPR): 0

Performance monitoring:
Line PM: Near end
Error second (ES): 0

Channel PM: Near end Far end
Bearer 0:
Code Violation (CV): 2835 3
FEC: 245343 25

ATM data path PM: Near end Far end
Bearer 0:
HEC violation count (HEC): 80558 1

G.997.1 Statistics (last 24 hours):

Failures:
Line failures Near end
Loss of signal (LOS): 0
Loss of frame (LOF): 0
Loss of power (LPR): 0

Performance monitoring:
Line PM: Near end
Error second (ES): 9

Channel PM: Near end Far end
Bearer 0:
Code Violation (CV): 2835 3
FEC: 245343 25

ATM data path PM: Near end Far end
Bearer 0:
HEC violation count (HEC): 80558

Bizarre. Donc en mode dual stack (IPv6 + IPv4) le routeur est plus lent ?
Pour activer l'optimization sur les ACK TCP.
:ipqos queue config ackfiltering enabled

[galettebretonne]

Je suis bien d'accord sur le côté logique de la chose. C'est le niveau de perturbation qui m'étonne. Je devrais dire qui m'étonnais car j'avais un ping qui montait à plus de 300ms et un download quasi bloqué lors d'un upload au max de la vitesse possible chez moi (env 100ko/s). Et tout à l'heure par acquis de conscience j'ai refait un petit test: et là bonne surprise, le ping ne monte plus qu'à 100ms et le download n'est plus bloqué. La seule modif sur mon install il y a quelques jours: je suis repassé en IPV4 sur le TG788 pour compatibilité avec netflix. Je me demande si il y a vraiment un lien avec l'amélioration (je ne vois pas trop mais qui sait ?). Les caractéristiques de la ligne pour info:

{Administrator}=>xdsl info expand=enabled
Physical Layer Statistics:

Modem state: up
Up time (Days hh:mm:ss): 22 jours, 11:45:13
xDSL Standard: ITU-T G.992.5 Annex A (ADSL2+ over POTS)
xDSL Annex: Annex A
Channel Mode: Interleaved

Number of reset: 0

Chipset Vendor info (G.994.1): Local Remote
Country code: B500 B500
ID: BDCM IFTN
Specific: 0000 71B3

System Vendor info (showtime): Local Remote
Country code: 0F00 0000
ID: TMMB ----
Specific: 3C61 0000

Bearers generic info DS US
Payload rate [kbps]: 16675 1019
Attenuation [dB]: 20.5 6.5
Margins [dB]: 6.0 14.4
Output power [dBm]: 0.0 12.7

Number of bearers: 1
Bearer 0 DS US
INP [DMT symbols]: 0.58 0.68
Delay [ms]: 7.50 3.98
Depth []: 64 0.00
R: 10 0

G.997.1 Statistics (Current):

Failures:
Line failures Near end
Loss of signal (LOS): 0
Loss of frame (LOF): 0
Loss of power (LPR): 0

Performance monitoring:
Line PM: Near end
Error second (ES): 1390

Channel PM: Near end Far end
Bearer 0:
Code Violation (CV): 2835 3
FEC: 245343 25

ATM data path PM: Near end Far end
Bearer 0:
HEC violation count (HEC): 80558 1

G.997.1 Statistics (last 15 minutes):

Failures:
Line failures Near end
Loss of signal (LOS): 0
Loss of frame (LOF): 0
Loss of power (LPR): 0

Performance monitoring:
Line PM: Near end
Error second (ES): 0

Channel PM: Near end Far end
Bearer 0:
Code Violation (CV): 2835 3
FEC: 245343 25

ATM data path PM: Near end Far end
Bearer 0:
HEC violation count (HEC): 80558 1

G.997.1 Statistics (last 24 hours):

Failures:
Line failures Near end
Loss of signal (LOS): 0
Loss of frame (LOF): 0
Loss of power (LPR): 0

Performance monitoring:
Line PM: Near end
Error second (ES): 9

Channel PM: Near end Far end
Bearer 0:
Code Violation (CV): 2835 3
FEC: 245343 25

ATM data path PM: Near end Far end
Bearer 0:
HEC violation count (HEC): 80558

[Stuntman]

Ca me parait logique. Pour faire du download/surf le protocol principal utilisé est TCP. Et en gros, si les ACK TCP (en direction du serveur) sont ralentis ou bloqués dans la queue et bien le traffic en download est ralentis.
Il est possible d'activer la fonctionnalité TCP ACK filtering (réduction du nombre de ACK envoyé pour optimiser le traffic sur des connexions à faible upstream).
Quel est la caractéristique de la ligne ?
:xdsl info expand=enabled

Je peux éventuellement aider pour faire une règle QoS, mais il le faudrait un orientation sur les choix

[buddy]

Bonjour,

en attendant une solution "simple" mais pas forcément idéale serait de limiter les logiciels "clouds" à 0;5 Mbits en upload par exemple, comme çà il resterait la moitié de l'upload pour le reste.

[galettebretonne]

Bonjour,
Malheureusement le défaut persiste. Et on est parfois à 2 doigts de la crise de nerf dans la maison ("Mais qui est en train d'uploader ?" est une question qui revient souvent...). Mon identifiant: ce24510-ovh. Merci pour votre aide.

[Luigi_B]

Bonjour.

Le défaut persiste-t-il ? Pourriez-vous me communiquer votre identifiant client pour les vérifications ?

Cordialement.

Luigi.B

[galettebretonne]

Bonjour,

Je suis actuellement bénéficiaire d'une offre ADSL OVH non dégroupé passant par les prises d'Orange au niveau du NRA (SFR non dégroupé sur ce NRA donc pas de doute possible) et j'ai un souci de débit en download et en ping dès que quelqu'un à la maison upload de gros fichiers (ce qui est de moins en moins rare avec la mode du cloud). En clair impossible de surfer si upload significatif. J'ai tenté de jouer avec les fonctions de QOS du TG788 (pour au moins prioriser mon laptop) mais rien n'y fait. Quelqu'un rencontre t'il un pb similaire ? Je suis bien conscient que l'upload a un impact sur le download mais à ce point ce n'est vraiment pas normal. Merci d'avance pour votre aide.