Free 10M/800K - Page 2

Donc en gros on risque rien à éssayer la patate?
Si on est près DSLAM ça marche mieux et sinon ça marche moins bien. si je comprend.

Voilà. Tu testes, et si t'as de la chance ça va plus vite, si t'as pas de chance c'est plus lent.

Mais pourquoi ils font pas l'accès débridé avec seuil de bruit minimum?

c'est ce qu'il font...

sauf que si tu t'estimes assez proche du dslam tu peux baisser le seuil...

spectras
:

arnsy et sdr>
- Parce que ça m'énerverait d'envoyer et recevoir des fichiers souvents corrompus. - s'il n'y a pas de gestion des erreurs, ça sert à rien de faire du transfert de fichier (ou alors statistiquement les pertes de paquets sont rares)

Comme l'a dit vince de façon un peu laconique, TCP/IP, un truc pas mal utilisé sur le net, fait la correction des erreurs tout seul comme un grand (retransmission, réorganisation des datagrammes arrivant dans un mauvais ordre, etc). Heureusement d'ailleurs parce que les paquets perdus ne sont pas aussi rares qu'on pourrait le penser, et les paquets arrivant dans le désordre sont même assez fréquents.
Et pour les applications utilisant UDP/IP, elles gèrent elles-même les pertes selon l'utilisation qu'elles font des données.

Bon déjà c'est zdr.
Ensuite, c'est ce que je disais en 6 et 10 , et t'inquiètes pas je connais TCP / IP.


A vrai dire je comprends pas ce que dit arnsy

arnsy :
Euh ça m'étonnerait qu'ils n'implémentent pas par dessus un protocole de gestion des erreurs et de réémission des paquets ...
>>>> Bin si c'est juste un mode à choisir...
Sinon c'est 6M/512K avec gestion des erreurs et réémission des paquets.

Ben si c'est "juste un mode à choisir" ça veut dire que ça fonctionne sur un TCP / IP sans correction / retransmission (je ne pense pas qu'une application puisse forcer TCP à ignorer les erreurs), ou plus simplement sur UDP / IP, avec éventuellement correction / retransmission au niveau applicatif ... Donc soit il y a un système de correction / retransmission soit ça ne marche pas sur TCP , donc l'un de vous deux a tort ...
Vraisemblablement (sauf pour la version ATM) ça fonctionne sur TCP ; donc le mode patate serait une histoire de fenêtre de transmission assez large

Oui, ou alors ils ont un système de correction d'erreur propre à la freebox et redondant et c'est celui-là qu'ils proposent de désactiver ?!
Sinon, je viens de l'activer (je suis à 1250m du DSLAM), je vais voir ce soir si ça change vraiment beaucoup.

enfin, non, je verrai ça dimanche soir

NOTE : - La mise à jour intervient toutes les 24 heures entre 00:00 H et 02:00 H

et je ne suis pas là ce w-e

:/

Nil :
Oui, ou alors ils ont un système de correction d'erreur propre à la freebox et redondant et c'est celui-là qu'ils proposent de désactiver ?!

J'avais pas pensé à ça

mouef... pas convaincu. Bonjour la surcharge protocolaire!

Je pense surtout comme l'a suggéré quelqu'un que ça propose un élargissement du spectre avec un nombre plus important de canaux de liaison. Donc si t'es assez prêt ca passe, sinon tu restes comme t'es. C'est ca qu'ils veulent dire.

Squalyl^2>Vu les débits qu'ils peuvent se permettre, il est possible qu'ils aient légèrement augmenté la qualité du son (ca leur coute rien et ça leur fait toujours un argument commercial supplémentaire).

Bon déjà c'est zdr

Désolé, fautte de frappe.

Vraisemblablement (sauf pour la version ATM) ça fonctionne sur TCP

Nan là n'est pas le problème. De toutes façons, quoique tu fasses, tu utilises forcément TCP quand tu accèdes à une page web. Que tu utilises un modem, le satellite, un réseau local, la rfc de transmission par pigeons voyageurs ou des signaux de fumée ne change rien au problème, tu as de toutes façons TCP/IP (ou UDP/IP pour certaines applications) qui entre en jeu quand tu accèdes au web.

En ATM (en pppoa pour être exact), ça donne ça quand tu accèdes à une page web :

