On 28/05/15 08:00, Steven Barth wrote:
Hi everyone,
again a bit of a basic question, but what are the advantages of doing
ingress shaping in SQM?
To me it wastes a lot of CPU cycles (decreases forwarding performance)
and you can't really "unsend" any packets from the ISP. What I mean is
in 99
And now the same tune with everyone running an ftp session at the same
time: We are playing the right notes, not necessarily in the right
order (apologies to Morecambe & Wise)
https://www.youtube.com/watch?v=R7GeKLE0x3s
On 26/05/15 23:20, Dave Taht wrote:
https://www.youtube.com/watch?v=mB3_
https://dev.openwrt.org/browser/trunk/package/kernel/mac80211/patches/379-ath9k-fix-DMA-stop-sequence-for-AR9003.patch?rev=45874
--
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast
___
Cer
> On the 3800, it never meets the rate, but it's only off by maybe 5%.
That's about right for Ethernet, IPv4 and TCP header overheads with 1500
MTU. The measured throughput is application level, while HTB controls at
the Ethernet level.
- Jonathan Morton
__
Hi Aaron,
about the 5% loss with the wndr, please remember that the shaper works
typically on raw Ethernet rates, while flent reports TCP good put I believe. So
roughly 2 to 6 percent difference can be explained with a combination of the
following overheads: PTM/ATM, ethernet, VLAN(s), PPPoE, I
Remind me: does HTB have a divide in the fast path? ARMv6 and ARMv7-A CPUs
don't have a hardware integer divide, so that can really hurt.
This is fixed I think in ARMv8 and definitely in AArch64, but divides are
still expensive instructions on any CPU.
- Jonathan Morton
__
HI Aaron,
On Jun 3, 2015, at 07:45 , Aaron Wood wrote:
> I wrote this up on my blog, where I can intersperse text and graphs a bit
> better:
>
> http://burntchrome.blogspot.com/2015/06/htb-rate-limiting-not-quite-lining-up.html
>
> Basically, I ran a series of tcp_download tests, using incre
> > On the 3800, it never meets the rate, but it's only off by maybe 5%.
>
> As Jonathan pointed out already this is in the range of the
> difference between raw rates and tcp good put, so nothing to write home
> about ;)
>
Yeah, I'm not too worried about that 5%, based on that explanation
On Wed, Jun 3, 2015 at 3:16 PM, Aaron Wood wrote:
>
> > On the 3800, it never meets the rate, but it's only off by maybe 5%.
>>
>> As Jonathan pointed out already this is in the range of the
>> difference between raw rates and tcp good put, so nothing to write home
>> about ;)
>>
>
> Yeah
On Wed, Jun 3, 2015 at 3:27 PM, Dave Taht wrote:
>
>
> On Wed, Jun 3, 2015 at 3:16 PM, Aaron Wood wrote:
>
>>
>> > On the 3800, it never meets the rate, but it's only off by maybe 5%.
>>>
>>> As Jonathan pointed out already this is in the range of the
>>> difference between raw rates and
On Wed, Jun 3, 2015 at 3:27 PM, Dave Taht wrote:
>
>
>> kbps = quantum = time
>> 2 = 3000 = 1.2ms
>> 3 = 6000 = 1.6ms
>> 4 = 12000 = 2.4ms
>> 5 = 24000 = 3.84ms
>> 6 = 48000 = 6.4ms
>> 8 = 96000 = 9.6ms
>>
>
>
>> So it appears that the goal of these values was to keep incr
11 matches
Mail list logo
