The RRUL graph shows 4 simultaneous flows. The total of 4 flows averaging 7Mb/s is 28Mb/s :).

I think it's more obvious when you know what the legend means. The flows have different service markings (which may or may not have any effect).

BE = "Best effort" (neither high nor low priority)
BK = Background
EF = "Expedited forwarding"

I think CS5 is another high priority mark. The abbreviation doesn't mean anything specific, it's just how it's coded really... it's a bit of a swamp, because there's no standard that works internet-wide, even for a low priority mark. IIRC there's one mark that ends up being treated as low priority in one "standard" and high priority in another.

On 24/08/16 18:03, [email protected] wrote:
My apologies again. The link should be, http://imgur.com/6DrMJKI

On 24 August 2016 at 18:03, [email protected] <[email protected]> wrote:

Many apologies, the link should be, http://imgur.com/6DrMJKI.

On 24 August 2016 at 18:01, [email protected] <[email protected]>
wrote:

I have today been using flent to do RRUL tests with the values set at 50%.

I have uploaded the first test I have performed. It can be seen at,
http://imgur.com/6DrMJKI.

I'm a bit confused why the DS speed is only 7Mb/s when every other speed
test I have done is around 28Mb/s (as it should be). Can anyone explain why
this might be? Am I doing something wrong?

I would appreciate an expert analysis of the graph, if possible :)

On 23 August 2016 at 21:09, Sebastian Moeller <[email protected]> wrote:

Hello techicist,

On August 23, 2016 5:13:19 PM GMT+02:00, "[email protected]" <
[email protected]> wrote:
Hello,

Thank you for your quick reply.

I take it that one of the DHCPs should read PPPoE?


Yes, you are quite correct. It should read: "TalkTalk uses DHCP to
obtain
an IP address and not PPPoE as most other ISPs do." But I think you
understood that :)

My sync speeds on VDSL2 have been very stable for the last 84+ days so
my
calculated figures will stay the same for some time, I would like to
think.
Yes, that is what I see as well.

My DS sync speed is 58976Kbps and thus I have calculated a reference
value
of 58068Kbps based on your formula. The US sync speed is 10422Kbps and
the
reference value for this is 10261Kbps.

Setting the reference values to 50%, I have: 29034Kbps for the DS; and
5130Kbps for the US. I will test with these numbers shortly. Am I right
to
assume I can just paste these into the SQM interface on LuCI?
        Yes, that should work.

I will set
the "Queuing discipline" to *cake* and the "Queue setup script" to
*piece_of_cake.qos*.

I assume also at this stage, to set "Which link layer to account for"
as *none
(default)*?
         Should work, but also Ethernet should work, as long as you do
not specify anything, or rather -14 ;)

I will then increment the values I have pasted into LuCI (assuming that
is
correct) as you have said. At this point, with an assumed overhead of
8, do
I just choose *Ethernet with overhead...* and then set the "Per Packet
Overhead (byte)" to *8*?
Yes. In essence that is the trick, it might make sense to look at cake'
statistics especially the max length field, which if you have lla set at
none reach 1514 if the kernel automatically adds it's 14 bytes.


Is there any benefit of going through UCI?
         Only if you despise the GUI or only have ssh access, I guess...
Functionally it should boil down to the same, as the GUI simply fills
/etc/config/sqm with values and then calls /etc/init.d/sqm to actually
start the scripts...

Best Regards
         Sebastian



-----------------------------------------------------------
-------------
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.




_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake


_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake

Reply via email to