Re: [Cake] cake flenter results round 2

[Georgios Amanakis]

@Pete I think you need to start netserver on the client first (in your
case, you are running flent on the server): "ip netns exec client netserver"

On Tue, Nov 28, 2017 at 7:16 PM, Pete Heist  wrote:

>
> > On Nov 28, 2017, at 11:52 PM, Dave Taht  wrote:
> >
> > A diffserv 200Mbit result would be good.
> >
> > We are utterly out of cpu at 900mbits here.
> >
> > 
>
> Wow, I see flent’s combination plots are handy though.
>
> Stuff to sort in irtt also. Merely setting the source IP of an outgoing
> packet doubles allocated heap when it calls into x/net code. Super.
>
> Ok, here’s a quick veth try but I gotta get to sleep so I’m not
> investigating much ’til later. I wonder if 4.9.0-4 is enough:
>
> root@apu2a:/home/sysadmin/src/veth# cat settings.example
> export HOSTS="server client delay mbox"
>
> # I’ve been a bad boy and did sudo make install in iproute2-cake-next
> export TC=/sbin/tc
> root@apu2a:/home/sysadmin/src/veth# ./vsetup.sh
> Cannot remove namespace file "/var/run/netns/server": No such file or
> directory
> Cannot remove namespace file "/var/run/netns/client": No such file or
> directory
> Cannot remove namespace file "/var/run/netns/delay": No such file or
> directory
> Cannot remove namespace file "/var/run/netns/mbox": No such file or
> directory
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> RTNETLINK answers: File exists
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> root@apu2a:/home/sysadmin/src/veth# ./vcake.sh
> root@apu2a:/home/sysadmin/src/veth# ip netns exec server flent -H
> 10.10.2.2 rrul_be
> Started Flent 1.1.1-git-5daa2b3 using Python 2.7.13.
> Starting rrul_be test. Expected run time: 70 seconds.
> WARNING: Program exited non-zero.
> Runner class: NetperfDemoRunner
> Command: /usr/bin/netperf -P 0 -v 0 -D -0.20 -4 -Y CS0,CS0 -H 10.10.2.2 -p
> 12865 -t UDP_RR -l 70 -F /dev/urandom--   -H 10.10.2.2 -k
> THROUGHPUT,LOCAL_CONG_CONTROL,REMOTE_CONG_CONTROL,TRANSPORT_
> MSS,LOCAL_TRANSPORT_RETRANS,REMOTE_TRANSPORT_RETRANS,
> LOCAL_SOCKET_TOS,REMOTE_SOCKET_TOS,DIRECTION,ELAPSED_
> TIME,PROTOCOL,LOCAL_SEND_SIZE,LOCAL_RECV_SIZE,REMOTE_SEND_
> SIZE,REMOTE_RECV_SIZE
> Return code: 255
> Stdout: establish control: are you sure there is a netserver listening on
> 10.10.2.2 at port 12865?
> establish_control could not establish the control connection from 0.0.0.0
> port 0 address family AF_INET to 10.10.2.2 port 12865 address family AF_INET
>
> ...
> ___
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] Fwd: Re: cake flenter results round 2

[Georgios Amanakis]

I got Dave's netns scripts working on my server. Will try to run rrul tests
on a 200/10mbit tonight.

George

On Nov 28, 2017 7:16 PM, "Pete Heist"  wrote:

