BTW, the SFQ-CoDel code does support the "new" flows concept in much the same way as the linux code, so this was already included in the simulation results.
On 5/6/13 2:47 PM, "Jesper Dangaard Brouer" <[email protected]> wrote: >On Mon, 6 May 2013 21:46:35 +0300 Jonathan Morton ><[email protected]> wrote: >> On 6 May, 2013, at 8:54 pm, Jesper Dangaard Brouer wrote: >> >> > A flow is considered "new" if no packets for the given flow exists >> > in the queue. It does not have to be a truly new-flow, it just >> > have to send packets "slow"/paced enough, that the queue is empty >> > when the next packet arrive. >> > >> > Perhaps VoIP would fit this traffic profile, and thus would work >> > better with the Linux fq_codel implementation, compared to the >> > SFQ-Codel used in the simulation. >> >> That doesn't work, because the with a sufficient number of BT flows, >> the flow queue containing the VoIP flow is the fullest queue, not the >> emptiest. That's independent of the number of flow queues, including >> the infinite case. Think about it carefully. > >Yes, I agree. > >And as I mentioned, with the fq_codel implementation details, this is >going to hit even earlier, as we have a limited number of flow/hash >queues. > >> Looking at the implementation, it does have the problem that the match >> for "if the flow already have packets in the queue" just looks to see >> if the hash bucket is empty. Thus 2 stream sharing a hash queue throw >> this off. > >-- >Best regards, > Jesper Dangaard Brouer > MSc.CS, Sr. Network Kernel Developer at Red Hat > Author of http://www.iptv-analyzer.org > LinkedIn: http://www.linkedin.com/in/brouer >_______________________________________________ >Codel mailing list >[email protected] >https://lists.bufferbloat.net/listinfo/codel _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