Oui, ou alors ils ont un système de correction d'erreur propre à la freebox et redondant et c'est celui-là qu'ils proposent de désactiver ?!

Pas crédible je dirais. Trop coûteux à implémenter alors que c'est déjà supporté en standard par les couches logicielles au dessus (donc sans grand intérêt).

Nan en fait le mode patate, c'est juste qu'il change le débit de 6Mbps à 10Mbps, ce qui va plus vite, mais avec plus d'interférences dues à la ligne, donc plus de pertes de paquets si la ligne est mauvaise.
C'est un peu comme transférer en 100Mbps sur un câble 10Mpbs. Si t'as de la chance, que la distance est courte et que tu est tombé sur un câble de bonne qualité, ça peut passer, le meilleur débit compensant les pertes dues à l'usage d'une fréquence pour laquelle le câble n'était pas prévu au départ.

spectras :
Nan là n'est pas le problème. De toutes façons, quoique tu fasses, tu utilises forcément TCP quand tu accèdes à une page web. Que tu utilises un modem, le satellite, un réseau local, la rfc de transmission par pigeons voyageurs ou des signaux de fumée ne change rien au problème, tu as de toutes façons TCP/IP (ou UDP/IP pour certaines applications) qui entre en jeu quand tu accèdes au web.

En ATM (en pppoa pour être exact), ça donne ça quand tu accèdes à une page web :

HTTP

TCP

IP

PPP

ATM

Ok je savais pas

Et PPP n'est pas indispensable, ça peut très bien être autre chose... ça, c'est si ta connexion est authentifiée avec le protocole PPP, mais ça peut être avec autre chose .

Ué, je parlais juste du cas de free, qui fait du pppoa (au moins chez moi en tous cas).

Ah ? Pas chez moi ?! Ou alors, c'est la freebox qui le fait en transparent

Je suis en non dégroupé, hein.

Ah ok

PPPOA si tu es en mode USB
PPPOE sur modem eth

Je l'est mis en fastpath, on verrat cette nuit.

FastPath 4tw ! Le mode papate, mouais, j'y crois pas trop, en général le débit est un poil superieur, mais on perd pas mal en ping... Perso, je prefere avoir un meilleur ping que de gagner qq kbs en dl/up ...

pas papate, patate ! (c pas,pareil ^^)

p_y_a>si le DSLAM est sur le trotoire d'en face, pkoi pas ??

je suis tres loin du dslam (2600m, 38dB d'atenuation theorique, et en pratique 28 en up et 55 en down), g activé la patate pour voir, mon débit n'a pas bcp bougé (+100kbps=>6100kbps) et le ping a baissé un poil (-3ms => 35ms)

le pb c que depuis leur debridage vers les 6Mb, mon noise margin a baissé de 10dB en up et down...
j'avais un attainable bitrate de 7616, maintenant, i lest à 6080...

Oui, mode patate et non pas papate, à mort les fautes de frappe :]

MacIntoc :
p_y_a>si le DSLAM est sur le trotoire d'en face, pkoi pas ??

Qu'il soit à 2kms ou à 10m de toi, ça ne joue rien sur ton ping, imagines si 2kms jouaient sur le ping, un ping sur un server américain serait énormissime

strangr>comment tu fait pour avoir l'aténuation pratique ??

p_y_a>le traitement des erreurs, ça joue pas sur le ping ??

pour avoir l'aténuation pratique, je vais sur la page 'infos ligne' http://adsl.free.fr/suivi/suivi_tech.html, et il y a marqué l'atténuation théorique (en haut), et l'atténuation pratique dans la serie des infos (uniquement pour les degroupés)

sinon, mon modem (olitec sx200) me la donne aussi

A tiens, j'ai l'atténuation théorique, mais pas pratique, pourtant, je suis dégroupé.

spectras> ip over pigeon voyageur, mais avec QoS svp

ftp://ftp.rfc-editor.org/in-notes/rfc2549.txt

(mouhahahah .. "Unintentional encapsulation in hawks has been known to occur, with decapsulation being messy and the packets mangled." j'adore..)

Cela dit cette version n'a jamais été implémentée, alors que la version d'origine (flemme de chercher le numéro) a été effectivement mise en oeuvre à titre de démonstration