>
> > On Nov 28, 2017, at 11:52 PM, Dave Taht  wrote:
> >
> > A diffserv 200Mbit result would be good.
> >
> > We are utterly out of cpu at 900mbits here.
> >
> > 
>
> Wow, I see flent’s combination plots are handy though.
>
> Stuff to sort in irtt also. Merely setting the source IP of an outgoing
> packet doubles allocated heap when it calls into x/net code. Super.
>
> Ok, here’s a quick veth try but I gotta get to sleep so I’m not
> investigating much ’til later. I wonder if 4.9.0-4 is enough:
>
> root@apu2a:/home/sysadmin/src/veth# cat settings.example
> export HOSTS="server client delay mbox"
>
> # I’ve been a bad boy and did sudo make install in iproute2-cake-next
> export TC=/sbin/tc
> root@apu2a:/home/sysadmin/src/veth# ./vsetup.sh
> Cannot remove namespace file "/var/run/netns/server": No such file or
> directory
> Cannot remove namespace file "/var/run/netns/client": No such file or
> directory
> Cannot remove namespace file "/var/run/netns/delay": No such file or
> directory
> Cannot remove namespace file "/var/run/netns/mbox": No such file or
> directory
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> RTNETLINK answers: File exists
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> net.ipv4.ip_forward = 1
> net.ipv6.conf.all.forwarding = 1
> root@apu2a:/home/sysadmin/src/veth# ./vcake.sh
> root@apu2a:/home/sysadmin/src/veth# ip netns exec server flent -H
> 10.10.2.2 rrul_be
> Started Flent 1.1.1-git-5daa2b3 using Python 2.7.13.
> Starting rrul_be test. Expected run time: 70 seconds.
> WARNING: Program exited non-zero.
> Runner class: NetperfDemoRunner
> Command: /usr/bin/netperf -P 0 -v 0 -D -0.20 -4 -Y CS0,CS0 -H 10.10.2.2 -p
> 12865 -t UDP_RR -l 70 -F /dev/urandom--   -H 10.10.2.2 -k
> THROUGHPUT,LOCAL_CONG_CONTROL,REMOTE_CONG_CONTROL,TRANSPORT_
> MSS,LOCAL_TRANSPORT_RETRANS,REMOTE_TRANSPORT_RETRANS,LOCAL_
> SOCKET_TOS,REMOTE_SOCKET_TOS,DIRECTION,ELAPSED_TIME,
> PROTOCOL,LOCAL_SEND_SIZE,LOCAL_RECV_SIZE,REMOTE_SEND_SIZE,REMOTE_RECV_SIZE
> Return code: 255
> Stdout: establish control: are you sure there is a netserver listening on
> 10.10.2.2 at port 12865?
> establish_control could not establish the control connection from 0.0.0.0
> port 0 address family AF_INET to 10.10.2.2 port 12865 address family AF_INET
>
> ...
> ___
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] cake flenter results round 2

[Pete Heist]

> On Nov 28, 2017, at 11:52 PM, Dave Taht  wrote:
> 
> A diffserv 200Mbit result would be good.
> 
> We are utterly out of cpu at 900mbits here.
> 
> 

Wow, I see flent’s combination plots are handy though.

Stuff to sort in irtt also. Merely setting the source IP of an outgoing packet 
doubles allocated heap when it calls into x/net code. Super.

Ok, here’s a quick veth try but I gotta get to sleep so I’m not investigating 
much ’til later. I wonder if 4.9.0-4 is enough:

root@apu2a:/home/sysadmin/src/veth# cat settings.example 
export HOSTS="server client delay mbox"

# I’ve been a bad boy and did sudo make install in iproute2-cake-next
export TC=/sbin/tc
root@apu2a:/home/sysadmin/src/veth# ./vsetup.sh
Cannot remove namespace file "/var/run/netns/server": No such file or directory
Cannot remove namespace file "/var/run/netns/client": No such file or directory
Cannot remove namespace file "/var/run/netns/delay": No such file or directory
Cannot remove namespace file "/var/run/netns/mbox": No such file or directory
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
RTNETLINK answers: File exists
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
root@apu2a:/home/sysadmin/src/veth# ./vcake.sh 
root@apu2a:/home/sysadmin/src/veth# ip netns exec server flent -H 10.10.2.2 
rrul_be
Started Flent 1.1.1-git-5daa2b3 using Python 2.7.13.
Starting rrul_be test. Expected run time: 70 seconds.
WARNING: Program exited non-zero.
Runner class: NetperfDemoRunner
Command: /usr/bin/netperf -P 0 -v 0 -D -0.20 -4 -Y CS0,CS0 -H 10.10.2.2 -p 
12865 -t UDP_RR -l 70 -F /dev/urandom--   -H 10.10.2.2 -k 
THROUGHPUT,LOCAL_CONG_CONTROL,REMOTE_CONG_CONTROL,TRANSPORT_MSS,LOCAL_TRANSPORT_RETRANS,REMOTE_TRANSPORT_RETRANS,LOCAL_SOCKET_TOS,REMOTE_SOCKET_TOS,DIRECTION,ELAPSED_TIME,PROTOCOL,LOCAL_SEND_SIZE,LOCAL_RECV_SIZE,REMOTE_SEND_SIZE,REMOTE_RECV_SIZE
  
