Bonjour Marc, Le lundi 21 septembre 2015 à 10:39 +0200, Marc Dilasser a écrit :
Le 14/09/2015 17:34, Mathieu Goessens a écrit :
Personnellement j'aurais tendance à penser que mettre en place de la QoS revient à chercher une solution technique à un problème qui ne l'est pas: si des membres consomment trop et que cela impact l'association (de manière financière ou la qualité des services rendus), ils doivent en assumer les conséquences. Autrement dit, autant facturer le surcoût éventuel, comme ça c'est clair, transparent, et techniquement bien moins intrusif. Un 90eme ou 95eme percentile par membre (interface), cacti fait ça très bien.
Tant que la congestion n'est pas atteinte, la QOS ne fait strictement rien, elle n'a pas à choisir quel paquet passe avant tel autre paquet, pour la simple et bonne raison qu'il n'y en a pas en attente dans la file, exemple sur une Mikrotik :
[admin@mkt397] /queue tree> /interface monitor-traffic ether1 once name: ether1 rx-packets-per-second: 837 rx-drops-per-second: 0 rx-errors-per-second: 0 rx-bits-per-second: 9.3Mbps tx-packets-per-second: 572 tx-drops-per-second: 0 tx-errors-per-second: 0 tx-bits-per-second: 453.8kbps
[admin@mkt397] /queue tree> /queue monitor once queued-packets: 0 queued-bytes: 0
Merci Marc pour ces précisions tout à fait justes. J'en ai discuté avec geb l'autre jour, et c'est vrai que *sur des contrats burstable*, le genre de solution que j'ai évoqué ne sert à rien. Sur un contrat flat, et *si on congestionne*, comme tu le précises, là ça pourrait éventuellement « aider ». Mais c'est clair que la solution c'est plutôt de d'abord éviter que ça congestionne…
Un bon indicateur du besoin (ou pas), c'est de faire passer de la VOIP, on sait très vite s'il en faut ou pas.
Merci pour tes conseils ! ;-) -- benjamin