[Cerowrt-devel] Linksys wrt1900acs rrul traces
dave.taht at gmail.com
Thu Apr 7 12:40:48 EDT 2016
There are multiple hardware queues on this ethernet interface but not
enough to avoid collisions. The driver has really deep queues. The
driver itself is buggy and lacks BQL. My own take on it was to use the
hardware queues for different forms of QoS, rather than spreading
flows across it.
There was some work on getting BQL to work on it; that stalled out.
On Thu, Apr 7, 2016 at 9:16 AM, moeller0 <moeller0 at gmx.de> wrote:
> Hi Richard,
>> For these tests I had the inbound and outbound limits set to 975000 kbps. 975000 was somewhat arbitrary. I wanted it below 1Gbps enough that I could be sure it was the router as the limit but yet fast enough that I would be able to see the peak transfer rates.
> All of the following might be old news to you, but please let me elaborate for others on this list (well, most folks here know way more about these things than I do).
> I believe Gbit ethernet is trickier than one would guess, the 1 Gbit rate contains some overhead that one typically does not account for. Here is the equivalent on-the-wire size of a full MTU non-jumbo ethernet frame:
> Layer “1+": 1500 (payload pMTU) + 6 (dest MAC) + 6 (src MAC) + 2 (ethertype) + 4 (FCS) + 7 (preamble) + 1 (start of frame delimiter) + 12 (interframe gap)) = 1500+6+6+2+4+7+1+12 = 1538
> ”Equivalent” in that the interframe gap is not really used, but filled with silence but it has the duration one would need for 12 bytes.
> The kernel, if left to its own devices, will only account for 14 of 38 overhead bytes. But that means that each packet will carry an additional 24 bytes of unaccounted for size that still needs to be transferred:
> 975000 * (1538/1514) = 990455.746367 (which still is below the 1GBit Layer1+ ceiling that GbE has). At 985000 * (1538/1514) = 1000614.26684 you would already have slowly caused the NIC’s buffer to fill ;)
> Luckily sqm-scripts will allow you to specify any additional per-packet overhead so just set this to 24 and things should just work out I believe.
> Best Regards
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
More information about the Cerowrt-devel