Return code: 255
Stdout: establish control: are you sure there is a netserver listening on 
10.10.2.2 at port 12865?
establish_control could not establish the control connection from 0.0.0.0 port 
0 address family AF_INET to 10.10.2.2 port 12865 address family AF_INET

...
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Simple metrics

[Dave Taht]

Pete Heist  writes:

>> On Nov 28, 2017, at 7:15 PM, Dave Taht  wrote:
>> 
>> Pete Heist  writes:
>> 
>>>On Nov 27, 2017, at 7:28 PM, Jonathan Morton  
>>> wrote:
>>> 
>>>An important factor when designing the test is the difference between
>>>intra-flow and inter-flow induced latencies, as well as the baseline
>>>latency.
>>> 
>>>In general, AQM by itself controls intra-flow induced latency, while flow
>>>isolation (commonly FQ) controls inter-flow induced latency. I consider 
>>> the
>>>latter to be more important to measure.
>>> 
>>> Intra-flow induced latency should also be important for web page load time 
>>> and
>>> websockets, for example. Maybe not as important as inter-flow, because there
>>> you’re talking about how voice, videoconferencing and other interactive apps
>>> work together with other traffic, which is what people are affected by the 
>>> most
>>> when it doesn’t work.
>>> 
>>> I don’t think it’s too much to include one public metric for each. People 
>>> are
>>> used to “upload” and “download”, maybe they’d one day get used to 
>>> “reactivity”
>>> and “interactivity”, or some more accessible terms.
>> 
>> Well, what I proposed was using a pfifo as the reference
>> standard, and "FQ" as one metric name against pfifo 1000/newstuff. 
>> 
>> That normalizes any test we come up with.
>
> So one could have 6 FQ on the intra-flow latency test and 4 FQ on the 
> inter-flow latency test, for example, because it’s always a factor of pfifo 
> 1000’s result on whatever test is run?

yep. using 1000 for FIFO queue length also pleases me due to all the
academic work at 50 or 100.

It would even work for tcp RTT measurement changes, although "FQ" is
sort of a bad name here. I'd be up to another name. LQ? (latency
quotient). LS (latency stress)


>
>>>Baseline latency is a factor of the underlying network topology, and 
>>> is
>>>the type of latency most often measured. It should be measured in the
>>>no-load condition, but the choice of remote endpoint is critical. Large 
>>> ISPs
>>>could gain an unfair advantage if they can provide a qualifying endpoint
>>>within their network, closer to the last mile links than most realistic
>>>Internet services. Conversely, ISPs are unlikely to endorse a measurement
>>>scheme which places the endpoints too far away from them.
>>> 
>>>One reasonable possibility is to use DNS lookups to randomly-selected 
>>> gTLDs
>>>as the benchmark. There are gTLD DNS servers well-placed in essentially 
>>> all
>>>regions of interest, and effective DNS caching is a legitimate means for 
>>> an
>>>ISP to improve their customers' internet performance. Random lookups
>>>(especially of domains which are known to not exist) should defeat the
>>>effects of such caching.
>>> 
>>>Induced latency can then be measured by applying a load and comparing the
>>>new latency measurement to the baseline. This load can simultaneously be
>>>used to measure available throughput. The tests on dslreports offer a 
>>> decent
>>>example of how to do this, but it would be necessary to standardise the
>>>load.
>>> 
>>> It would be good to know what an average worst case heavy load is on a 
>>> typical
>>> household Internet connection and standardize on that. Windows updates for
>>> example can be pretty bad (many flows).
>> 
>> My mental reference has always been family of four -
>> 
>> Mom in a videoconference
>> Dad surfing the web
>> Son playing a game
>> Daughter uploading to youtube
>> 
>> (pick your gender neutral roles at will)
>> 
>> + Torrenting or dropbox or windows update or steam or …
>
> That sounds like a pretty good reasonable family maximum.
>
>> A larger scale reference might be a company of 30 people.
>
> I’m only speculating that an average active company user generates less 
> traffic than an average active home user, depending on the line of work of 
> course.
>
> Could there be a single test that’s independent of scale and intelligently
> exercises the connection until the practical limits of its rrul related
> variables are known? I think that’s what would make testing much easier. I
> realize I'm conflating the concept of a simple testing metric with this idea.
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] Cake tree unreadable

