Hello Dave,
I'll have to try that.
But for the moment, I found a "solution", expecting to use something
"cleaner" : I downgraded to kernel 3.10.25, and everything is working as
usual.
The machine is a production server for a little student radio in France,
so I cannot test a lot without shutting down the entire station.
The downgrade did the trick, so the problem is kinda "solved" for me
(although having the latest kernel would have been a better solution for
me I guess). Anyway, I'm going to tune these policies a bit, as you are
suggesting.
As for the reason I'm not running sfq on all qdiscs, well... as you
understand, with my very poor knowledge, I've been working on this
little script for a long time to have an acceptable level of service. I
had finally found the "perfect" match for the desired performances, and
the results of my "researches" showed that I had to use sfq only on the
qdiscs that did not require a "guaranteed" (although this is not
entirely correct, as we are working on a ADSL connection) throughput :
the classes having sfq are used for TCP operations such as web surfing,
and the returning of ACK packets for example. The other ones have fixed
limited bandwidth (not borrowable) for UDP (RTP) streams directly to
broadcast servers.
Thanks for your help, I'll get back on this list soon.
Hoggins!
Le 06/01/2014 00:41, Dave Taht a écrit :
> Is there some reason you aren't running sfq on all qdiscs? That could
> be a cause.
>
> and:
>
> try
>
> fq_codel target 20ms quantum 300 limit 600
>
> instead of sfq.
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
