[Q] Diminution de débit ftp de Freebox HD vers mac
15 réponses
JiPaul
Bonjour =E0 tous,
Souhaitant faire de la place sur ma FB HD afin de pouvoir enregistrer
la c=E9r=E9monie des jeux que je ne peux voir en direct, je viens de
constater le ph=E9nom=E8ne suivant :
(J'utilise Fetch version 5.3 et je suis sous Tiger 10.4.11)
Lorsque je commence =E0 t=E9l=E9charger par FTP un (ou plusieurs) fichiers
depuis la FBHD, le d=E9bit est d'environ 1,5 =E0 2 Mo/s. Un fichier d'
1,5Go (une heure) devrait donc =EAtre t=E9l=E9charg=E9 (d'apr=E8s Fetch) en=
une
quinzaine de minutes. Mais au fur et =E0 mesure que le temps passe, le
d=E9bit ne cesse de diminuer jusqu'=E0 une ou deux centaines de Ko/s, soit
dix fois plus lent, et donc dix fois plus de temps. Si alors
j'interromps le t=E9l=E9chargement, et le relance (en double-cliquant sur
le fichier partiel obtenu sur le dd), le d=E9bit reprends la valeur
initiale, puis recommence de diminuer.
Suis-je le seul dans ce cas ?
Qu'en est-il avec d'autres logiciels client ftp ?
Y a-t-il un moyen de corriger le d=E9faut ?
Merci d'avance pour vos r=E9ponses que j'esp=E8re nombreuses.
Je viens de faire l'essai avec FileZilla (recommandé par Free)(version 3.06 pour OSX 10.4.11) 3600 Mo en 48 mn et débit affiché 1,2 Mo/sec
-- Gérard FLEUROT Remplacer le chiffre par la lettre correspondante.
blanc
Anonyme wrote:
Je pense pas que ce soit un problème de débit qui chute, mais de calcul incorrect du débit.
Non, non, je vois bien avec NetMonitor que le débit chute effectivement. Et si je ne fais pas la manip indiquée (arrêt et relancement toutes les 4 ou 5 minutes) le fichier met dix fois plus de temps à se télécharger que si je la fais.
Tu peux essayer avec CyberDuck qui est assez fiable là-dessus.
J'essayerai dès que possible.
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Anonyme <jayce@mosx.org> wrote:
Je pense pas que ce soit un problème de débit qui chute, mais de calcul
incorrect du débit.
Non, non, je vois bien avec NetMonitor que le débit chute effectivement.
Et si je ne fais pas la manip indiquée (arrêt et relancement toutes les
4 ou 5 minutes) le fichier met dix fois plus de temps à se télécharger
que si je la fais.
Tu peux essayer avec CyberDuck qui est assez fiable là-dessus.
J'essayerai dès que possible.
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Je pense pas que ce soit un problème de débit qui chute, mais de calcul incorrect du débit.
Non, non, je vois bien avec NetMonitor que le débit chute effectivement. Et si je ne fais pas la manip indiquée (arrêt et relancement toutes les 4 ou 5 minutes) le fichier met dix fois plus de temps à se télécharger que si je la fais.
Tu peux essayer avec CyberDuck qui est assez fiable là-dessus.
J'essayerai dès que possible.
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
blanc
Fleuger wrote:
Je viens de faire l'essai avec FileZilla (recommandé par Free)(version 3.06 pour OSX 10.4.11)
J'essayerai celui-ci aussi
3600 Mo en 48 mn et débit affiché 1,2 Mo/sec
Ce débit est-il affiché ? toujours le même tous le temps du téléchargement ?
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Fleuger <g5fleurot@free.fr> wrote:
Je viens de faire l'essai avec FileZilla (recommandé par Free)(version
3.06 pour OSX 10.4.11)
J'essayerai celui-ci aussi
3600 Mo en 48 mn et débit affiché 1,2 Mo/sec
Ce débit est-il affiché ? toujours le même tous le temps du
téléchargement ?
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Je viens de faire l'essai avec FileZilla (recommandé par Free)(version 3.06 pour OSX 10.4.11)
J'essayerai celui-ci aussi
3600 Mo en 48 mn et débit affiché 1,2 Mo/sec
Ce débit est-il affiché ? toujours le même tous le temps du téléchargement ?
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Eric Levenez
Le 13/08/08 22:57, dans <1ilmvfp.h6apq19um8bzN%, « JiPaul » a écrit :
Non, non, je vois bien avec NetMonitor que le débit chute effectivement. Et si je ne fais pas la manip indiquée (arrêt et relancement toutes les 4 ou 5 minutes) le fichier met dix fois plus de temps à se télécharger que si je la fais.
Si je me rappelle bien, la fenêtre de transfert du protocole TCP est initialisée à l'ouverture de la session. Sa taille permet d'émettre rapidement des données (taille de la fenêtre), sans attendre les acquittements (pour chaque paquet émis dans cette fenêtre). En cas de problème de transmission, la taille de la fenêtre est réduite. Et je ne pense pas qu'elle puisse réaugmenter. Cela permet normalement une adaptation automatique des débits que la ligne soit à 1 kb/s ou 1 Gb/s. Mais si la ligne est mauvaise on a des paquets perdus (que cela soit dû au réseau, à un hub surchargé, ou à un câble mauvais...) et donc le débit baisse sans arrêt jusqu'à la fenêtre minimum TCP (de 0 où chaque paquet doit être acquitté avant l'émission du suivant). La valeur d'initialisation de la fenêtre est le champ "net.inet.tcp.recvspace" de sysctl. Quand la ligne est bonne la fenêtre ne change pas et le débit est maximum grâce à la bufferisation faite par les fenêtres d'émission et de réception.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 13/08/08 22:57, dans <1ilmvfp.h6apq19um8bzN%blanc@empty.org>, « JiPaul »
<blanc@empty.org> a écrit :
Non, non, je vois bien avec NetMonitor que le débit chute effectivement.
Et si je ne fais pas la manip indiquée (arrêt et relancement toutes les
4 ou 5 minutes) le fichier met dix fois plus de temps à se télécharger
que si je la fais.
Si je me rappelle bien, la fenêtre de transfert du protocole TCP est
initialisée à l'ouverture de la session. Sa taille permet d'émettre
rapidement des données (taille de la fenêtre), sans attendre les
acquittements (pour chaque paquet émis dans cette fenêtre). En cas de
problème de transmission, la taille de la fenêtre est réduite. Et je ne
pense pas qu'elle puisse réaugmenter. Cela permet normalement une adaptation
automatique des débits que la ligne soit à 1 kb/s ou 1 Gb/s. Mais si la
ligne est mauvaise on a des paquets perdus (que cela soit dû au réseau, à un
hub surchargé, ou à un câble mauvais...) et donc le débit baisse sans arrêt
jusqu'à la fenêtre minimum TCP (de 0 où chaque paquet doit être acquitté
avant l'émission du suivant). La valeur d'initialisation de la fenêtre est
le champ "net.inet.tcp.recvspace" de sysctl. Quand la ligne est bonne la
fenêtre ne change pas et le débit est maximum grâce à la bufferisation faite
par les fenêtres d'émission et de réception.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 13/08/08 22:57, dans <1ilmvfp.h6apq19um8bzN%, « JiPaul » a écrit :
Non, non, je vois bien avec NetMonitor que le débit chute effectivement. Et si je ne fais pas la manip indiquée (arrêt et relancement toutes les 4 ou 5 minutes) le fichier met dix fois plus de temps à se télécharger que si je la fais.
Si je me rappelle bien, la fenêtre de transfert du protocole TCP est initialisée à l'ouverture de la session. Sa taille permet d'émettre rapidement des données (taille de la fenêtre), sans attendre les acquittements (pour chaque paquet émis dans cette fenêtre). En cas de problème de transmission, la taille de la fenêtre est réduite. Et je ne pense pas qu'elle puisse réaugmenter. Cela permet normalement une adaptation automatique des débits que la ligne soit à 1 kb/s ou 1 Gb/s. Mais si la ligne est mauvaise on a des paquets perdus (que cela soit dû au réseau, à un hub surchargé, ou à un câble mauvais...) et donc le débit baisse sans arrêt jusqu'à la fenêtre minimum TCP (de 0 où chaque paquet doit être acquitté avant l'émission du suivant). La valeur d'initialisation de la fenêtre est le champ "net.inet.tcp.recvspace" de sysctl. Quand la ligne est bonne la fenêtre ne change pas et le débit est maximum grâce à la bufferisation faite par les fenêtres d'émission et de réception.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
blanc
Eric Levenez wrote:
Si je me rappelle bien, la fenêtre de transfert du protocole TCP est initialisée à l'ouverture de la session. Sa taille permet d'émettre rapidement des données (taille de la fenêtre), sans attendre les acquittements (pour chaque paquet émis dans cette fenêtre). En cas de problème de transmission, la taille de la fenêtre est réduite. Et je ne pense pas qu'elle puisse réaugmenter. Cela permet normalement une adaptation automatique des débits que la ligne soit à 1 kb/s ou 1 Gb/s. Mais si la ligne est mauvaise on a des paquets perdus (que cela soit dû au réseau, à un hub surchargé, ou à un câble mauvais...) et donc le débit baisse sans arrêt jusqu'à la fenêtre minimum TCP (de 0 où chaque paquet doit être acquitté avant l'émission du suivant). La valeur d'initialisation de la fenêtre est le champ "net.inet.tcp.recvspace" de sysctl. Quand la ligne est bonne la fenêtre ne change pas et le débit est maximum grâce à la bufferisation faite par les fenêtres d'émission et de réception.
OK. Mais je ne vois pas pourquoi la ligne serait mauvaise dans le cas de la FB HD, connectée en local à la FB par un cable éthernet (100Mbps ?), et celle-ci connectée de même à mon ordi.
D'ailleurs je trouve que même le débit max que j'obtiens (2Mbps environ) est vraiment faible pour une connexion locale, même s'il est vrai que les commandes transitent par Free, ce qui lui permet de filtrer les fichiers visibles sur la FBHD depuis mon mac.
Je soupçonne un bridage par Free, et c'est pourquoi j'attends d'autres essais par les freenautes qui nous lisent pour confirmer ou infirmer ce point.
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Eric Levenez <usenet@levenez.com> wrote:
Si je me rappelle bien, la fenêtre de transfert du protocole TCP est
initialisée à l'ouverture de la session. Sa taille permet d'émettre
rapidement des données (taille de la fenêtre), sans attendre les
acquittements (pour chaque paquet émis dans cette fenêtre). En cas de
problème de transmission, la taille de la fenêtre est réduite. Et je ne
pense pas qu'elle puisse réaugmenter. Cela permet normalement une adaptation
automatique des débits que la ligne soit à 1 kb/s ou 1 Gb/s. Mais si la
ligne est mauvaise on a des paquets perdus (que cela soit dû au réseau, à un
hub surchargé, ou à un câble mauvais...) et donc le débit baisse sans arrêt
jusqu'à la fenêtre minimum TCP (de 0 où chaque paquet doit être acquitté
avant l'émission du suivant). La valeur d'initialisation de la fenêtre est
le champ "net.inet.tcp.recvspace" de sysctl. Quand la ligne est bonne la
fenêtre ne change pas et le débit est maximum grâce à la bufferisation faite
par les fenêtres d'émission et de réception.
OK. Mais je ne vois pas pourquoi la ligne serait mauvaise dans le cas de
la FB HD, connectée en local à la FB par un cable éthernet (100Mbps ?),
et celle-ci connectée de même à mon ordi.
D'ailleurs je trouve que même le débit max que j'obtiens (2Mbps environ)
est vraiment faible pour une connexion locale, même s'il est vrai que
les commandes transitent par Free, ce qui lui permet de filtrer les
fichiers visibles sur la FBHD depuis mon mac.
Je soupçonne un bridage par Free, et c'est pourquoi j'attends d'autres
essais par les freenautes qui nous lisent pour confirmer ou infirmer ce
point.
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Si je me rappelle bien, la fenêtre de transfert du protocole TCP est initialisée à l'ouverture de la session. Sa taille permet d'émettre rapidement des données (taille de la fenêtre), sans attendre les acquittements (pour chaque paquet émis dans cette fenêtre). En cas de problème de transmission, la taille de la fenêtre est réduite. Et je ne pense pas qu'elle puisse réaugmenter. Cela permet normalement une adaptation automatique des débits que la ligne soit à 1 kb/s ou 1 Gb/s. Mais si la ligne est mauvaise on a des paquets perdus (que cela soit dû au réseau, à un hub surchargé, ou à un câble mauvais...) et donc le débit baisse sans arrêt jusqu'à la fenêtre minimum TCP (de 0 où chaque paquet doit être acquitté avant l'émission du suivant). La valeur d'initialisation de la fenêtre est le champ "net.inet.tcp.recvspace" de sysctl. Quand la ligne est bonne la fenêtre ne change pas et le débit est maximum grâce à la bufferisation faite par les fenêtres d'émission et de réception.
OK. Mais je ne vois pas pourquoi la ligne serait mauvaise dans le cas de la FB HD, connectée en local à la FB par un cable éthernet (100Mbps ?), et celle-ci connectée de même à mon ordi.
D'ailleurs je trouve que même le débit max que j'obtiens (2Mbps environ) est vraiment faible pour une connexion locale, même s'il est vrai que les commandes transitent par Free, ce qui lui permet de filtrer les fichiers visibles sur la FBHD depuis mon mac.
Je soupçonne un bridage par Free, et c'est pourquoi j'attends d'autres essais par les freenautes qui nous lisent pour confirmer ou infirmer ce point.
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
g5fleurot
JiPaul wrote:
Ce débit est-il affiché ? toujours le même tous le temps du téléchargement ?
Oui. Variable au début, puis se stabilise.
Vue de la fenêtre de transfert : <http://cjoint.com/?ioiyhlPPs2>
Lien pour la 3.06 (les plus récentes ne fonctionnent pas sous Tiger) <http://sourceforge.net/project/showfiles.php?group_id!558&package_id 15149&release_idW2633> -- Gérard FLEUROT Remplacer le chiffre par la lettre correspondante.
JiPaul <blanc@empty.org> wrote:
Ce débit est-il affiché ? toujours le même tous le temps du
téléchargement ?
Oui. Variable au début, puis se stabilise.
Vue de la fenêtre de transfert :
<http://cjoint.com/?ioiyhlPPs2>
Lien pour la 3.06 (les plus récentes ne fonctionnent pas sous Tiger)
<http://sourceforge.net/project/showfiles.php?group_id!558&package_id 15149&release_idW2633>
--
Gérard FLEUROT <g5fleurot@free.fr>
Remplacer le chiffre par la lettre correspondante.
Ce débit est-il affiché ? toujours le même tous le temps du téléchargement ?
Oui. Variable au début, puis se stabilise.
Vue de la fenêtre de transfert : <http://cjoint.com/?ioiyhlPPs2>
Lien pour la 3.06 (les plus récentes ne fonctionnent pas sous Tiger) <http://sourceforge.net/project/showfiles.php?group_id!558&package_id 15149&release_idW2633> -- Gérard FLEUROT Remplacer le chiffre par la lettre correspondante.
blanc
Serge Horrent wrote:
Je le soupçonne également ! Mon débit (Dégroupage total, ADSL2+, 1200m du DSLAM avec faible affaiblissement, Freebox V4) a bien chuté depuis quelques semaines et dépasse rarement les 3 Mb/s (3,358 à l'instant), au lieu des 12 à 18 constatés depuis des mois après le passage de mon DSLAM à l'ADSL2+.
Tu parles bien du débit FBHD ---> ordi (par ftp, et normalement sans passer par le DSLAM) ?
Constates-tu comme moi une remontée à 18 Mbs quand tu arrêtes le transfert et que tu le relances ? -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Serge Horrent <minfiu@free.fr.invalid> wrote:
Je le soupçonne également ! Mon débit (Dégroupage total, ADSL2+, 1200m
du DSLAM avec faible affaiblissement, Freebox V4) a bien chuté depuis
quelques semaines et dépasse rarement les 3 Mb/s (3,358 à l'instant), au
lieu des 12 à 18 constatés depuis des mois après le passage de mon DSLAM
à l'ADSL2+.
Tu parles bien du débit FBHD ---> ordi (par ftp, et normalement sans
passer par le DSLAM) ?
Constates-tu comme moi une remontée à 18 Mbs quand tu arrêtes le
transfert et que tu le relances ?
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Je le soupçonne également ! Mon débit (Dégroupage total, ADSL2+, 1200m du DSLAM avec faible affaiblissement, Freebox V4) a bien chuté depuis quelques semaines et dépasse rarement les 3 Mb/s (3,358 à l'instant), au lieu des 12 à 18 constatés depuis des mois après le passage de mon DSLAM à l'ADSL2+.
Tu parles bien du débit FBHD ---> ordi (par ftp, et normalement sans passer par le DSLAM) ?
Constates-tu comme moi une remontée à 18 Mbs quand tu arrêtes le transfert et que tu le relances ? -- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
blanc
Fleuger wrote:
Oui. Variable au début, puis se stabilise.
Vue de la fenêtre de transfert : <http://cjoint.com/?ioiyhlPPs2>
Lien pour la 3.06 (les plus récentes ne fonctionnent pas sous Tiger) <http://sourceforge.net/project/showfiles.php?group_id!558&package_id > 15149&release_idW2633>
OK. Merci. J'essayerai...
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Fleuger <g5fleurot@free.fr> wrote:
Oui. Variable au début, puis se stabilise.
Vue de la fenêtre de transfert :
<http://cjoint.com/?ioiyhlPPs2>
Lien pour la 3.06 (les plus récentes ne fonctionnent pas sous Tiger)
<http://sourceforge.net/project/showfiles.php?group_id!558&package_id > 15149&release_idW2633>
OK. Merci. J'essayerai...
--
JiPaul.
/ /--/--//\ Jean-Paul Blanc
|/| L |\ quelquepart en (somewhere in)
/|| = |||\ FRANCE
Vue de la fenêtre de transfert : <http://cjoint.com/?ioiyhlPPs2>
Lien pour la 3.06 (les plus récentes ne fonctionnent pas sous Tiger) <http://sourceforge.net/project/showfiles.php?group_id!558&package_id > 15149&release_idW2633>
OK. Merci. J'essayerai...
-- JiPaul. / /--/--// Jean-Paul Blanc |/| L | quelquepart en (somewhere in) /|| = ||| FRANCE
Huron
On 8 août, 14:38, JiPaul wrote:
Bonjour à tous,
Souhaitant faire de la place sur ma FB HD afin de pouvoir enregistrer la cérémonie des jeux que je ne peux voir en direct, je viens de constater le phénomène suivant :
(J'utilise Fetch version 5.3 et je suis sous Tiger 10.4.11)
Lorsque je commence à télécharger par FTP un (ou plusieurs) fichier s depuis la FBHD, le débit est d'environ 1,5 à 2 Mo/s. Un fichier d' 1,5Go (une heure) devrait donc être téléchargé (d'après Fetch) en une quinzaine de minutes. Mais au fur et à mesure que le temps passe, le débit ne cesse de diminuer jusqu'à une ou deux centaines de Ko/s, soi t dix fois plus lent, et donc dix fois plus de temps. Si alors j'interromps le téléchargement, et le relance (en double-cliquant sur le fichier partiel obtenu sur le dd), le débit reprends la valeur initiale, puis recommence de diminuer.
Suis-je le seul dans ce cas ? Qu'en est-il avec d'autres logiciels client ftp ? Y a-t-il un moyen de corriger le défaut ?
Merci d'avance pour vos réponses que j'espère nombreuses.
JiPaul.
Ca depend la nature du serveur sur lequel vous etes logué.... C'est un secret de polichinelle certes mais pour optimiser la bande passante les FAIs en interne on des table de routage regulierement mis a jour... En gros le debit sera assuré si le site est transparent (contenu) ou si c'est un service payant... A noté aussi l'explication du buffer qui pendant longtemps a fait croire a quelques écervellés que leur ADSL devenait fantasmagorique pendant les premieres secondes de branchement...
Question : 3go de données .... C'est quoi un film de vacances ou une distribution Yellow dog pour Mac ?
On 8 août, 14:38, JiPaul <bl...@iut.u-clermont1.fr> wrote:
Bonjour à tous,
Souhaitant faire de la place sur ma FB HD afin de pouvoir enregistrer
la cérémonie des jeux que je ne peux voir en direct, je viens de
constater le phénomène suivant :
(J'utilise Fetch version 5.3 et je suis sous Tiger 10.4.11)
Lorsque je commence à télécharger par FTP un (ou plusieurs) fichier s
depuis la FBHD, le débit est d'environ 1,5 à 2 Mo/s. Un fichier d'
1,5Go (une heure) devrait donc être téléchargé (d'après Fetch) en une
quinzaine de minutes. Mais au fur et à mesure que le temps passe, le
débit ne cesse de diminuer jusqu'à une ou deux centaines de Ko/s, soi t
dix fois plus lent, et donc dix fois plus de temps. Si alors
j'interromps le téléchargement, et le relance (en double-cliquant sur
le fichier partiel obtenu sur le dd), le débit reprends la valeur
initiale, puis recommence de diminuer.
Suis-je le seul dans ce cas ?
Qu'en est-il avec d'autres logiciels client ftp ?
Y a-t-il un moyen de corriger le défaut ?
Merci d'avance pour vos réponses que j'espère nombreuses.
JiPaul.
Ca depend la nature du serveur sur lequel vous etes logué....
C'est un secret de polichinelle certes mais pour optimiser la bande
passante les FAIs en interne on des table de routage regulierement mis
a jour... En gros le debit sera assuré si le site est transparent
(contenu) ou si c'est un service payant... A noté aussi l'explication
du buffer qui pendant longtemps a fait croire a quelques écervellés
que leur ADSL devenait fantasmagorique pendant les premieres secondes
de branchement...
Question : 3go de données .... C'est quoi un film de vacances ou une
distribution Yellow dog pour Mac ?
Souhaitant faire de la place sur ma FB HD afin de pouvoir enregistrer la cérémonie des jeux que je ne peux voir en direct, je viens de constater le phénomène suivant :
(J'utilise Fetch version 5.3 et je suis sous Tiger 10.4.11)
Lorsque je commence à télécharger par FTP un (ou plusieurs) fichier s depuis la FBHD, le débit est d'environ 1,5 à 2 Mo/s. Un fichier d' 1,5Go (une heure) devrait donc être téléchargé (d'après Fetch) en une quinzaine de minutes. Mais au fur et à mesure que le temps passe, le débit ne cesse de diminuer jusqu'à une ou deux centaines de Ko/s, soi t dix fois plus lent, et donc dix fois plus de temps. Si alors j'interromps le téléchargement, et le relance (en double-cliquant sur le fichier partiel obtenu sur le dd), le débit reprends la valeur initiale, puis recommence de diminuer.
Suis-je le seul dans ce cas ? Qu'en est-il avec d'autres logiciels client ftp ? Y a-t-il un moyen de corriger le défaut ?
Merci d'avance pour vos réponses que j'espère nombreuses.
JiPaul.
Ca depend la nature du serveur sur lequel vous etes logué.... C'est un secret de polichinelle certes mais pour optimiser la bande passante les FAIs en interne on des table de routage regulierement mis a jour... En gros le debit sera assuré si le site est transparent (contenu) ou si c'est un service payant... A noté aussi l'explication du buffer qui pendant longtemps a fait croire a quelques écervellés que leur ADSL devenait fantasmagorique pendant les premieres secondes de branchement...
Question : 3go de données .... C'est quoi un film de vacances ou une distribution Yellow dog pour Mac ?
