**** BEGIN LOGGING AT Sat Sep 05 02:59:57 2020
Sep 05 04:34:41 <Grommish> I need to point a package to the lib and include direcotry, and it's in the build_dir/target-mips64_octeon3_64_musl/root-octeon directory.  Does anyone know the short-code for that?
Sep 05 04:56:33 <Grommish> *facepalm* It's just $(STAGING_DIR)/usr/libs
Sep 05 09:13:26 <aparcar[m]> mangix: ping
Sep 05 09:14:08 <aparcar[m]> Grommish: yea the more you jump around in the build system the more you love all those long paths and the variables
Sep 05 09:14:46 <Grommish> I just wish there was a cheat sheet for the common ones :)
Sep 05 09:15:12 <aparcar[m]> feel free to write some docs :)
Sep 05 09:15:24 <Grommish> I've thought out it
Sep 05 09:20:55 <nbd> aparcar[m]: ping
Sep 05 09:21:04 <aparcar[m]> nbd: pong
Sep 05 09:21:44 <nbd> just wanted to give you a heads up, got a complaint about a significant build system performance regression, which i tracked down to your SOURCE_DATE_EPOCH changes
Sep 05 09:22:12 <nbd> i just made a fix that simply evaluates PKG_SOURCE_DATE_EPOCH once per package directory instead of in the per-target rules
Sep 05 09:22:36 <nbd> should be fine, right? it only gets passed the package source dir after all
Sep 05 09:22:48 <aparcar[m]> can I please see the patch?
Sep 05 09:23:15 <nbd> sure
Sep 05 09:23:21 <nbd> https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=commitdiff;h=0d8ffcece74d1978209acec87191c044af879c2b
Sep 05 09:24:37 <nbd> before the change, make package/linux/compile was taking 2 minutes, afterwards only 9 seconds
Sep 05 09:24:48 <aparcar[m]> awakward
Sep 05 09:24:54 <aparcar[m]> amazing thank you very much
Sep 05 09:25:14 <nbd> you put the $(shell) call in per-target rules, which means that make had to call it over and over again
Sep 05 09:25:25 <aparcar[m]> I'm not yet on the buildsystem master level so fail to see those issues
Sep 05 09:25:29 <nbd> no problem
Sep 05 09:25:46 <nbd> just thought i'd point it out and explain it to you so you know what to look out for
Sep 05 09:25:57 <aparcar[m]> that's actually great news because I though fakeroot would be the isue
Sep 05 09:26:14 <aparcar[m]> yea next time I'll keep that in mind!
Sep 05 09:26:48 <aparcar[m]> thank you very much for the quick fix
Sep 05 09:26:53 <nbd> you're welcome
Sep 05 09:27:08 <nbd> pushed to master now
Sep 05 09:27:27 <aparcar[m]> dangole: nbd fixed the slow buildbot issue, it wasn't fakeroot after all 💃
Sep 05 09:36:54 <aparcar[m]> nbd: well please apply to master :)
Sep 05 09:37:14 <nbd> already did a few minutes ago
Sep 05 09:37:19 <nbd> 11:27 < nbd> pushed to master now
Sep 05 09:41:58 <aparcar[m]> ack
Sep 05 09:42:32 <stintel> ah that sounds good
**** BEGIN LOGGING AT Sat Sep 05 10:31:09 2020
Sep 05 16:57:53 <wigyori> DonkeyHotei: that forward, was it me? :)  i'll see tonight if i can do that
Sep 05 16:58:13 <DonkeyHotei> yes
Sep 05 17:00:02 <greearb> btw, someone reports 5.8 kernel sucks with ath10k-ct:  https://github.com/greearb/ath10k-ct/issues/152#issuecomment-687608968
Sep 05 17:00:36 <greearb> from their comments, likely not just driver related, as 5.8 kernel is implicated, and not firmware related, afaik, since just changing kernel/driver causes crap.
Sep 05 17:01:17 <greearb> if someone can work with them to tell them how to disable ATF and/or some of the other low-latency stuff in 5.8, maybe that is a way to narrow down the issue?
Sep 05 17:01:42 <greearb> actually, I should check if they are using owrt or not
Sep 05 17:02:03 <greearb> oh, just ubuntu...well bugger, I'll work with them
Sep 05 17:04:29 <svanheule[m]> greearb: I did some throughput test earlier with stintel's patch to bring 5.8 to owrt
Sep 05 17:05:04 <svanheule[m]> greearb: download was at ~320Mb/s (with intel ax200 on windows)
Sep 05 17:06:19 <greearb> this user reports bad ping times and pkt loss.  They are using wave-2 radios, which might have some bearing since the driver treats tx path different than with wave-1
Sep 05 17:06:50 <svanheule[m]> greearb: upload results were mixed. Upload (iperf3 -R) maxed out at ~230mb/s, but some tests dropped a lot of packets
Sep 05 17:06:54 <greearb> interestingly, my 5.4 driver in 5.8kernel is improvement, but not fix, so likely multiple issues in 5.8
Sep 05 17:07:03 <svanheule[m]> I used a qca9982, so also wave-2
Sep 05 17:07:04 <greearb> ax200 sucks at upload
Sep 05 17:14:16 <svanheule[m]> with the stock firmware, throughput was the same for up- and download, although I only did one iperf test in each direction
Sep 05 17:15:18 <greearb> happen to test stock driver?
Sep 05 17:15:38 <svanheule[m]> more precisely: donwload: 337 Mbps, upload: 371 Mbps
Sep 05 17:16:15 <greearb> ok, so maybe upload to AP with stock fw vs ct fw?
Sep 05 17:16:28 <greearb> maybe better, I mean
Sep 05 17:16:46 <svanheule[m]> yes, upload was better with stock fw than ct fw
Sep 05 17:16:53 <svanheule[m]> download was about the same
Sep 05 17:16:55 <greearb> same driver?
Sep 05 17:17:27 <svanheule[m]> ah, no. With "stock fw" I meant the entire image for the device
Sep 05 17:17:45 <greearb> oh, ok that could easily be stack related then
Sep 05 17:17:48 <svanheule[m]> including whatever driver the vendor included
Sep 05 17:18:11 <svanheule[m]> I can test with stock atk10k fw, if you like
Sep 05 17:18:43 <greearb> all datapoints are interesting to me, there are so many moving parts in owrt that it is hard to know where regressions might enter
Sep 05 17:19:06 <svanheule[m]> alright, let me see if I can get stock fw to work with the ct driver then :)
**** BEGIN LOGGING AT Sat Sep 05 17:23:52 2020
Sep 05 18:16:58 <svanheule[m]> greearb: how would I recognize a compatible FW file? stock image has two ~350kB files in /lib/firmware/AR900B/hw.2: athwlan.bin and utf.bin
Sep 05 18:17:37 <svanheule[m]> using athwlan.bin as firmware-5.bin, I get "invalid firmware magic"
Sep 05 18:35:34 <greearb> I meant the upstream qca firmware, selectable as option in openwrt, of you can DL it from ath10k-firmware repo or whereever and copy it into place
Sep 05 19:16:31 <svanheule[m]> greearb: okay, that makes more sense :)
Sep 05 19:17:11 <svanheule[m]> using firmware-5.bin_10.4.1.00030-1, down/up is 100/28 Mbps
Sep 05 19:17:25 <svanheule[m]> but upload is at least consistent over multiple attempts
**** BEGIN LOGGING AT Sat Sep 05 19:54:07 2020
Sep 05 20:06:37 <lynxis> rpavuc
Sep 05 20:16:03 <greearb> svanheule[m], so upstream FW is noticeably worse?
Sep 05 20:16:39 <svanheule[m]> greearb: yes
Sep 05 20:18:17 <greearb> how about if you use stock driver as well?
Sep 05 20:42:12 <svanheule[m]> with upstream driver+upstream firmware down/up is: 140/40 Mbps
Sep 05 20:43:26 <svanheule[m]> and no retries on the 3 upload tests
**** BEGIN LOGGING AT Sat Sep 05 21:41:17 2020
**** BEGIN LOGGING AT Sat Sep 05 22:26:32 2020
**** BEGIN LOGGING AT Sun Sep 06 00:10:39 2020
**** BEGIN LOGGING AT Sun Sep 06 00:32:41 2020
**** ENDING LOGGING AT Sun Sep 06 02:59:57 2020