Jonas Mårtensson <[email protected]> writes: > On Tue, Apr 17, 2018 at 2:22 PM, Toke Høiland-Jørgensen <[email protected]> > wrote: > >> Y via Cake <[email protected]> writes: >> >> > From: Y <[email protected]> >> > Subject: Re: [Cake] A few puzzling Cake results >> > To: [email protected] >> > Date: Tue, 17 Apr 2018 21:05:12 +0900 >> > >> > Hi. >> > >> > Any certain fomula of fq_codel flow number? >> >> Well, given N active bulk flows with packet size L, and assuming the >> quantum Q=L (which is the default for FQ-CoDel at full-size 1500-byte >> packets), the maximum rate for a sparse flow, R_s, is bounded by >> >> R_s < R / ((L/L_s)(N+1)) >> >> Where R is the link rate and L_s is the packet size of the sparse flow. >> This assumes that the sparse flow has constant spacing between its >> packets, which is often the case for a VoIP flow... > > > For 10-Mbit/s link rate and 32 bulk flows with 1500-byte packets this > formula gives roughly 25 pps (packets per second) as maximum for a sparse > flow. A VoIP flow is typically 50 pps (20 ms voice payload). > > Does this mean that cake sets the quantum to less than 750 bytes for a > 10-Mbit/s link?
Yup, it sets it to 305 bytes. I added this to the stats output in the latest git version. > Do you see any benefit with cake diffserv if you increase the number > of flows? I have not been able to see a benefit of diffserv mode for the VoIP flow. Even at 128 flows there's no difference; and beyond that my testbed can't keep up anymore... Diffserv mode doesn't hurt either, though... It may simply be that its primary utility is to allow flows to *de*prioritise themselves... > Does the adjusted quantum also explain the "*way* higher" TCP RTT for > cake? How? Nope, don't think so. I think the difference in TCP RTT is due to differences in the CoDel implementation. -Toke _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
