I'm in no position to help (on the road). But please test also cake's
4 and 8 tin modes on arm and mips. Does cake besteffort work on mips?
On Sun, Jul 1, 2018 at 9:49 AM Pete Heist <[email protected]> wrote:
>
> Ok, my reboots were because I need to compile with om-watchdog support, 
> otherwise the OM2P’s hardware watchdog reboots every few minutes. Thus, my 
> sysupgrades were not _actually_ working (watchdog was interrupting them), 
> thus the unknown symbols / dependency problems, etc, so that’s behind me. :/
>
> And yes, I get no tin stats without the patch. With the patch, I get tin 
> stats as expected. This is probably nothing new.
>
> I also compiled on a Raspi 2 (32-bit ARM) running Debian 9.4, and it works as 
> expected without the patch. This probably just confirms what George reported, 
> because I think his wrt1900acs also uses 32-bit ARM.
>
> So yes, MIPS 32-bit, both le and be are both fails. What next? We could test 
> more archs, but it might be more productive to attempt to figure it out in 
> the code when I can at least repro it on MIPS.
>
> You mentioned earlier netlink_parse_nested doesn’t seem to handle 64-bit 
> values but I’m not seeing where that is. I’m getting my head around how stats 
> work so just writing out loud…looks like there are qstats from struct Qdisc 
> then the tin stats which are probably custom for Cake and stored at some 
> address obtained from qdisc_priv, which is right after the regular Qdisc 
> struct. Interesting. I’m searching now for how this data ends up in tc’s 
> hands, which looks like happens in cake_print_xstats with 
> parse_rtattr_nested, then the printing gets underway, and at some point if 
> st[TCA_CAKE_STATS_TIN_STATS] is true it gets into the tin printing business. 
> What’s the condition that fails to make the tin stats not be printed? Best I 
> know is to add debugging statements to figure it out, which I might give a 
> try later today. Am I on the right track?
>
> > On Jul 1, 2018, at 9:18 AM, Pete Heist <[email protected]> wrote:
> >
> > Ok, so I’ve got to figure out what’s up with my build in general, so I’m 
> > blowing away my source tree and will build master without any patches.
> >
> > I don’t know if the kernel panics and unknown symbols are related somehow, 
> > but they’re not helping(!) so I’ll try to get past that. I don’t actually 
> > get logs in /sys/kernel/debug/crashlog, so I can’t even prove it’s a panic, 
> > but it’s rebooting that usually happens just as I do something net related, 
> > like start typing in ssh or do an scp, after some period of inactivity. If 
> > it’s reproducible on an unpatched build I’ll head over to the OpenWRT 
> > universe.
> >
> > (the stats alignment is just proportional vs fixed fonts- they look fine in 
> > vim)
> >
> >> On Jul 1, 2018, at 4:37 AM, Georgios Amanakis <[email protected]> wrote:
> >>
> >> The stats got mangled in by the email, in the terminal they are
> >> properly aligned.
> >>
> >>
> >> ---------- Forwarded message ----------
> >> From: Georgios Amanakis <[email protected]>
> >> Date: Sat, Jun 30, 2018 at 10:35 PM
> >> Subject: Re: [Cake] Cake on openwrt - falling behind
> >> To: Pete Heist <[email protected]>
> >>
> >>
> >> I just tested this on my wrt1900acs but it is behaving as it should. I
> >> used Kevin's RFC patches for iproute2 and kmod-sched-cake.
> >>
> >> root@lede:/tmp# tc -s qdisc show dev eth0
> >> qdisc cake 8004: root refcnt 9 bandwidth 2500Kbit diffserv3
> >> triple-isolate split-gso rtt 100.0ms raw overhead 0
> >> Sent 122745 bytes 691 pkt (dropped 0, overlimits 419 requeues 0)
> >> backlog 0b 0p requeues 0
> >> memory used: 6416b of 4Mb
> >> capacity estimate: 2500Kbit
> >> min/max network layer size:           42 /    1186
> >> min/max overhead-adjusted size:       42 /    1186
> >> average network hdr offset:           13
> >>
> >>                  Bulk  Best Effort        Voice
> >> thresh      156248bit     2500Kbit      625Kbit
> >> target        116.3ms        7.3ms       29.1ms
> >> interval      232.6ms      102.3ms      124.1ms
> >> pk_delay          0us        196us        8.6ms
> >> av_delay          0us         13us        1.3ms
> >> sp_delay          0us          2us         38us
> >> backlog            0b           0b           0b
> >> pkts                0          414          277
> >> bytes               0        38367        84378
> >> way_inds            0            0            0
> >> way_miss            0           20            2
> >> way_cols            0            0            0
> >> drops               0            0            0
> >> marks               0            0            0
> >> ack_drop            0            0            0
> >> sp_flows            0            1            0
> >> bk_flows            0            0            1
> >> un_flows            0            0            0
> >> max_len             0          206         1186
> >> quantum           300          300          300
> >>
> >> root@lede:/tmp# opkg list-installed | grep cake
> >> kmod-sched-cake - 4.14.50+2018-06-26-0520a6cb-1
> >>
> >> root@lede:/tmp# uname -a
> >> Linux lede 4.14.50 #0 SMP Wed Jun 27 21:48:32 2018 armv7l GNU/Linux
> >>
> >> George
> >>
> >> On Sat, Jun 30, 2018 at 7:20 PM, Pete Heist <[email protected]> wrote:
> >>> Ok, same result (unknown symbols and routine crashing) after a make clean 
> >>> and re-build, but I just force installed the kmod-sched-cake package with 
> >>> --force-depends and it seems to work. This reproduces it, right? no stats 
> >>> and the debug output?
> >>>
> >>> root@LEDE:~# tc qdisc add dev eth0 root cake
> >>> root@LEDE:~# tc -s -d qdisc show dev eth0
> >>> qdisc cake 8001: root refcnt 2 bandwidth unlimited diffserv3 
> >>> triple-isolate rtt 100.0ms raw overhead 0
> >>> tca_stats 2005579564 tca_stats2 0 tca_xstats 0
> >>> calling print_tcstats_attr()
> >>> print_tcstats_attr()
> >>> got stats
> >>> Sent 9070 bytes 66 pkts (dropped 0, overlimits 0)
> >>> got xstats 0 tca_stats 2005579564 tca_stats2 0 tca_xstats 0
> >>>
> >>> root@LEDE:~# cat /proc/cpuinfo
> >>> system type             : Atheros AR7240 rev 2
> >>> machine                 : OpenMesh OM2P
> >>> processor               : 0
> >>> cpu model               : MIPS 24Kc V7.4
> >>> BogoMIPS                : 265.42
> >>> wait instruction        : yes
> >>> microsecond timers      : yes
> >>> tlb_entries             : 16
> >>> extra interrupt vector  : yes
> >>> hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 
> >>> 0x0ffc, 0x0ffb, 0x0ffb]
> >>> isa                     : mips1 mips2 mips32r1 mips32r2
> >>> ASEs implemented        : mips16
> >>> shadow register sets    : 1
> >>> kscratch registers      : 0
> >>> package                 : 0
> >>> core                    : 0
> >>> VCED exceptions         : not available
> >>> VCEI exceptions         : not available
> >>>
> >> _______________________________________________
> >> Cake mailing list
> >> [email protected]
> >> https://lists.bufferbloat.net/listinfo/cake
> >
>
> _______________________________________________
> Cake mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cake



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake

Reply via email to