[Dave Taht]

A flag day here is feasible. I will fiddle along the lines you describe.

As for other flag days...

I'm toying with the idea of fixing xstats in a separate branch. I really
hate the idea of breaking backward compatability here, but I do suspect
it will be a barrier to upstreaming, and it is, quite inefficient.


Kevin Darbyshire-Bryant  writes:

>> On 28 Nov 2017, at 18:48, Dave Taht  wrote:
>> 
>> 
>> 
>> It sounds like your git-foo is stronger than ours! I'm not even trying
>> to get head to work, tho my intent would be to promote cobalt to it.
>
> git checkout master
> git pull   (does the equivalent of git fetch origin; git merge origin/master)
> git merge cobalt   (this will produce a minor merge conflict in sch_cake.c)
>
> fix merge conflict
>
> git add sch_cake.c
> git commit   (complete the merge - and create a merge commit in process)
>
> git diff cobalt - should return nothing…content of master & cobalt are the 
> same.
>
> git push  (send this to github assuming above is true!)
>
> If it were me I’d now restart the cobalt ‘feature’ branch from this new 
> ‘master’ point.
>
> git checkout cobalt
> git reset —hard master  (resets ‘cobalts’ commit pointer and the current tree 
> on disc to where master is)
> git push -f   (send that to github -f means force)
>
> You’ve just created a ‘new’ history for the ‘cobalt’ feature branch, so all
> ‘clients’ of that branch will see a ‘forced update’ message….you’ve broken the
> linear git history for that branch, so they’d have to do something like ‘git
> checkout cobalt; git reset —hard origin/cobalt’
>
> I used to be terrified of ‘git reset’ until I read 
> https://git-scm.com/blog/2011/07/11/reset.html - at that point I realised all 
> it (and  the whole of git) is about moving pointers contained in branch names.
>
> Of course I’d advise checking things carefully before doing force pushes….but 
> then I’d imagine many on this list have forks and hence clones of the git 
> repo in various places so it’s all recoverable.
>
>
>> 
>> I didn't know about the cherry-pick option til now, either. I was doing
>> a git format-patch thenewcommit, then a git am on my other branch.
> I’ve just sped up your workflow then :-)
>> 
>> For example, with this config, git fetch --all doesn't do anything.
> git fetch —all goes and gets all the branches/commits etc from all configured
> remotes.  You’ve only 1 remote (origin…which points at github) and it’s likely
> that since it’s not very active that you’ve all the commits etc already in 
> your
> local git database.
>
> I have several remotes e.g.
>
> [remote "origin"]
> url = g...@github.com:ldir-EDB0/sch_cake.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [remote "upstream"]
> url = g...@github.com:dtaht/sch_cake.git
> fetch = +refs/heads/*:refs/remotes/upstream/*
> [remote "teg"]
> url = g...@github.com:tegularius/sch_cake.git
> fetch = +refs/heads/*:refs/remotes/teg/*
> [remote "rmounce"]
> url = g...@github.com:rmounce/sch_cake.git
> fetch = +refs/heads/*:refs/remotes/rmounce/*
>
> so my ‘git fetch —all’ will go and look in all those places for things I’m
> missing.  Origin is my own github base cake repo (a clone/fork of yours),
> ‘upstream’ is a pointer directly to your github repo, ‘teg’ & ‘rmounce’ are
> pointers to their forks/clones.
>
> So to bring my master up to date with yours:
>
> git checkout master
> git fetch —all
> git merge upstream/master. (which should do a ‘fast-forward’ to where you are 
> since I intentionally don’t do any of my own work in master)
> git push (update my own fork with all the latest stuff)
>
>
> My own stuff (not that there is any anymore ‘cos it’s all in cobalt) would 
> then be rebased on top of the stable (but moving) master e.g:
>
> git checkout worldpeace (my WIP mega solution branch)
> edit edit edit, commit commit commit
> git rebase master. - replay all of my stuff on top of the updated master
> edit - fixup any conflicts
> git push -f  (force update my worldpeace branch on github)
>
>
> I like git, but I’m by no means a guru on it….and it took me about 2 years to 
> go from ‘I hate it’ to ‘ahhh I get it - sort of’.  The git reset article 
> helped.  Also having ‘git prompt’ enabled was a godsend.
>
>> 
>> [core]
>>repositoryformatversion = 0
>>filemode = true
>>bare = false
>>logallrefupdates = true
>> [remote "origin"]
>>url = g...@github.com:dtaht/sch_cake.git
>>fetch = +refs/heads/*:refs/remotes/origin/*
>> [branch "master"]
>>remote = origin
>>merge = refs/heads/master
>> [branch "for_upstream_4.16"]
>>remote = origin
>>merge = refs/heads/for_upstream_4.16
>> [branch "cobalt"]
>>remote = origin
>>merge = refs/heads/cobalt
>> 
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] cake flenter results round 2

[Dave Taht]

Pete Heist  writes:

>> On Nov 28, 2017, at 8:07 PM, Dave Taht  wrote:
>> 
>> Pete Heist  writes:
>> 
>>> *** Round 3 Plans:
>>> 
>>> * Use netem to test a spread of simulated rtts and bandwidths.
>> 
>> Since you are leveraging a few too few boxes, attached are my current
>> scripts for fiddling a bit with network namespaces. I added individual
>> ssh, irtt, etc, servers so that things like flent's ssh stuff should
>> just work for polling stats.
>
> You mean a few too few virtual boxes, not necessarily physical ones, right? :)
> In other words, there are different topologies that can be used for testing. 
> In
> your scripts you’re simulating "Internet access", where client is the family 
> or
> organization for example and server is stuff on the Internet:
>
> client - middlebox - delay - server
>
> In my earlier point-to-point WiFi testing I was simulating an ISP’s backhaul:
>
> client - client_router - station - ap - server_router - server
>
> In my current testing I’m simulating, well, something far less useful if I 
> think about it- two boxes blasting traffic to one another over a cable and 
> trying to improve queueing delays between them:
>
> client - client_router --- server_router - server

Yes, in this case, the local TCP stack tends to interact better with
fq_codel than cake does, due in part to the NET_XMIT_CN support there.

I confess that my fav takeaway of your results thus far has been - it
doesn't crash. It still doesn't crash, here, either. We could upstream
it this week. :)

>
> I hadn’t realized how heavy-weight traffic generation for anything beyond 4/4 
> flows would be at Gbit rates, or how confusing and trivial some of these 
> results would be.
>
> So beyond just my vague idea to “simulate a spread of rtts and bandwidths”, I 
> see I need a topology change to produce something more useful. I think there 
> are still two options:

Yes, I wouldn't trust the result with netem on what you got very far.

> 1) Point-to-point WiFi again, where I’d be using two NSM5s and testing over
> short range at rates of up to 100 Mbps. I would probably try to get FreeNet’s
> APU version 1 boxes into action again so I’d have physical devices for each of
> the six roles above. I wish I didn’t have to use those RTL8111Es, but that’s 
> how
> it is.
>
> 2) Your “Internet access” setup. Either I can get the veth stuff into action 
> on
> a single physical APU2 (powerful enough?), or I can try to set up four 
> physical
> boxes with the same topology (or if I were tricky, try to spread the four 
> roles
> across two boxes).

Getting the veth stuff setup for a basic test should be plug and go with
what I gave you. And you do have 4 cores, so try a few tests at 900Mbit
to see what happens.

I think george has the most powerful box we have readily available, and
perhaps it would be easier for him to give netns a go. I cannot trust
the results we get from the cloud (too many unknown VMs sharing the
hardware)... so I keep thinking, for christmas, I will finally get
around to replacing snapon (which is doing lede build and server duty in
sweden).

I am presently getting in a good 40+ minute nap in between kernel
builds, which that would also solve. (I like my naps tho). All my
computers are pretty low power - only the core I5 nucs and laptops have
fans which only kick in on builds - and I like a quiet work environment,
so trying to build the fastest box possible without howling fans would
be ideal.

snapon (6 cores) cost about 2.5k when we got it (5? years ago). It looks
like for about the same price we can get to at least 8 cores. Things
start going pear-shaped on (for example) the AMD threadripper (16 cores)
- or Xeons, at 1k for the cpu at min (but a 30 second kernel build)

We could try to get a dedicated rack mount somewhere, but I don't know
where, or how much.

I rather enjoyed what esr pulled off with "the great beast". He had
different requirements - in my case I'd like a sharable box for builds
and simulations. Were these actual simulations (e.g. ns3) the virtual
clock would be ok to run in the cloud, but since we're on bare metal,
we'd need bare metal.

Worse, to do this truly right, actually starting to fiddle with 10Gig+
hardware in a realistic topology could also be of use. Arguably those of
you in Northern Europe need space heaters more than I do...

PS: 
I note the veth file I sent had two errors in it - vdaemons was meant to
be vssh.sh and the netem delay component should have had a limit 10
to it. I'm still using these simplistic shell scripts 'cause I havent
found anything better to construct topologies with (want ipv6), as yet,
and I should probably get around to a public repo for 'em.

>
> #1 would be useful for FreeNet. Would it also be useful for Cake testing in 
> general, or would you prefer more #2 results at this stage (i.e. simulating 
> dsl, cable, satellite, etc)?

I'm really happy with this stuff right now. I 

Re: [Cake] Cake tree unreadable

[Kevin Darbyshire-Bryant]

> On 28 Nov 2017, at 18:48, Dave Taht  wrote:
> 
> 
> 
> It sounds like your git-foo is stronger than ours! I'm not even trying
> to get head to work, tho my intent would be to promote cobalt to it.

git checkout master
git pull   (does the equivalent of git fetch origin; git merge origin/master)
git merge cobalt   (this will produce a minor merge conflict in sch_cake.c)

fix merge conflict

git add sch_cake.c
git commit   (complete the merge - and create a merge commit in process)

git diff cobalt - should return nothing…content of master & cobalt are the same.

git push  (send this to github assuming above is true!)

If it were me I’d now restart the cobalt ‘feature’ branch from this new 
‘master’ point.

git checkout cobalt
git reset —hard master  (resets ‘cobalts’ commit pointer and the current tree 
on disc to where master is)
git push -f   (send that to github -f means force)

You’ve just created a ‘new’ history for the ‘cobalt’ feature branch, so all 
‘clients’ of that branch will see a ‘forced update’ message….you’ve broken the 
linear git history for that branch, so they’d have to do something like ‘git 
checkout cobalt; git reset —hard origin/cobalt’

I used to be terrified of ‘git reset’ until I read 
https://git-scm.com/blog/2011/07/11/reset.html - at that point I realised all 
it (and  the whole of git) is about moving pointers contained in branch names.

Of course I’d advise checking things carefully before doing force pushes….but 
then I’d imagine many on this list have forks and hence clones of the git repo 
in various places so it’s all recoverable.


> 
> I didn't know about the cherry-pick option til now, either. I was doing
> a git format-patch thenewcommit, then a git am on my other branch.
I’ve just sped up your workflow then :-)
> 
> For example, with this config, git fetch --all doesn't do anything.
git fetch —all  goes and gets all the branches/commits etc from all configured 
remotes.  You’ve only 1 remote (origin…which points at github) and it’s likely 
that since it’s not very active that you’ve all the commits etc already in your 
local git database.

I have several remotes e.g.

[remote "origin"]
url = g...@github.com:ldir-EDB0/sch_cake.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "upstream"]
url = g...@github.com:dtaht/sch_cake.git
fetch = +refs/heads/*:refs/remotes/upstream/*
[remote "teg"]
url = g...@github.com:tegularius/sch_cake.git
fetch = +refs/heads/*:refs/remotes/teg/*
[remote "rmounce"]
url = g...@github.com:rmounce/sch_cake.git
fetch = +refs/heads/*:refs/remotes/rmounce/*

so my ‘git fetch —all’ will go and look in all those places for things I’m 
missing.  Origin is my own github base cake repo (a clone/fork of yours), 
‘upstream’ is a pointer directly to your github repo, ‘teg’ & ‘rmounce’ are 
pointers to their forks/clones.

So to bring my master up to date with yours:

git checkout master
git fetch —all
git merge upstream/master. (which should do a ‘fast-forward’ to where you are 
since I intentionally don’t do any of my own work in master)
git push (update my own fork with all the latest stuff)


My own stuff (not that there is any anymore ‘cos it’s all in cobalt) would then 
be rebased on top of the stable (but moving) master e.g:

git checkout worldpeace (my WIP mega solution branch)
edit edit edit, commit commit commit
git rebase master. - replay all of my stuff on top of the updated master
edit - fixup any conflicts
git push -f  (force update my worldpeace branch on github)


I like git, but I’m by no means a guru on it….and it took me about 2 years to 
go from ‘I hate it’ to ‘ahhh I get it - sort of’.  The git reset article 
helped.  Also having ‘git prompt’ enabled was a godsend.

> 
> [core]
>repositoryformatversion = 0
>filemode = true
>bare = false
>logallrefupdates = true
> [remote "origin"]
>url = g...@github.com:dtaht/sch_cake.git
>fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
>remote = origin
>merge = refs/heads/master
> [branch "for_upstream_4.16"]
>remote = origin
>merge = refs/heads/for_upstream_4.16
> [branch "cobalt"]
>remote = origin
>merge = refs/heads/cobalt
> 

___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] 1Gbit/20Mbit D/L with ack-filtering

[Dave Taht]

Wrote up that result here:

http://blog.cerowrt.org/post/ack_filtering/
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] cake flenter results round 2

[Pete Heist]

> On Nov 28, 2017, at 8:07 PM, Dave Taht  wrote:
> 
> Pete Heist  writes:
> 
>> *** Round 3 Plans:
>> 
>> * Use netem to test a spread of simulated rtts and bandwidths.
> 
> Since you are leveraging a few too few boxes, attached are my current
> scripts for fiddling a bit with network namespaces. I added individual
> ssh, irtt, etc, servers so that things like flent's ssh stuff should
> just work for polling stats.

You mean a few too few virtual boxes, not necessarily physical ones, right? :) 
In other words, there are different topologies that can be used for testing. In 
your scripts you’re simulating "Internet access", where client is the family or 
organization for example and server is stuff on the Internet:

client - middlebox - delay - server

In my earlier point-to-point WiFi testing I was simulating an ISP’s backhaul:

client - client_router - station - ap - server_router - server

In my current testing I’m simulating, well, something far less useful if I 
think about it- two boxes blasting traffic to one another over a cable and 
trying to improve queueing delays between them:

client - client_router --- server_router - server

I hadn’t realized how heavy-weight traffic generation for anything beyond 4/4 
flows would be at Gbit rates, or how confusing and trivial some of these 
results would be.

So beyond just my vague idea to “simulate a spread of rtts and bandwidths”, I 
see I need a topology change to produce something more useful. I think there 
are still two options:

1) Point-to-point WiFi again, where I’d be using two NSM5s and testing over 
short range at rates of up to 100 Mbps. I would probably try to get FreeNet’s 
APU version 1 boxes into action again so I’d have physical devices for each of 
the six roles above. I wish I didn’t have to use those RTL8111Es, but that’s 
how it is.

2) Your “Internet access” setup. Either I can get the veth stuff into action on 
a single physical APU2 (powerful enough?), or I can try to set up four physical 
boxes with the same topology (or if I were tricky, try to spread the four roles 
across two boxes).

#1 would be useful for FreeNet. Would it also be useful for Cake testing in 
general, or would you prefer more #2 results at this stage (i.e. simulating 
dsl, cable, satellite, etc)?

___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] cake flenter results round 2

[Dave Taht]

Pete Heist  writes:

>
> *** Round 3 Plans:
>
> * Use netem to test a spread of simulated rtts and bandwidths.

Since you are leveraging a few too few boxes, attached are my current
scripts for fiddling a bit with network namespaces. I added individual
ssh, irtt, etc, servers so that things like flent's ssh stuff should
just work for polling stats.

To get it setup, run

# ./vsetup.sh # basically go read *.sh
# ./vcake.sh # go read it
# ip netns exec server flent -H 10.10.2.2 yourtest

What's got me stopped is the network namespaces don't seem to let me
have an /etc/hosts file for dns lookup, as I'd wanted to have names
like mbox-l, mbox-r and the above IP, be "client".



veth.tgz
Description: application/gtar-compressed
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

[Cake] Simple metrics

[Dave Taht]

Changing the title of the thread.

Pete Heist  writes:

> On Nov 27, 2017, at 7:28 PM, Jonathan Morton  
> wrote:
> 
> An important factor when designing the test is the difference between
> intra-flow and inter-flow induced latencies, as well as the baseline
> latency.
>
> In general, AQM by itself controls intra-flow induced latency, while flow
> isolation (commonly FQ) controls inter-flow induced latency. I consider 
> the
> latter to be more important to measure.
>
> Intra-flow induced latency should also be important for web page load time and
> websockets, for example. Maybe not as important as inter-flow, because there
> you’re talking about how voice, videoconferencing and other interactive apps
> work together with other traffic, which is what people are affected by the 
> most
> when it doesn’t work.
>
> I don’t think it’s too much to include one public metric for each. People are
> used to “upload” and “download”, maybe they’d one day get used to “reactivity”
> and “interactivity”, or some more accessible terms.

Well, what I proposed was using a pfifo as the reference
standard, and "FQ" as one metric name against pfifo 1000/newstuff. 

That normalizes any test we come up with.

>
> Baseline latency is a factor of the underlying network topology, and 
> is
> the type of latency most often measured. It should be measured in the
> no-load condition, but the choice of remote endpoint is critical. Large 
> ISPs
> could gain an unfair advantage if they can provide a qualifying endpoint
> within their network, closer to the last mile links than most realistic
> Internet services. Conversely, ISPs are unlikely to endorse a measurement
> scheme which places the endpoints too far away from them.
>
> One reasonable possibility is to use DNS lookups to randomly-selected 
> gTLDs
> as the benchmark. There are gTLD DNS servers well-placed in essentially 
> all
> regions of interest, and effective DNS caching is a legitimate means for 
> an
> ISP to improve their customers' internet performance. Random lookups
> (especially of domains which are known to not exist) should defeat the
> effects of such caching.
>
> Induced latency can then be measured by applying a load and comparing the
> new latency measurement to the baseline. This load can simultaneously be
> used to measure available throughput. The tests on dslreports offer a 
> decent
> example of how to do this, but it would be necessary to standardise the
> load.
>
> It would be good to know what an average worst case heavy load is on a typical
> household Internet connection and standardize on that. Windows updates for
> example can be pretty bad (many flows).

My mental reference has always been family of four -

Mom in a videoconference
Dad surfing the web
Son playing a game
Daughter uploading to youtube

(pick your gender neutral roles at will)

+ Torrenting or dropbox or windows update or steam or ...

A larger scale reference might be a company of 30 people.


>
> DNS is an interesting possibility. On the one hand all you get is RTT, but on
> the other hand your server infrastructure is already available. I use the
> dslreports speedtest pretty routinely as it’s decent, although results can 
> vary
> significantly between runs. If they’re using DNS to measure latency, I hadn’t
> realized it.
>
> ___
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] cake flenter results round 2

[Pete Heist]

> On Nov 28, 2017, at 3:11 PM, Pete Heist  wrote:
> 
> * still don’t think I managed to get udp flood to work, must be doing 
> something wrong:
> 
> http://www.drhleny.cz/bufferbloat/cake/round2/udpflood_eg_fq_codel_900mbit/index.html
>  
> 
> http://www.drhleny.cz/bufferbloat/cake/round2/udpflood_eg_cakeeth_900mbit/index.html
>  
> 
Never mind, udp flood tests are working and copied up now. They'll probably be 
more useful at lower bandwidths.

Nice to see OWD, IPDV and loss in the voip tests… :)

___
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake