[resolu]Bande passante (question complémentaire sur le QoS)

Support Debian
#1

J’utilise un script de QoS personnel qui marche sans problème, il y a eu plusieurs versions suivant l’usage du serveur. Mais tous ces scripts prenaient comme paramètres une estimation de la bande passante. Or chez Free, le moins qu’on puisse dire c’est que l’upload fait le yoyo, voici les caractéristiques de ligne fourni par Free des derniers jours:

[quote]Attainable bitrate 506 kb/s (up) 6300 kb/s (down)
Attainable bitrate 196 kb/s (up) 4920 kb/s (down)
Attainable bitrate 431 kb/s (up) 6384 kb/s (down)
Attainable bitrate 328 kb/s (up) 6304 kb/s (down)
Attainable bitrate 477 kb/s (up) 6272 kb/s (down)
Attainable bitrate 427 kb/s (up) 6000 kb/s (down)
Attainable bitrate 490 kb/s (up) 6116 kb/s (down)
Attainable bitrate -28102 kb/s (up) 5936 kb/s (down)
Attainable bitrate -28155 kb/s (up) 6004 kb/s (down)
Attainable bitrate 251 kb/s (up) 6216 kb/s (down)
Attainable bitrate 236 kb/s (up) 6264 kb/s (down)
Attainable bitrate 244 kb/s (up) 6280 kb/s (down)
Attainable bitrate 332 kb/s (up) 6436 kb/s (down)
[/quote]
(caractéristiques récupérées tous les jours par un script perso sur le site de Free).
C’est n’importe quoi donc (un débit de -28102 kb/s me laisse rêveur! ).
Je n’ai pas réussi à faire un script satisfaisant fonctionnant sur des tests réguliers d’upload qui marche convenablement (à chaque fois, je me suis retrouvé au moins une fois toute une journée avec un upload bloqué par le script à 5K/s). Du coup, j’en suis réduit à modifier les paramètres à la main. Quelqu’un a-t-il trouvé une solution qui marche? :slightly_smiling: [/code]

#2

hello,

Là tu essaie de te baser par rapport a ton FAI, essaie plutot de te baser sur tes priortiés a toi, c’est a dire peut immporte le débit les priorités seront les mêmes et proportionnel au débit.

#3

Pas tout à fait, le QoS partage une bande passante donnée en plusieurs plages indépendantes sur lesquelles tu mets des priorités. Ce que tu suggères et que j’ai fait (sauf une fois dans un cas critique) a été de prendre une seule plage totalisant toute la bande passante et de mettre 7 files de priorités dessus, file 0 pour le ping, file 1 pour les petits paquets, le ssh, etc…
Le problème est que tu dois quand même indiquer l’upload total. En gros si tu disposes d’un upload de 50K/s, tu as intérêt à gérer sur 45K/s(en gros upload max -10%) pour avoir une gestion convenable. Sinon j’ai effectivement constaté que ça bouchonne et tout se passe comme si tu n’avais plus de QoS.
Usuellement mon upload chez Free est entre 46K/s à 52K/s, j’ai donc mis un upload à 42K/s et ça marche en général bien. Seulement depuis quelques semaines, c’est le bazar complet et aujourd’hui par exemple, l’upload max est de 35K/s. Si je déclare un upload de 42K/s à mon script, je me retrouve avec des pings à 300 et mon script ne sert à rien. Si je le met à 30K/s, là ça marche bien. Je cherche desespéremment comment automatiser ça.

#4

hello,

Comment fais tu pour récupéré ton débit d’upload ? y aurait pas moyen de le “cut(é)” et de l’inserer dynamiquement, le tout geré par une cron toute les minutes ?

#5

C’est ce que je voudrais faire mais comment tu évalue l’upload?

  1. Le site de Free: c’est n’importe quoi
  2. Une mesure directe: Je me suis retrouvé avec des uploads mesurés à 6K/s: lorsque la bande passante est saturée, le débit varie beaucoup (en tout ca sur ma carte), dès qu’il y a du QoS, le débit en upload devient très régulier (je suis sûr d’ailleurs que en moyenne, même en calant à -10%, j’y gagne)

Je sèche sur cette mesure.

#6

[quote=“fran.b”]C’est ce que je voudrais faire mais comment tu évalue l’upload?

  1. Le site de Free: c’est n’importe quoi
  2. Une mesure directe: Je me suis retrouvé avec des uploads mesurés à 6K/s: lorsque la bande passante est saturée, le débit varie beaucoup (en tout ca sur ma carte), dès qu’il y a du QoS, le débit en upload devient très régulier (je suis sûr d’ailleurs que en moyenne, même en calant à -10%, j’y gagne)

Je sèche sur cette mesure.[/quote]Tu peux peut être utiliser des compteurs fournissant le volume total transmis RX bytes et TX bytes dans ifconfig, par ex, si tu ne trouves pas la même info dans /proc, et baser dessus ton calcul de débit en la lisant à intervalle régulier pour calculer un debit moyen réel un peu lissé et reconfigurer à la volée ton QOS ?
(tu vois ce que je veux dire ?)

#7

regardes dans /sys/class/net/eth0/statistics/ (pour eth0, par exemple)

#8

Le problème est que je ne dois pas faire trop de mesures: la mesure pour être valable doit prendre un peu de temps et ne peut se faire qu’avec le script coupé (puisqu’il limite l’upload…). Existe-t-il un serveur “puit” qui digère tout ce qu’on lui envoit sans rien en faire pour faire ce type de mesure? (Jusqu’à présent je prenais d’autres serveurs qui peuvent être eux même en saturation de download (plus rare mais bon…). Je vais voir tout ça…

#9

Je comprends de moins en moins ce que tu veux:
tu ne fais pas de mesure, tu n’envoies aucun paquet, tu récupères juste une donnée dans le noyau de temps en temps…

Parcequ’il y a aussi peut être la possibilité d’utiliser iptables -m limit (ou voisin), pour déclencher une operation en “userspace” quand le debit change de tranche (en envoyant le paquet dans une chaine USER, déclenchant ainsi une reconfiguration du QOS, avant de renvoyer le paquet dans le flux).

Tu as aussi ttcp pour faire des mesures, mais ça fait du traffic durant la mesure.

Enfin bon. J’arrète parceque je ne comprends pas.

#10

J’ai compris ce que je ne comprenais pas: tu ne peux travailler qu’avec le debit max réel, mais tu n’as accés qu’au debit courant réel.

Mais rien ne t’empêche de travailler en limitant le debit en permanence, et en reajustant cette limite vers le haut ou vers le bas quand tu vois qu’elle est “prés” ou “loin” d’être atteinte:

  • tu fais ton calcul par intervalle sans envoyer de paquet en calculant juste un débit moyen sur la base de ce que tu as dans /sys/class/net/eth0/statistics/rx_bytes
  • si ton debit calculé est à -de 5% du debit max réel supposé, tu supposes que le debit max réel a augmenté et tu le le remonte d’un cran, sauf quand il atteind le debit max theorique -10% (là, on atteind la saturation réelle)
  • si ton debit calculé est infèrieur mettons à 15% de ton debit max supposé, tu supposes que le debit max réel est alors en baisse, tu ajustes dans ce sens
  • si le debit max authorisé a changé, tu relance immédiatement pour suivre la variation de débit, sinon, tu attends un nouvel intervalle complet en considèrant que le debit est stable.
    Ca merite peut être d’être testé et affiné, non ?
#11

[quote=“MattOTop”]Je comprends de moins en moins ce que tu veux:
tu ne fais pas de mesure, tu n’envoies aucun paquet, tu récupères juste une donnée dans le noyau de temps en temps…[/quote]

Ah, alors c’est moi qui n’ai pas compris ce que tu as en tête. Comment ces mesures vont me donner le débit upload maximal? Si mon script est réglé à 30K/s et que par amélioration de la ligne l’upload maximal monte à 40K/s, du fait même de mon script, le débit de mon serveur sera toujours limité à 30K/s (le débit moyen sera donc en dessous) et je ne verrais pas cette amélioration. Ensuite, si je fais la mesure la nuit, je verrais un débit assez bas (l’activité est quand même réduite la nuit). Donc il me semble que pour que les infos me donnent l’upload maximal du moment, il faut que j’assure

  • la neutralisation du script
  • un upload maximal (d’où ma question sur le serveur).
    pendant un temps de test.
    Je ne peux donc m’appuyer sur le débit moyen pour régler le bazar.

Sinon, visiblement, tu as en tête un truc que je ne connais absolument pas sur le QoS. Mon script (qui est parti de Wondershaper) marque les paquets en fonction des ports de destination, des ports source et du protocole et envoit ça dans des files de priorités, (http://boisson.homeip.net/limiteur).
Je ne connais pas le -m limit, je vais regarder ce que ça fait, je comprendrais peut être mieux ce que tu veux dire.

#12

oublies le -m limit et dis moi ce que tu penses du post que j’ai écrit pendant que tu me répondais.

#13

Astucieux, en plus ça n’intervient pas sur le traffic doit effectivement ça peut se faire quasiment en permanence, je vais essayer de faire ça. On peut sans doute arriver à voir les grosses fluctuations de débit qui m’ont l’air d’être lié à une grosse saturation. Dès que j’ai un peu de temps, j’essaye de faire un truc sur ce principe. Je vais commencé par faire un paquet de mesures sur 3-4 jours pour voir la tête que ça a.

[edit: commence mal, je n’ai pas /proc/sys/class/net/eth1/statistics/tx_bytes, il doit me manquer un module, comme c’est un 2.4.19 compilé et adapté maison, je vais peut être en profiter pour tout upgrader… Ça va me mettre à la Toussaint cette histoire :frowning: ]
[reedit: à moins que tu parles réellement de /sys (que je ne connais pas), si c’est le cas je commence à payer ma non connaissance du noyau 2.6 :frowning: , je vais RTFM, sur ce coup là il faut que je me mette à jour ]

[reredit: c’est bien /sys (essai sur qemu), dmaned!]

#14

ah ben voui: /sys doit être une fonctionnalité du 2.6, à tous les coups. :frowning:

Mais bon, tu peux prendre l’info sur le nombre d’octets transmis dans ifconfig aussi, c’est juste qu’il faut découper l’info dans la sortie de la commande au lieu de l’avoir toute seule. Mais bon, ça ne devrait pas être un problême pour toi. :wink:

#15

Oui, sinon je pense aussi qu’il doit y avoir une entrée dans le /proc qui est équivalente, je vais voir ça…

[edit: il y a un nombre de trucs dans ce /sys, ça mérite d’être regardé]

#16

:slightly_smiling: Un strace sur ifconfig m’a permis de trouver ça:

[quote]francois@totoche:~$ cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
lo: 752 9 0 0 0 0 0 0 752 9 0 0 0 0 0 0
eth0: 2431205 3761 0 0 0 0 0 0 479576 3887 0 0 0 0 0 0
irda0: 0 0 0 0 0 0 0 0 134685 4305 0 0 0 0 0 0
francois@totoche:~$
[/quote]

Le chiffre intéressant c’est le 479576

#17

hello,

Je pense pas que ce soit une bonne source de mesure, puisque je pênse que peu importe le débit cette valeur est prise sur les paquets envoyés a eth0, donc un demon qui envoit des paquets a cette interface verra la valeur s’accroite et ce en dehors du debit du fai, non ?

#18

#!/bin/sh while /bin/true ; do grep eth1 /proc/net/dev | awk '{print "date +\"%s;"$9"\""}' | sh >> Debitup sleep 30 done

J’ai lancé ça en tache de fond. Je vais le laisser quelques jours pour voir ce que ça donne. J’obtiens un fichier contenant des lignes temps;tx_bytes:

[quote]…
1159977664;2932257201
1159977694;2932266743
1159977724;2932740468
1159977755;2933670975
1159977785;2934662450
…[/quote]

stonfi: Ça donne le nombre d’octets envoyés par eth1. En mesurant ça régulièrement, on a effectivement une idée du débit. L’idée de Mat est que cela doit permettre de voire si on est loin du débit upload maximal. J’ai réglé l’upload max à 32K/s très proche du maximum -10% du moment (35-36K/s on dirait). J’espère effectivement que quand ça s’améliorera je le verrais sur les chiffres.[quote][/quote]

#19

Pardon je n’ai pas tout lu, mais un script du genre m’interesserais aussi, postes le dans “tucx et astuces” si tu y arrive.

Sinon n’est-il pas envisageable de saturer la ligne en up et down avec une priorité mini dans QoS et de récup le volume total transmis RX bytes et TX bytes ?

#20

Oui, j’avais essayé ce genre de choses mais cela nécessite de «débrancher» le script et ça a donné des résultats très fluctuants. Mais si ça se trouve, j’ai tout bêtement une connexion pourrie.