Jump to content
XPEnology Community

DownloadStation débit bridé


Recommended Posts

Bonjour à tous,

 

Je poste ici un pb que je constate depuis que j'ai la fibre - je ne m'en étais jamais rendu compte auparavant car je n'avais pas d'abonnement chez Uptobox et encore moins quand j'avais l'adsl évidement.

Bref, lorsque je télécharge un fichier depuis Uptobox, le téléchargement est bridé à 25Mo/s. Pour certains vous allez me dire que bon c'est pas si mal, mais normalement je devrais être aux alentours de 100Mo/s (comme sur mon PC par exemple).

C'est un constat que je fais exclusivement avec DownloadStation et les téléchargements en http, je n'ai pas le pb avec les torrent, le débit est bien à 100Mo/s.

En regardant de plus près les processus, mon NAS surconsomme la CPU pour le téléchargement en cours et notamment le service lftp de DownloadStation qui monopolise tout.

 

Je suspecte un pb de trame http qui nécessite une vérification de chaque paquet. J'aurai envie de jouer avec le MTU (dont la valeur par défaut est 1500) du NAS mais j'ai peur de faire une bêtise. Avez-vous une idée ?

 

Pour info, le NAS est relié directement à ma Freebox Delta en gigabit avec un cable cat 7 et je me répête aucun pb avec des torrent, c'est exclusivement avec un download http (ou https).

PbDownloadStation.png

Link to comment
Share on other sites

J'ai pas la fibre chez moi, mais le NAS de backup que je stock chez ma mère a la fibre... 300Mo/s je crois.

Je viens d'y lancer la DL d'une ISO Linux :

byAZ30y.png

 

LDClGUR.png

 

C'est un HP N54L baremetal avec RP 7.1 DS3615xs.

 

Edit :

Je vais en effet plus vite avec les torrent :

mYmd1xA.png

 

Cependant, il faut aussi prendre en compte la bande passante du site en émission HTTP.

Peut-être n'ont-ils pas la capacité d'envoyer aussi vite que tu peux récupérer, ou bien ils brident délibérément pour garantir une qualité moyenne a tous les visiteurs... ?

 

Edit 2 :

En terme de charge CPU, en effet, le DL HTTP consomme beaucoup :

f0qpZZt.png

 

Dans la mesure où c'est un double coeur, j'imagine qu'il met à 100% un des 2 coeurs.

Edited by Orphée
Link to comment
Share on other sites

merci pour cet exercice. J'arrive de temps en temps à faire des pointe à 30-35Mo/s également. C'est donc bien une limitation de performance du N54L dans le cadre d'un download http.

 

Le truc, c'est que si il consomme autant c'est qu'il corrige des erreurs de transmissions, je ne vois pas d'autres explications. Je suis sur que si nous avions un CPU plus performant nous nous en rendrions pas compte. Donc à ce jour ma seule piste reste donc le MTU. A tester au risque de planter l'interface réseau du NAS^^

Link to comment
Share on other sites

Alors ne serai pas si catégorique...

 

J'ai oublié que j'ai un serveur Linux hébergé chez OVH.

