Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148)

Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148)

[Dave Täht]

[-- Attachment #1.1: Type: text/plain, Size: 218 bytes --]

maybe we can flow-dissect arp?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/148#issuecomment-414094548

[-- Attachment #1.2: Type: text/html, Size: 3305 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148)

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 1634 bytes --]

Pete Heist <notifications@github.com> writes:

>> On Aug 27, 2018, at 1:40 PM, flent-users <notifications@github.com> wrote:
>> 
>> Hi Pete,
>> 
>> > On Aug 25, 2018, at 19:53, Pete Heist <notifications@github.com> wrote:
>> > 
>> > 50ms wouldn't be too disruptive in most cases. At 1 Mbit, the 5% of bandwidth threshold is crossed.
>> 
>> Would it be possible to simply also show this bandwidth use in the
>> bandwidth plots (say as a single data series accumulated over all
>> irtt probes), then the user could select the interval and still be
>> able to easily assess the effects on other bandwidth flows? I believe
>> that would also be great for the netperf UDP/ICMP streams, but
>> probably harder to implement
>
>
> We could, but I would think what might happen is that in most cases
> you’ll have a line that appears close to 0 Mbit, relative to other
> flows, and we probably wouldn’t want to change the scaling for the
> scaled bandwidth plots to accommodate that...

I think the important part of this is that it would be reflected in the
total bandwidth score. I've been meaning to implement this for a while
for netperf UDP_RR, because otherwise you can get spurious bandwidth
drops as latency decreases just because the latency measurement flows
take up more bandwidth. But, well, irtt sort of made that less urgent ;)

But I could revisit; I do believe I already capture the data from irtt
(I think?).

-Toke


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/148#issuecomment-416208064

[-- Attachment #1.2: Type: text/html, Size: 6640 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148)

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 866 bytes --]

flent-users <notifications@github.com> writes:

> Hi Dave,
>
>
>> On Sep 3, 2018, at 18:00, Dave Täht <notifications@github.com> wrote:
>> vnv 
>> Another rrul_v2 issue would be to correctly end up in all the queues on wifi.
>
> So in theory rrul_cs8 should do that... (it aims to just use one
> dscp-marked flow per class selector for a total of 8 tcp flows per
> direction...) In practice I believe the mapping from dscps to ACs is
> highly non-linear...

Well, not that non-linear:

const int ieee802_1d_to_ac[8] = {
	IEEE80211_AC_BE,
	IEEE80211_AC_BK,
	IEEE80211_AC_BK,
	IEEE80211_AC_BE,
	IEEE80211_AC_VI,
	IEEE80211_AC_VI,
	IEEE80211_AC_VO,
	IEEE80211_AC_VO
};


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/148#issuecomment-418167272

[-- Attachment #1.2: Type: text/html, Size: 4876 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org

Re: [Flent-users] [tohojo/flent] testing the behavior of small queue building non-ecn'd flows (#148)

[Toke Høiland-Jørgensen]

[-- Attachment #1.1: Type: text/plain, Size: 2237 bytes --]

flent-users <notifications@github.com> writes:

> HI Toke,
>
>
>> On Sep 3, 2018, at 19:37, Toke Høiland-Jørgensen <notifications@github.com> wrote:
>> 
>> flent-users <notifications@github.com> writes:
>> 
>> > Hi Dave,
>> >
>> >
>> >> On Sep 3, 2018, at 18:00, Dave Täht <notifications@github.com> wrote:
>> >> vnv 
>> >> Another rrul_v2 issue would be to correctly end up in all the queues on wifi.
>> >
>> > So in theory rrul_cs8 should do that... (it aims to just use one
>> > dscp-marked flow per class selector for a total of 8 tcp flows per
>> > direction...) In practice I believe the mapping from dscps to ACs is
>> > highly non-linear...
>> 
>> Well, not that non-linear:
>> 
>> const int ieee802_1d_to_ac[8] = {
>> IEEE80211_AC_BE,
>> IEEE80211_AC_BK,
>> IEEE80211_AC_BK,
>> IEEE80211_AC_BE,
>> IEEE80211_AC_VI,
>> IEEE80211_AC_VI,
>> IEEE80211_AC_VO,
>> IEEE80211_AC_VO
>> };
>
> Well, aren't these values according to IEEE P802.1p (https://en.wikipedia.org/wiki/IEEE_P802.1p)?
>
> PCP 	value		Priority	Acronym	Traffic types
> 1		0 (lowest)	BK		Background
> 0		1 (default)	BE		Best effort
> 2		2			EE		Excellent effort
> 3		3			CA		Critical applications
> 4		4			VI		Video, < 100 ms latency and jitter
> 5		5			VO		Voice, < 10 ms latency and jitter
> 6		6			IC		Internetwork control
> 7		7 (highest)	NC		Network control
>
> These map the 3 bit priority PCP values from VLAN tags to ACs, but
> note the dance with PCP 1 being lower than PCP 0, and more importantly
> the different interpretations about PCP 2, is it "excellent effort" or
> another BK code point?
>
> I guess the point I wanted to make is that mapping down from the 6bit
> DSCP to ACs is not very intuitive (with linear mapping being the "most
> intuitive").
>
> Anyway, I am totally fine with just using 3 bits, this is still plenty
> for priority hierarchies that I can still understand ;)

Oh, it's absolutely a mess. So much so that the IETF had to write a
whole RFC on it: https://tools.ietf.org/html/rfc8325

-Toke


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/148#issuecomment-418188201

[-- Attachment #1.2: Type: text/html, Size: 8553 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Flent-users mailing list
Flent-users@flent.org
http://flent.org/mailman/listinfo/flent-users_flent.org