[Cake] cake flenter results round 2

[Dave Taht]

Pete Heist <peteheist at gmail.com> writes:

>> On Nov 28, 2017, at 8:07 PM, Dave Taht <dave at taht.net> wrote:
>> 
>> Pete Heist <peteheist at gmail.com> 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 100000
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 haven't taken apart the
tarball from the last attempt yet. 16x1, 10x1 results with ack filtering
against DSL speeds and typical cable speeds seem plausible.