> On June 1, 2015 at 2:12 PM Dave Taht <dave.taht@xxxxxxxxx> wrote: > > > On Mon, Jun 1, 2015 at 10:06 AM, jsullivan@xxxxxxxxxxxxxxxxxxx > <jsullivan@xxxxxxxxxxxxxxxxxxx> wrote: > > > >> On June 1, 2015 at 12:36 PM Andy Furniss <adf.lists@xxxxxxxxx> wrote: > >> > >> > >> Robert LeBlanc wrote: > >> > -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > >> > > >> > Any ideas on this? > >> > >> 40 gig nics are way beyond anything I've ever done with tc and I guess > >> involve some offload = huge "packets". > >> > >> It could be that aas sfq has a default qlen of 128 and as you are not > >> actually rate limiting (and to do that may be "interesting" at 80 gig) > >> the prio relies on some downstream buffer being full. Perhaps it's just > >> that at these rates prio can not dequeue anything for periods of time so > >> the 128 limit of sfq is overrun even for the highest prio. > >> > >> This is pure guesswork. > >> -- > >> 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 > > > > Alas, I haven't yet read the details of the original post but I know we just > > replaced all our sfq leaves with fq_codel because of concerns about the per > > flow > > packet depth on high speed, high latency networks. > > Yes, older versions of SFQ had a hard limit on queue depth. This was > "improved" in linux 3.6 and later but that work ultimately pointed at > a need to actively manage the queue depth, which begat sfqred, and > ultimately fq_codel. > > I note that, these days, the best results we get for > tcp-heavy-*servers and hosts* (not routers, not udp heavy services, > and the bare metal under a vm is a "router" in this context), in the > data center, at these speeds, now come from sch_fq (from the pacing, > fq, and tso fixes), and a low setting for tcp_limit_output_bytes. > > example: > > https://fasterdata.es.net/host-tuning/linux/fair-queuing-scheduler/ > > fq_codel remains a great all-around choice, but what pacing is doing > is really remarkable for servers in sch_fq. > <snip> Interesting. We do a lot of video work and hence UDP. For heavily mixed environments with high bandwidth and sometimes high latency, is fq_codel still the preferred leaf qdisc or should we be investigating sch_fq? Thanks - John -- 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
