<Znevna>
oh please add support for my ap315!111naw
<Znevna>
morning.
<mrkiko>
Znevna: Morning
<mrkiko>
rmilecki: well, but it's also nice to see you workinb on BCM space, doing your best to support hardware which can be pretty hard to get working
<rmilecki>
mrkiko: thanks
<rmilecki>
the problem is it's some real niche and it's hard to get much help
<rmilecki>
i mean - some people are definitely trying to help - but you won't get straight answers
<dhewg>
I guess because there's no easy one
<dhewg>
but it sounds like this may happen on other platforms too
<rmilecki>
i'm sure it does, you can find a lot of forum posts complaining about perfroamnce drop between releases
<rmilecki>
those are very non-technical reports though, from people who usually can't even bisect
<dhewg>
I remcommend to nerdsnipe capable ppl while showing the issues on platforms they're working on :)
<dhewg>
like the two qca guys in here
* dhewg
ducks
cbeznea has joined #openwrt-devel
robimarko has joined #openwrt-devel
<robimarko>
rmilecki: Well, its a niche of a niche
<rmilecki>
apparently...
<robimarko>
Well, I am still trying to load the external module symbols into perf as well
<robimarko>
To actually see whats chewing up CPU time
<mrkiko>
robimarko: "none of them are hard" you mean all of them can be, with some hickups, used with no UART access
<robimarko>
mrkiko: Yes
<robimarko>
Almost all of them are installable without UART
<nbd>
rmilecki: hi. did you get the chance to run some performance tests with threaded NAPI?
<rmilecki>
nbd: i did no see improvement
<rmilecki>
but then I realized I use packet steering
<rmilecki>
I'll try threading again with all CPUs "enabled"
gch981213 has joined #openwrt-devel
<mrkiko>
I remember trying to port openwrt to an Netgear BCM device of which I don't remember the brand. I got at a point where It could not arrive to the CFE prompt, probably because I messed up with the JFFS2 partitions containing other CFE pieces or something. A night mare. :D
<nbd>
rmilecki: another thing: how much memory does your device have. how much is free in the wifi-off and in the wifi-on case?
<rmilecki>
plenty
<rmilecki>
# head -n 2 /proc/meminfo
<rmilecki>
MemTotal: 510328 kB
<rmilecki>
MemFree: 475372 kB
<rmilecki>
nbd: please note I don't even need interface up
zer0def has quit [Quit: zer0def]
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
<rmilecki>
nbd: without packet steering disabled (all rps_cpus set to 0) I get 650 Mb/s without wifi and with wifi
zer0def has joined #openwrt-devel
<rmilecki>
*with packet steering disabled
<rmilecki>
AKA *without packet steering
<dhewg>
maybe it's something that netifd does? It toggles some sysctls for example
<rmilecki>
dhewg: if you check my recent "Enabling WiFi slows down NAT (bcm53xx)" e-mail
<rmilecki>
you can see that all I need to reproduce this issue is to call: iw phy phy0 interface add ap0 type __ap
<dhewg>
oh alright
<dhewg>
does non-ap reproduce it too?
<nbd>
rmilecki: found a potential issue in the driver napi code that could cause some slowdown
<rmilecki>
dhewg: I can't have two "sta" interfaces or montor interface (brcmfmac doesn't allow it)
<rmilecki>
nbd: happy to test anything you may have
<oliv3r[m]>
how can I forcefully rebuild a tool? make just keeps telling me 'already up to date' (which it really is not)
<rmilecki>
nbd: sorry but it doesn't fix the problem :(
<oliv3r[m]>
and if I 'find' for any traces of it, other then the 'tool' dir, there's nothign.
srslypascal has quit [Ping timeout: 480 seconds]
<nbd>
dhewg: it's a firmware limitation
<rmilecki>
ok, this just got fun
srslypascal has joined #openwrt-devel
<rmilecki>
uci set wireless.radio0.disabled=0 && uci set wireless.radio1.disabled=0 && uci commit wireless
<rmilecki>
reload_config
<rmilecki>
== here wlan interfaces get setup and I get slow NAT ===
<rmilecki>
/etc/init.d/network restart
<rmilecki>
== here NAT gets back to stable 940 Mb/s ==
<nbd>
whee
<rmilecki>
nbd: there must be some magic bit in network setup by netifd that affects NAT performance
bluew has quit [Quit: Leaving]
<rmilecki>
a matter of order?
<rmilecki>
some sysctl bit?
<nbd>
netifd restart also brings down the wifi interfaces
<rmilecki>
yeah, but there are not disabled, so they go back up during netifd setup
<rmilecki>
they are up right now, part of br-lan and I get 940 Mb/s
<Znevna>
x.x
<nbd>
please trigger the issue and check how frequently the irqs of the brcmfmac cards fire
<rmilecki>
will do now
<rmilecki>
also after a reboot, NAT is still slow... so it's network restart (netifd network setup from scratch) *during runtime* that fixes NAT speed for me
<rmilecki>
wtf
<oliv3r[m]>
Anybody can point me where to find about how to force a rebuild of a package/tool? :)
<Mangix>
force push
<rmilecki>
oliv3r[m]: make package/foo/{clean,compile} V=s ?
<oliv3r[m]>
yeah it just says 'already'
<robimarko>
That aint gonna work for host tools
<oliv3r[m]>
ah, exactly
<Mangix>
yeah it will
<Mangix>
replace package with tools
<oliv3r[m]>
make: 'tools/libdeflate/' is up to date.
<oliv3r[m]>
so no, it won't work :D
<oliv3r[m]>
make tools/libdeflate/ compile V=sc
<Mangix>
you need to clean first
<Mangix>
or just wipe build_dir/host/libdeflate
<oliv3r[m]>
i did :p
<oliv3r[m]>
which is why I said 'find . -iname' won't find it
<oliv3r[m]>
`find . -iname ' libdeflate'
<f00b4r0>
there's a stamp in staging_dir iirc
<oliv3r[m]>
wouldn't find find it?
<oliv3r[m]>
find . -iname '*libdeflate*' to be more accurate
<oliv3r[m]>
ohhh wait, the staging dir is inside my container, and i'm searching outside of it!
<oliv3r[m]>
but, that's also not it alas
<Mangix>
you using docker?
<oliv3r[m]>
yeah
<oliv3r[m]>
and volume-mounted my source dir
<dhewg>
nbd: huh, so iiuc in theory a fw supporting it would make it work, since the hw would be capable?
<nbd>
i think so
<dhewg>
nice
<nbd>
but i don't think we will get such a fw
<dhewg>
because? marketing?
<nbd>
the primary target market for mt7921 is client devices
<nbd>
mesh support is irrelevant for that market
<nbd>
the only reason why AP support is in there is hotspot mode on mobile devices
<nbd>
and it's limited
<robimarko>
Look at Intel, selling client cards for years without AP mode at all
<Mangix>
ax200 and ax210 apparently can do 6ghz
<Mangix>
erm only the latter
<robimarko>
But that requires hacks
<robimarko>
Not like Intel advertises that
<Mangix>
yep
<dhewg>
yeah, it's limited, but I gotta say, I configured my notebook to use that router-usb-wifi exclusively, mostle because 6ghz is less populated, but it's stable as a rock and works very nicely
<Mangix>
i'm curious about that
<dhewg>
are there any mesh capable usb devices?
<Mangix>
where I live, nobody uses DFS channels on 5ghz
<robimarko>
Hehe, same here
<robimarko>
So channel 100 is always free
<Mangix>
yep
<dhewg>
same here, but the various devices used here refuse to connect to it on those channels
<Mangix>
luckily DFS doesn't kick me off, although it used to
<Mangix>
oh that is interesting
<Mangix>
actually what devices would those be?
borek has joined #openwrt-devel
<dhewg>
lame but frequently used stuff, from the top of my head my kid's tonybox, my cycling computer and an air purifier
<dhewg>
some work on some channels, but making them all work limits your channel options
<robimarko>
That crap I dont even attempt to run at 5GHz
<Mangix>
ah, I don't have devices like that
srslypascal has quit [Quit: Leaving]
<Mangix>
worst device I have is a printer that fails to connect if 802.11w is set to optional
<Mangix>
meaning no ax possible.
<robimarko>
Printers are always the worst thing possible
<dhewg>
same here, which is why I added an additional iot wlan for that crap
<dhewg>
on 2.4ghz then
<Mangix>
I think I'll just hardwire it
<Mangix>
Oddly enough I hate wires. I'm considering swapping keyboard and mouse for wireless ones.
srslypascal has joined #openwrt-devel
<rmilecki>
nbd: I don't see any significant amount of IRQs.
<rmilecki>
any idea how to dump network state after "reload_config" and after "/etc/init.d/network restart" to look for differences?
danitool has joined #openwrt-devel
<jow>
hmmm
<jow>
cmake in my openwrt buildroot begun picking up host libraries
<jow>
in my case it tries to link /usr/local/lib/libubox.so (built for x86_64) while compiling an image for mips 24kc
<jow>
it also discovers and uses libubox headers from /usr/local/include/libubox
<nbd>
rmilecki: i just went back to your original perf flamegraphs for the wifi-on and wifi-off case and noticed something odd
<nbd>
rmilecki: in the wifi-on case the output path includes cycles in br_dev_xmit
<nbd>
which i can't find in the wifi-off case
<karlp>
jow: any tips on resolving menu.d/blah.json problems? I get https://bin.jvnv.net/file/CH4SK.png and I've restarted rpcd, uhttpd, turned off the cache in luci,
<karlp>
I can't really see what I've got different in this menu.d file vs any others...
<nbd>
rmilecki: oh, never mind. they're just elsewhere
<karlp>
I get that error if I try to go directly to the page, it's obviously not turning up in the drop down menus either.
<nbd>
jow: can you please give me a build log of an affected package where it runs into this issue?
<karlp>
hah, the menu.d file had a "depends" clause with a uci entry...
<karlp>
removing that and I can navigate directly at least, still missing in the dropdowns.
<karlp>
baby steps
<jow>
karlp: dropdowns are cached client side
<jow>
karlp: or rather, the menu tree structure
<jow>
karlp: log out and in again, then it should update
<jow>
or use the browser debu console to clear session dta, then reload page
<karlp>
yup, that fixed the dropdowns,
<rmilecki>
nbd: can you think of any way of dumping kernel network state? anything else than readying sysctl?
<nbd>
make a tarball of /sys/class/net + a textfile with the ifconfig output before and after
<nbd>
use diff -ur afterwards
<rmilecki>
will try that ,thanks
cbeznea has quit [Quit: Leaving.]
<jow>
nbd: can't reproduce it after a clean/compile, I'll assume that it was a temporary glitch due to some unclean artifacts
bluew has joined #openwrt-devel
cbeznea has joined #openwrt-devel
<karlp>
jow: I've found luci-app-commands as an example app with .ut templates, so that's cool, but it also has ucode/controller/commands.uc, where does that run then? on the host, like an old lua controller?
<karlp>
it looks like generally, I can rename my lua templates from luarsc/blah/view/blah.htm to ucode/blah.ut, and just replace <%: text %> with {{_("text")}} and all my plain html+js will "just work" by the looks..
<karlp>
jow: ok, neat, wouldn't have found that. is there a way like for k,v in _ENV or something to print out all the variables that are already defined?
gch981213 has quit [Remote host closed the connection]
gch981213 has joined #openwrt-devel
gch981213_ has joined #openwrt-devel
Lynx- has joined #openwrt-devel
gch981213 has quit [Ping timeout: 480 seconds]
floof58 has quit [Quit: floof58]
floof58 has joined #openwrt-devel
floof58 has quit []
srslypascal has quit [Ping timeout: 480 seconds]
bjorn has quit [Ping timeout: 480 seconds]
Lynx- has quit [Ping timeout: 480 seconds]
<opty>
karlp: declare -p
<karlp>
{% declare -p %} and {{ declare -p }} are both empty on my view? does that mean it's blank, and you need a controller to provide anything? or am I holding it wrong?
minimal has joined #openwrt-devel
<rmilecki>
ok, i found out why /etc/init.d/network restart brings back 940 Mb/s NAT
<stintel>
wasn't a big fan of that init script approach, also because it uses hardcoded interface names, but didn't have the time to properly review it
<dhewg>
it hardcoded it to every interface
<dhewg>
how about per interface user uci settings, which that thing uses instead if it exists
<dhewg>
oh, the bcm script hardcodes names
<jow>
karlp: it is parsed as `declare - p`, `null - null`
<jow>
karlp: whch expands to the empty string when iterpolated
<nick[m]12>
any tips dumping the mtd partitions via serial console? I thought I could use base64, and write screen output to file, and decoce again. However, base64 always errors
<mrkiko>
nick[m]12: if you have minicom and it's accompanying tools lzrs or osmething, you may be able to do that
<PaulFertser>
nick[m]12: probably od or hexdump are available?
<jow>
karlp: use backtick strings, those are allowed to be multiline
<dhewg>
nick[m]12: that definitely works, I've messed up patches often enough to do exactly that and the reason I always enable the lrzsz package in my builds