Il est tout à fait capable de DL à 100Mo/s (je m'en sert comme seedbox entre autre...)

 

Et j'ai donc lancé le DL de l'ISO Linux dessus :

82bySVW.png

 

Au final, vitesse semblable à celle observée sur Download Station avec le NAS.

Je penche vraiment pour une limitation de bande passante côté serveur distant.

 

Il faudrait trouver un serveur distant dont on est sur qu'il upload à genre 100Mo/s.

 

Sinon c'est une limitation du protocole HTTP je sais pas... j'ai jamais creusé le sujet.

 

Edit : En utilisant aria2c qui permet de faire du téléchargement multiple sur une URL :

3Q2NFHr.png

 

92Mo/s

 

Edit 2 :

lftp serait à priori capable de faire du DL multiple :

https://www.cyberciti.biz/tips/linux-unix-download-accelerator.html

 

YLviuNZ.png

 

Quote

Please note that by using download accelerator you are going to put a load on remote host. Also note that lftp may not work with sites that do not support multi-source downloads or blocks such requests at firewall level.

 

Est-ce que Download Station utilise cette fonctionnalité, c'est peu probable.

Edited by Orphée
Link to comment
Share on other sites

Non comme je l'ai indiqué ce n'est pas le serveur distant qui pose pb. Le download du même fichier (ou d'autres peut importe) depuis un autre client (mon pc perso par exemple) plafonne bien à 100Mo/s.

C'est clairement le processus qui sature le CPU. Mais la raison est j'en suis quasiment sur est le checksum des paquets qui pour une raison qui m'échappe nécessite une correction des trames qui utilise toute la CPU et donc bloque le débit. J'ai eu un moment le même pb avec les transfert SMB (consommation CPU à 100%M et débit plafonné entre 10 et 15Mo/s) et cela venait du cable réseau RJ45 entre mon switch et le NAS qui était de mauvaise qualité semble-t-il. Pour être plus précis il avait un connecteur metallique qui devait avoir un tout petit défaut et je l'ai remplacé par un autre cable avec un connecteur en plastique et depuis RAS. Mais là pour lftp je ne pense pas que ce soit le cable mais plutot un pb de MTU ou qqchose du genre.

Link to comment
Share on other sites

Bonjour,

Un paramètre qui peut être intéressant dans le man de lftp (et qui doit pouvoir se fixer dans un fichier de config) :

ftp:ssl-protect-data (boolean)
              if  true,  request SSL connection for data transfers. This provides privacy and trans‐
              mission error correction. Was cpu-intensive on old CPUs. Default is true.

Si le téléchargement est en https (la quasi totalité des serveurs le sont), ça pourrait expliquer le délai et la charge CPU.

 

Bons tests

Jacques

  • Like 1
Link to comment
Share on other sites

 

Le 27/08/2022 à 14:09, JacquesF a dit :

Bonjour,

Un paramètre qui peut être intéressant dans le man de lftp (et qui doit pouvoir se fixer dans un fichier de config) :

ftp:ssl-protect-data (boolean)
              if  true,  request SSL connection for data transfers. This provides privacy and trans‐
              mission error correction. Was cpu-intensive on old CPUs. Default is true.

Si le téléchargement est en https (la quasi totalité des serveurs le sont), ça pourrait expliquer le délai et la charge CPU.

 

Bons tests

Jacques


Très bonne piste mais hélas sans succès. Juste pour préciser mon test j’ai modifié le fichier /etc/lftp.conf puis redémarrer le service DownloadStation et relancer un nouveau téléchargement mais toujours pareil.

Link to comment
Share on other sites

Bonjour,

Dommage... peut-être vérifier dans la ligne de commande (via un ps et je ne sais plus si l'option -w passe avec busybox, j'en doute) auels paramètres sont utilisés lors du téléchargement, si c'est visible.

Autrement dans /proc/PIDduProgramme on peut trouver la ligne de commande.

 

Bons tests

Jacques

Link to comment
Share on other sites

Voici la ligne de commande qui est lancée lors d'un téléchargement https :

 

root@NAS:~# ps -ef | grep lftp

Downloa+ 14286     1 72 10:35 ?        00:00:17 /var/packages/DownloadStation/target/bin/lftp --norc -c set ssl:verify-certificate false;set syn
o:task-id 1158;set syno:username niko44;set net:timeout 30;set net:max-retries 3;set http:user-agent "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/5
35 (KHTML, like Gecko) Chrome/14 Safari/535";set xfer:log false;pget -c -n 4 -O /volume1/@download/1158 "https://www79.uptobox.com/dl/BLABLABLA.iso";


image.thumb.png.233caa992a099bde69f8e512a99b93a1.png

 

J'ai l'impression que DownloadStation utilise sa propre configuration de lftp sans tenir compte du fichier /etc/lftp.conf car l'option ssl:verify-certificate false n'est pas dans le fichier de config alors que ce n'est pas la valeur par défaut. De même je ne vois pas d'autre fichier de config associé dans lequel je pourrai mettre ton flag.

Link to comment
Share on other sites

Pas évident à trouver, mais en principe les paquets (pour ce que j'en ai vu) placent leur config dans /var/package.

Je tenterai ça :

grep -R "ssl:verify-certificate" /var 2>/dev/null

L'option -R suit les liens symboliques au cas où...

Ça devrait te dire dans quel fichier se trouve cette option, et par là le modifier éventuellement.

 

Jacques

  • Like 1
Link to comment
Share on other sites

J'avais déjà essayé de regarder si il y avait des fichiers de conf qui serait utiliser par lftp mais hélas aucun fichier autre que le binaire lftp ne contient ces paramètres...

J'ai l'impression que c'est un binaire spécifique dédié à DownloadStation pré-compilé avec ces instructions et du coup ce n'est pas modifiable - dommage :(

Link to comment
Share on other sites

Tu peux tester en renommant le fichier dans le même répertoire, ou en faisant un lien physique au lien d'un lien symbolique (mais dans ce cas, on doit être sur la même partition).

Tester avant le binaire en ligne de commande pour voir s'il ne provoque pas un plantage (architecture ou dépendances incorrectes).

 

J.

Link to comment
Share on other sites

La réponse à la commande semble indiquer que la cible et la destination sont les mêmes fichiers.

La commande 'ls -li' indique dans le premier champ le n° d'inode associé au fichier, si ce sont les mêmes sur les 2 c'est effectivement un lien physique.

Dans ce cas, renommer les 2 par sécurité et copie le nouveau programme aux deux emplacements sous le nom d'origine permettra au moins de faire un test, ceci sous réserve que le programme fonctionne effectivement dans l'environnement du NAS.

Il faudra peut-être regarder les droits étendus qui peuvent être associés au fichier, mais je ne suis pas certain que ce soit utilisé pour les binaires.

Ça l'est pour les dossiers partagés en tout cas.

 

Jacques

Link to comment
Share on other sites

Les différences entre les liens physiques et symboliques :

[jacques@jacques test]$ ls -li
total 0
132252199 lrwxrwxrwx 1 jacques jacques 4 sept.  2 10:41 titi -> toto
132252192 -rw-r--r-- 2 jacques jacques 0 sept.  2 10:41 toto
132252192 -rw-r--r-- 2 jacques jacques 0 sept.  2 10:41 tutu

Les 3 noms pointent vers le même fichier (vide) toto.

titi est un lien symbolique (visible par le "l" qui précède les droits (en principe toujours 777, soit rwxrwxrwx, car ils sont vérifiés sur le fichier cible).

tutu est un lien physique vers toto car le numéro d'inode 132252192 est identique pour les deux fichiers. La taille du fichier est la même (0 octet) dans ce cas.

Dans le cas d'un lien symbolique, la taille du lien correspond en fait à la longueur de la chaîne de caractères qui contient le chemin vers le fichier (ici le lien est relatif, donc toto faisant 4 caractères, le lien en fait 4).

Un lien physique ne peut être créé que dans un même système de fichiers (en fait chaque nom de fichier pointe vers le même emplacement indiqué par l'inode).

Un lien symbolique pointe où l'on veut, même vers des montages réseau.

La différence de fonctionnement est que pour un lien symbolique, si le fichier cible disparaît, le lien est mort, alors que pour un lien physique le fichier continue d'exister tant qu'il existe un nom (une référence) qui pointe vers lui (le nombre de lien est indiqué dans le 3ème champ dans mon exemple, ici 2).

 

Dans ton cas, il faut vérifier que le programme lftp est bien soit la cible d'un lien symbolique (facilement visible avec "ls -l") ou  celle d'un lien physique (infos à afficher pour chaque instance du programme), dans ce cas soit le n° d'inode est à vérifier (par "ls -li") soit le nombre de liens indiqué dans le 2ème ou 3ème champ de la commande "ls" selon qu'on utilise les options "-l" ou "-li".

 

Jacques

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...