Je suis assez agréablement surpris de l'inscription chez Free.
Je m'attendais à des délais interminables et coupure de ma ligne ADSL
pendant des jours.
Pas du tout.
J'ai posté mon inscription mercredi 24/09.
Reçu chez Free jeudi 25.
vendredi 3/10 : reception de la FreeBox
mercredi 8 : ouverture de ma ligne.
Ma demande a été traité en 10 jours ouvrés. pas trop mal.
Branchement installation du matériel un petit qurt d'heure et ca marche
du premier coup.
Les premiers tests de débit sont très concluant... >>1024K (c'est
facilement du 1500K voire presque 2048K)
Je suis à Paris dans le XVème, ça aide peut être un peu ?
J'attends de voir la suite en qualité de service, et continuité de
connexion.
Branchement installation du matériel un petit qurt d'heure et ca marche du premier coup.
Superbe, c'est ta maman qui doit être fière de toi
fc
Daniel CULO wrote:
Je suis assez agréablement surpris de l'inscription chez Free. Je m'attendais à des délais interminables et coupure de ma ligne ADSL pendant des jours.
Pas du tout.
J'ai posté mon inscription mercredi 24/09. Reçu chez Free jeudi 25. vendredi 3/10 : reception de la FreeBox mercredi 8 : ouverture de ma ligne.
Ma demande a été traité en 10 jours ouvrés. pas trop mal. Branchement installation du matériel un petit qurt d'heure et ca marche du premier coup.
Les premiers tests de débit sont très concluant... >>1024K (c'est facilement du 1500K voire presque 2048K)
Je suis à Paris dans le XVème, ça aide peut être un peu ?
J'attends de voir la suite en qualité de service, et continuité de connexion.
Jusqu'ici tout va bien ! ;o))
Daniel
Bonjour à tous,
Je tiens à confirmer également mon passage sans douleur de wanadoo à free. Je suis à nancy (sur le dslam de champ-le-boeuf 1). J'ai été dégrouppé en 10 jours tout compris (de l'envoi de mon inscription au surf). Pour le moment tout marche parfaitement (download à 250ko/sec et upload à 35-40 ko/sec). La téléphonie fonctionne également sans problème. Voilà, je voulais vous faire part de mon expérience. N'ayant pas eu besoin du service technique, je ne donnerai donc aucune impression...
François.
Daniel CULO wrote:
Je suis assez agréablement surpris de l'inscription chez Free.
Je m'attendais à des délais interminables et coupure de ma ligne ADSL
pendant des jours.
Pas du tout.
J'ai posté mon inscription mercredi 24/09.
Reçu chez Free jeudi 25.
vendredi 3/10 : reception de la FreeBox
mercredi 8 : ouverture de ma ligne.
Ma demande a été traité en 10 jours ouvrés. pas trop mal.
Branchement installation du matériel un petit qurt d'heure et ca marche
du premier coup.
Les premiers tests de débit sont très concluant... >>1024K (c'est
facilement du 1500K voire presque 2048K)
Je suis à Paris dans le XVème, ça aide peut être un peu ?
J'attends de voir la suite en qualité de service, et continuité de
connexion.
Jusqu'ici tout va bien !
;o))
Daniel
Bonjour à tous,
Je tiens à confirmer également mon passage sans douleur de wanadoo à free.
Je suis à nancy (sur le dslam de champ-le-boeuf 1). J'ai été dégrouppé
en 10 jours tout compris (de l'envoi de mon inscription au surf).
Pour le moment tout marche parfaitement (download à 250ko/sec et upload
à 35-40 ko/sec). La téléphonie fonctionne également sans problème.
Voilà, je voulais vous faire part de mon expérience.
N'ayant pas eu besoin du service technique, je ne donnerai donc aucune
impression...
Je suis assez agréablement surpris de l'inscription chez Free. Je m'attendais à des délais interminables et coupure de ma ligne ADSL pendant des jours.
Pas du tout.
J'ai posté mon inscription mercredi 24/09. Reçu chez Free jeudi 25. vendredi 3/10 : reception de la FreeBox mercredi 8 : ouverture de ma ligne.
Ma demande a été traité en 10 jours ouvrés. pas trop mal. Branchement installation du matériel un petit qurt d'heure et ca marche du premier coup.
Les premiers tests de débit sont très concluant... >>1024K (c'est facilement du 1500K voire presque 2048K)
Je suis à Paris dans le XVème, ça aide peut être un peu ?
J'attends de voir la suite en qualité de service, et continuité de connexion.
Jusqu'ici tout va bien ! ;o))
Daniel
Bonjour à tous,
Je tiens à confirmer également mon passage sans douleur de wanadoo à free. Je suis à nancy (sur le dslam de champ-le-boeuf 1). J'ai été dégrouppé en 10 jours tout compris (de l'envoi de mon inscription au surf). Pour le moment tout marche parfaitement (download à 250ko/sec et upload à 35-40 ko/sec). La téléphonie fonctionne également sans problème. Voilà, je voulais vous faire part de mon expérience. N'ayant pas eu besoin du service technique, je ne donnerai donc aucune impression...
François.
Daniel CULO
Brina wrote:
Dans l'article , Daniel CULO nous disait ...
Les premiers tests de débit sont très concluant... >>1024K (c'est facilement du 1500K voire presque 2048K)
ça doit être du 2048/384 :-)
bin, c'est que je découvre... je croyais avoir du 1024 bonne surprise ! ;o))
Brina wrote:
Dans l'article <3F848DAA.8E342FFA@anti-pourriel.laposte.net>, Daniel CULO
<daniel.culo@anti-pourriel.laposte.net> nous disait ...
Les premiers tests de débit sont très concluant... >>1024K (c'est
facilement du 1500K voire presque 2048K)
ça doit être du 2048/384 :-)
bin, c'est que je découvre...
je croyais avoir du 1024
bonne surprise !
;o))
je suis sur un reseau de 4 pcs win98se reliés à un routeur netgear rp614.
donc le premier pas est de mettre un seul PC relié à la fbx (en éthernet) et voir le DL. Si c'est bon, il faut revoir ton réseau.
pedrito
On 11 Oct 2003 12:51:48 GMT, Brina wrote:
Il faut régler le MTU
réglage actuel après consultation des divers sites et groupes:
MTU:1500 Tcp receive window: 51800 Window scaling: yes Time stamping: no Selective acks: yes Path MTU discovery: yes Black hole detection: no Max duplicate ACKs: 3 TTL: 64
est-ce bon? merci.
On 11 Oct 2003 12:51:48 GMT, Brina <brina@alussinan.org> wrote:
Il faut régler le MTU
réglage actuel après consultation des divers sites et groupes:
MTU:1500
Tcp receive window: 51800
Window scaling: yes
Time stamping: no
Selective acks: yes
Path MTU discovery: yes
Black hole detection: no
Max duplicate ACKs: 3
TTL: 64
réglage actuel après consultation des divers sites et groupes:
MTU:1500 Tcp receive window: 51800 Window scaling: yes Time stamping: no Selective acks: yes Path MTU discovery: yes Black hole detection: no Max duplicate ACKs: 3 TTL: 64
est-ce bon? merci.
pedrito
On Sat, 11 Oct 2003 14:59:22 +0200, pedrito wrote:
On 11 Oct 2003 12:51:48 GMT, Brina wrote:
Il faut régler le MTU
réglage actuel après consultation des divers sites et groupes:
données Dr TCP.
On Sat, 11 Oct 2003 14:59:22 +0200, pedrito <pedrito@hotmail.com>
wrote:
On 11 Oct 2003 12:51:48 GMT, Brina <brina@alussinan.org> wrote:
Il faut régler le MTU
réglage actuel après consultation des divers sites et groupes:
On Sat, 11 Oct 2003 14:59:22 +0200, pedrito wrote:
On 11 Oct 2003 12:51:48 GMT, Brina wrote:
Il faut régler le MTU
réglage actuel après consultation des divers sites et groupes:
données Dr TCP.
Remy Moulin
pedrito wrote:
réglage actuel après consultation des divers sites et groupes:
Bonsoir,
C'est pourtant pas mal du tout, comme réglage...
MTU:1500 Tcp receive window: 51800
C'est un peu étrange comme nombre pour le RWin, 51800 ...
Expérimentalement, chez moi, je me suis apperçu que l'on pouvait aller jusqu'à 65535 sans effet secondaire, mais certains préconisent de prendre une taille multiple du MSS, lequel, en TCP/IP, correspond au MTU - 40 octets.
MTU = 1500 MSS = 1460 (1500-40) RWin = 1460 * n, avec, par exemple 64240 (nD), ...
51800 n'est pas divisible par 1460...
Enfin, ce n'est pas dramatique... J'utilise 65535 chez moi avec de bonnes performances, et c'est pas non plus divisible par 1460 :-D...
Window scaling: yes
Cet option permet d'utiliser des RWin plus grands que 65535. Ce n'est réelement utile que sur des liens à trés haute latence, au /ping/ dépassant la seconde, quand il faut un RWin énorme. En ADSL, nul besoin d'avoir recours à cet artifice, vous pouvez mettre /no/ ici.
Au passage, chez moi, l'activation de cet option m'avait sorti des scores de transferts plus faibles que d'ordinaire...
Time stamping: no
En effet, pas reelement utile en ADSL. Cet option de marquage temporel des paquets peut être utilisé pour affiner le calcul du temps moyen de parcours des paquets, et d'affiner les timers de retransmission. Par défaut, TCP/IP possède une limite basse d'attente de retransmission d'une seconde (quand tous les autres artifices ont échoués), donc en ADSL où les temps sont de l'ordre de 20 à 70 ms, ça ne servirait pas à grand chose !
Selective acks: yes
Un des trucs pour découvrir la perte d'un paquet et déclancher rapidement une retransmission... /yes/.
Path MTU discovery: yes
Permet l'auto-détection du MTU optimum d'émission des paquets. Cela affecte l'Upload. Si l'option est désactivée, l'ordinateur prends la valeur minimal garantie par RFC, seulement 576 octets !!! A laisser sur /yes/ en effet !
Black hole detection: no
Active la détection d'appareils (routeurs ou autres) qui feraient que le Path MTU discovery retourne un MTU d'émission surdimensionné. Vu votre "souci" d'upload, ça vaudrait le coup d'essayer aussi avec cet option d'activée, juste pour voir...
Max duplicate ACKs: 3 TTL: 64
Ces deux là sont standards... Ok.
est-ce bon? merci.
Rien de choquant chez vous, à mon avis...
-- Herm
pedrito wrote:
réglage actuel après consultation des divers sites et groupes:
Bonsoir,
C'est pourtant pas mal du tout, comme réglage...
MTU:1500
Tcp receive window: 51800
C'est un peu étrange comme nombre pour le RWin, 51800 ...
Expérimentalement, chez moi, je me suis apperçu que l'on pouvait aller
jusqu'à 65535 sans effet secondaire, mais certains préconisent de prendre
une taille multiple du MSS, lequel, en TCP/IP, correspond au MTU - 40
octets.
MTU = 1500
MSS = 1460 (1500-40)
RWin = 1460 * n, avec, par exemple 64240 (nD), ...
51800 n'est pas divisible par 1460...
Enfin, ce n'est pas dramatique... J'utilise 65535 chez moi avec de bonnes
performances, et c'est pas non plus divisible par 1460 :-D...
Window scaling: yes
Cet option permet d'utiliser des RWin plus grands que 65535. Ce n'est
réelement utile que sur des liens à trés haute latence, au /ping/ dépassant
la seconde, quand il faut un RWin énorme. En ADSL, nul besoin d'avoir
recours à cet artifice, vous pouvez mettre /no/ ici.
Au passage, chez moi, l'activation de cet option m'avait sorti des scores de
transferts plus faibles que d'ordinaire...
Time stamping: no
En effet, pas reelement utile en ADSL. Cet option de marquage temporel des
paquets peut être utilisé pour affiner le calcul du temps moyen de parcours
des paquets, et d'affiner les timers de retransmission. Par défaut, TCP/IP
possède une limite basse d'attente de retransmission d'une seconde (quand
tous les autres artifices ont échoués), donc en ADSL où les temps sont de
l'ordre de 20 à 70 ms, ça ne servirait pas à grand chose !
Selective acks: yes
Un des trucs pour découvrir la perte d'un paquet et déclancher rapidement
une retransmission... /yes/.
Path MTU discovery: yes
Permet l'auto-détection du MTU optimum d'émission des paquets. Cela affecte
l'Upload. Si l'option est désactivée, l'ordinateur prends la valeur minimal
garantie par RFC, seulement 576 octets !!! A laisser sur /yes/ en effet !
Black hole detection: no
Active la détection d'appareils (routeurs ou autres) qui feraient que le
Path MTU discovery retourne un MTU d'émission surdimensionné. Vu votre
"souci" d'upload, ça vaudrait le coup d'essayer aussi avec cet option
d'activée, juste pour voir...
réglage actuel après consultation des divers sites et groupes:
Bonsoir,
C'est pourtant pas mal du tout, comme réglage...
MTU:1500 Tcp receive window: 51800
C'est un peu étrange comme nombre pour le RWin, 51800 ...
Expérimentalement, chez moi, je me suis apperçu que l'on pouvait aller jusqu'à 65535 sans effet secondaire, mais certains préconisent de prendre une taille multiple du MSS, lequel, en TCP/IP, correspond au MTU - 40 octets.
MTU = 1500 MSS = 1460 (1500-40) RWin = 1460 * n, avec, par exemple 64240 (nD), ...
51800 n'est pas divisible par 1460...
Enfin, ce n'est pas dramatique... J'utilise 65535 chez moi avec de bonnes performances, et c'est pas non plus divisible par 1460 :-D...
Window scaling: yes
Cet option permet d'utiliser des RWin plus grands que 65535. Ce n'est réelement utile que sur des liens à trés haute latence, au /ping/ dépassant la seconde, quand il faut un RWin énorme. En ADSL, nul besoin d'avoir recours à cet artifice, vous pouvez mettre /no/ ici.
Au passage, chez moi, l'activation de cet option m'avait sorti des scores de transferts plus faibles que d'ordinaire...
Time stamping: no
En effet, pas reelement utile en ADSL. Cet option de marquage temporel des paquets peut être utilisé pour affiner le calcul du temps moyen de parcours des paquets, et d'affiner les timers de retransmission. Par défaut, TCP/IP possède une limite basse d'attente de retransmission d'une seconde (quand tous les autres artifices ont échoués), donc en ADSL où les temps sont de l'ordre de 20 à 70 ms, ça ne servirait pas à grand chose !
Selective acks: yes
Un des trucs pour découvrir la perte d'un paquet et déclancher rapidement une retransmission... /yes/.
Path MTU discovery: yes
Permet l'auto-détection du MTU optimum d'émission des paquets. Cela affecte l'Upload. Si l'option est désactivée, l'ordinateur prends la valeur minimal garantie par RFC, seulement 576 octets !!! A laisser sur /yes/ en effet !
Black hole detection: no
Active la détection d'appareils (routeurs ou autres) qui feraient que le Path MTU discovery retourne un MTU d'émission surdimensionné. Vu votre "souci" d'upload, ça vaudrait le coup d'essayer aussi avec cet option d'activée, juste pour voir...
