Eric,<br><br>Thanks for the confirmation of that.<br><br>So application pacing of say 8Mbps (1000 packets at 1000 bytes each), is equivalent to 8.3-8.4Mbps at the interface (depending on ip header options)<br><br>So anyone planning on calling setsockopt() needs to keep that in mind?  Or is that calculated correctly for an application?<br><br>-Aaron<br><div class="gmail_quote"><div dir="ltr">On Fri, Apr 14, 2017 at 11:00 Eric Dumazet <<a href="mailto:eric.dumazet@gmail.com">eric.dumazet@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 2017-04-13 at 20:12 -0700, Aaron Wood wrote:<br>
> When I was testing with my iPerf changes, I realized that the sch_fq<br>
> pacing (which in iperf is set via setsockopt()), is pacing at a<br>
> bandwidth that's set at a pretty low level in the stack (which makes<br>
> sense).  This is different from the application pacing that iperf does<br>
> (which is pacing the goodput).<br>
><br>
><br>
> But it's not clear to me where the X bps determination is being made.<br>
> My current guess is that it's at the interface level (since that's<br>
> where sch_fq is), and so it's approximately "bytes on the wire", minus<br>
> preambles and inter-packet spacing, and whatnot.  And so it's<br>
> including all the 802.x headers involved (vlan tags, qos tags,<br>
> source/dest macs, etc).  Is this correct?<br>
><br>
Like other qdisc having rate limits (TBF, HTB ....), FQ sees packets<br>
with all headers (including Ethernet one)<br>
<br>
This is why the default quantum is 3028, which is exactly 2 regular<br>
Ethernet frames (MTU=1500 + 14 bytes of Ethernet header)<br>
<br>
If you have VLAN tag, it is generally not included in the calculation,<br>
as many devices provide 'hardware tagging'.<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>