<mangix>
wonder how much of a bad idea it is to use a flash drive as /overlay
<aparcar[m]>
mangix: talk to dango, he's building a much smaller docker replacement
mattsm has joined #openwrt-devel
<Thermi>
mangix: docker is written in Go and that has no dynamic libs.
<Thermi>
What else did you expect?
Grommish has quit [Read error: Connection reset by peer]
Grommish_ has joined #openwrt-devel
Grommish_ is now known as Grommish
nitroshift has joined #openwrt-devel
Acinonyx_ has joined #openwrt-devel
rmilecki has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 260 seconds]
Grommish has quit [Read error: Connection reset by peer]
Grommish has joined #openwrt-devel
ashkan has joined #openwrt-devel
Grommish has quit [Read error: Connection reset by peer]
Grommish has joined #openwrt-devel
paulcarroty has joined #openwrt-devel
slh64 has joined #openwrt-devel
Grommish has quit [Read error: Connection reset by peer]
Grommish has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 265 seconds]
Acinonyx has joined #openwrt-devel
<mangix>
aparcar[m]: do tell
<mangix>
Thermi: I run docker on a different host that does not run OpenWrt. Don't really pay attention to sizes there.
<mangix>
lxc could be used as an alternative but that's not docker :)
<mangix>
alright. make package/x/refresh is officially difficult
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 246 seconds]
dedeckeh has joined #openwrt-devel
kakaka has joined #openwrt-devel
ivanich has joined #openwrt-devel
black_ant has joined #openwrt-devel
black_ant has quit [Changing host]
black_ant has joined #openwrt-devel
dottedmag has joined #openwrt-devel
<dottedmag>
I'm interested in building a firmware based on OpenWRT for a non-network-router device — a e-book with eInk screen. That includes a number of packages (these can go to a separate feed) and a new (actually, old resurrected) target. I'd like to keep this firmware as close to OpenWRT as possible and merge everything relevant back to OpenWRT.
<dottedmag>
So, should I submit to OpenWRT support for a target that's out of scope, or should I keep it separate?
<dottedmag>
The target in question is Ingenic XBurst MIPS. It was dropped from OpenWRT some time ago, and I'm not sure how useful it is here.
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
<paulcarroty>
dottedmag, submit it for sure
<dottedmag>
great, will do.
<dottedmag>
The target does not have to be fully functional to be merged, right? I've got a ton of old kernel patches, so it might take some time to sort and forward-port them all.
<zorun>
dottedmag, drop an email to openwrt-devel with details about the target (and how much work is likely needed to catch up), you will hopefully get more informed feedback
<dottedmag>
thanks
<zorun>
also, would that target have any in-tree device if merged back into openwrt? that's an important consideration
<zorun>
we have limited build resources, and targets that don't have many devices tend to bit-rot much faster
poljar has joined #openwrt-devel
poljar1 has quit [Ping timeout: 260 seconds]
<dottedmag>
sorry, what's in-tree device? the device openwrt supports? No. Previous incarnation had only another e-book as subtarget, bitrot (due to stale kernel) and was removed.
<dottedmag>
OTOH I can set up a CI node for making sure that at least the configuration from master builds.
Tost has joined #openwrt-devel
<zorun>
yes, the devices supported in openwrt
<paulcarroty>
zorun, Github/Gitlab CI open source credits aren't an option?
<dottedmag>
For a single build configuration I don't see a problem setting up a GH, GitLab, CircleCI or a privately hosted CI build - whatever turns out to be the easiest.
<dottedmag>
I'll need that for full eBook image anyway.
<rmilecki>
dottedmag: you should probably use "source-only" flag for such specific target
<rmilecki>
dottedmag: if it doesn't go with tons of patches (making OpenWrt harder to maintain), i think it may be accepted
<paulcarroty>
what's ebook we're talking about?
<rmilecki>
dottedmag: FEATURES:=source-only
<dottedmag>
paulcarroty: I'm resurrecting an old project of mine, OpenInkpot, and picking up the target it supported best (and HW for which I still have): https://wiki.mobileread.com/wiki/N516 - if this goes well, I'll try getting more eBooks supported.
<dottedmag>
rmilecki: got it, thanks
Borromini has joined #openwrt-devel
poljar1 has joined #openwrt-devel
Namidairo has quit [Read error: Connection reset by peer]
poljar has quit [Ping timeout: 265 seconds]
Namidairo has joined #openwrt-devel
<paulcarroty>
dottedmag, cool device but ancient. something like modern kobo or kindle will be much more interesting for contributors. guess they're locked down, sadly.
<dottedmag>
Old Kindles weren't - I still have a custom board that connects to a serial port in Kindle Keyboard that does not even require one to open the device.
<dottedmag>
New Kindles are.
<dottedmag>
I'll get to it once I have N516 running. Maybe other eBook manufacturers are not so interested in locking down their things.
<dottedmag>
paulcarroty: Yes, that's the "old kindles". I don't think Oasis and newer populate serial port header anymore, and their upgrade process seems to be locked down.
<dottedmag>
Though a nice hack to get old ones for cheap to play with :)
Neighbor11111116 has quit [Ping timeout: 240 seconds]
opal has joined #openwrt-devel
Neighbor11111116 has joined #openwrt-devel
opal has quit [Remote host closed the connection]
opal has joined #openwrt-devel
victhor has joined #openwrt-devel
dedeckeh has quit [Quit: Ping timeout (120 seconds)]
pine127 has quit [Remote host closed the connection]
kontaxis has quit [Remote host closed the connection]
kontaxis has joined #openwrt-devel
pine127 has joined #openwrt-devel
AnimaSMR has joined #openwrt-devel
AnimaSMR has left #openwrt-devel [#openwrt-devel]
<rsalvaterra>
Guys, does backport-5.4/020-backport_netfilter_rtcache.patch make sense? It was never even merged upstream, it wasn't forward-ported to 5.10, and I have this faint idea that route caches were dropped in favour of RCU route lookups, quite a while ago.
<stintel>
rsalvaterra: when in doubt, measure the difference?
<karlp>
well, ask who committed it to that directory?
<karlp>
backports are pretty explicitly meant to be backports...
plntyk has quit [Remote host closed the connection]
<rmilecki>
karlp: someone took it for a backport as it was sent for upstream inclusion
<rmilecki>
but patch was rejected after all apparently
Borromini has quit [Quit: Lost terminal]
<stintel>
so first we should figure out if it's still applicable / relevant for 5.10. if it is, test performance impact. if it's substantial it should be resubmitted and moved to pending-5.10 ?
<rmilecki>
sounds sane
<rmilecki>
testing should involve few targets
<rmilecki>
and comparing with offloading probabl
<rsalvaterra>
I don't know (yet, at least) how to test that, though. I stumbled upon that because I found some unused kconfig symbols.
<rsalvaterra>
Namely, CONFIG_IP6_NF_QUEUE (dropped in 3.5), CONFIG_IP6_NF_TARGET_LOG (dropped in 3.4), CONFIG_IP_NF_MATCH_DSCP (dropped in 2.6.19), CONFIG_NF_CONNTRACK_IPV4 (dropped in 4.19), CONFIG_NF_CONNTRACK_IPV6 (dropped in 4.19) and CONFIG_NF_CONNTRACK_RTCACHE (which was never merged).
<rmilecki>
rsalvaterra: how can we tell without testing speed improvement first? :)
<stintel>
rsalvaterra: 112 to 147 Mbps tells me yes
<rmilecki>
we need more tests I believe
<rmilecki>
and maybe verify if it still works at all
<rsalvaterra>
rmilecki: I have my doubts it's still relevant… but without measuring, it's just handwaving.
astylian has quit [Read error: Connection reset by peer]
paulcarroty has quit [Remote host closed the connection]
<rmilecki>
rsalvaterra: get two fast machines, connect 1 to WAN, connect one to LAN, setup IPs, make router do NAT between LAN & WAN
<rmilecki>
rsalvaterra: test speed without and with patch
<stintel>
no need
<stintel>
rmmod the module
<stintel>
and you might be able to leverage netns and test on a single machine but I've yet to get some real experience with that
<rsalvaterra>
rmilecki: Not really feasible on my side… :( If someone else tests it, I won't mind do the other part of the job (backporting or dropping, depending on the result). How about it? :)
<stintel>
my fast machines are using my L3/10GbE switch as GW so not super easy for me either
<stintel>
hmmz
Tapper has joined #openwrt-devel
<rsalvaterra>
One day, I'll have a home lab. Today isn't the day, unfortunately. :)
<stintel>
oh wait, I just revived my previous box
<stintel>
I can move it to a different VLAN
<rmilecki>
rsalvaterra: i'll keep this patch in mind, but can't promise when I find time to test it
<rsalvaterra>
stintel: Oh, I decided to go with cat.6a cabling on the new flat. Best bang for the €, at the moment… :P
<rsalvaterra>
rmilecki: No worries, thanks! :)
<stintel>
yeah I have some ugly 30m cat6a running next the walls :P
<stintel>
but I'm way past being bothered by that
<rsalvaterra>
Eheheh!
<stintel>
running 7.1.2 dolby atmos in a rental apartment ...
<stintel>
cables, cables everywhere!
<rsalvaterra>
You're officially crazy.
<stintel>
not to mention long USB cables to power ESP32/ESP8266/RPi0W's with various sensors etc :P
<rsalvaterra>
I'm not going past 5.1 in a flat. Ever.
<stintel>
well I went from 7.1 to 5.1.2 and that was awesome... for the few atmos sources + the amp didn't support the front height upfiring channel with DTS:X
<stintel>
so I got tempted and bought a new amp that can do 7.1.2 (the previous one was choice between 7.1 or 5.1.2)
<karlp>
stereo's where it's at :)
<rsalvaterra>
I'm still at stereo too. :P
<stintel>
actually it can do 7.2.4 but then I need 1 stereo PA extra
<stintel>
which I already built (DIY kit) few weeks ago
<stintel>
so now I am tempted to test front wide with the speakers from the bedroom 😂
<rsalvaterra>
stintel: I'd hate to be your neighbour. :P
<stintel>
well I have a duplex penthouse, the fun stuff is in the top floor, and no neighbor directly below me so there's 2 floors between me and the next
<rsalvaterra>
Ah, ok, that's fine.
<stintel>
and I put the sub on acoustic isolation stands, which greatly reduces the bass spreading via the walls
<stintel>
ah, that reminds me I'm still waiting for my new speakers :(
<rsalvaterra>
stintel: Do you use Kodi as media centre?
<stintel>
rsalvaterra: what else is there ;)
<stintel>
I'm using XBMC since Xbox1
<rsalvaterra>
:D
<stintel>
I even have the XBMC hoodie!
<stintel>
the one they were selling at the time of the rebrand
<rsalvaterra>
I started with OpenELEC, now I'm on LibreELEC. :P
<stintel>
I'm with CoreELEC because it worked best on VIM3 at the time I got it
<stintel>
but I'm not a fan of any of them
<stintel>
I should continue my meson target and update my kodi for openwrt packages
<stintel>
my main problem with *ELEC is that it's read-only and can't really use it for anything else than kodi
<stintel>
I'm allergic to those kind of things :P
<stintel>
there's a reason I'm running OpenWrt
<rsalvaterra>
Oh, I love statelessness. ;)
<rsalvaterra>
But that's the whole point… It's supposed to be an appliance.
<stintel>
well hence my reason for "porting" it to OpenWrt
<stintel>
but there was very little interest, and some demotivating response even
<rsalvaterra>
Sure, it you want to run OpenWrt on everything… :)
Acinonyx_ has quit [Ping timeout: 240 seconds]
<stintel>
OpenWrt on embedded, Gentoo on powerful stuff
<rsalvaterra>
I don't know… for everything involving GPUs, I prefer to run bleeding edge kernels. 5.10 is a bit long in the tooth already.
<stintel>
well all my rpi's run headless for example
<rsalvaterra>
Heh… I had a 1 B+ as a print/scan server, running OpenWrt. Unfortunately I had issues with SANE (the scanner would hang if you cancelled the scan, had to unplug the USB to fix it), so I had to decommission it.
Acinonyx has joined #openwrt-devel
<stintel>
ah I have a network printer/scanner
<stintel>
that does double-sided printing in double-pass and double-sided scanning in single pass. love that thing
dedeckeh has joined #openwrt-devel
valku has joined #openwrt-devel
nitroshift has quit [Quit: Gone that way --->]
muhaha has joined #openwrt-devel
Tapper has quit [Ping timeout: 240 seconds]
plntyk has quit [Remote host closed the connection]
* rsalvaterra
is on a crusade to kill both lzo and zlib …:P
* karlp
appreciates the portability of some boring traditional uncool things...
<karlp>
I mean, "kill zlib" seems excessive...
<rsalvaterra>
It's not killing… it's putting it out of its misery. :P
* karlp
infers from the lack of alterantive c impls, and from the omitted benchmarks that program size and memory usage are not goals of zstd, and may be a reason why some people still use "useless, inferior, legacy" trash :)
Zoxc has joined #openwrt-devel
<rsalvaterra>
karlp: Those are configurable… If you want high compression ratios, you pay with RAM and CPU time. ;)
* ldir
wants the moon on a stick - take loads of ram and inordinate amounts of cpu
rsalvaterra1 has joined #openwrt-devel
rsalvaterra has quit [Ping timeout: 248 seconds]
Neighbor11111116 has quit [Ping timeout: 260 seconds]
ashkan has quit [Quit: Konversation terminated!]
Neighbor11111116 has joined #openwrt-devel
rsalvaterra1 has quit [Quit: Leaving.]
rsalvaterra has joined #openwrt-devel
Dracos-Carazza has quit [Ping timeout: 248 seconds]
<karlp>
(admittedly, not zlib either, but there's tiny zlib compatible implementations too)
paulcarroty has joined #openwrt-devel
Tapper has joined #openwrt-devel
Zero_Chaos has joined #openwrt-devel
<Zero_Chaos>
Package iptables-nft is missing dependencies for the following libraries:
<Zero_Chaos>
libiptext6.so
<Zero_Chaos>
trying to build on the 21.02 branch
Tost has quit [Ping timeout: 265 seconds]
danitool has quit [Quit: Cubum autem in duos cubos, aut quadratoquadratum in duos quadratoquadratos]
pgwipeout[m] has quit [Quit: Idle for 30+ days]
finsternis has quit [Remote host closed the connection]
mm__ has joined #openwrt-devel
<rsalvaterra>
karlp: Uhh… that's a library for tiny MCUs, for sure. I'm positive zstd isn't supposed to be used on 80C51 and friends… :P
<karlp>
wel, zlib does get used in those places, or at least, zlib compatible :)
muhaha has quit [Quit: Connection closed]
<karlp>
so you can use the same tooling in both ends easily
<karlp>
anywya, zstd is rad, no complaints, just maybe we don't need to kill zlib :)
<rsalvaterra>
Oh, I don't mean killing in the general case! :)
Dracos-Carazza has joined #openwrt-devel
Slimey has quit [Read error: Connection reset by peer]
Slimey has joined #openwrt-devel
Neighbor11111117 has joined #openwrt-devel
Neighbor11111116 has quit [Ping timeout: 240 seconds]
Dracos-Carazza_ has joined #openwrt-devel
Dracos-Carazza has quit [Ping timeout: 265 seconds]
Neighbor11111117 has quit [Ping timeout: 248 seconds]
Neighbor11111117 has joined #openwrt-devel
Neighbor11111117 has quit [Read error: Connection reset by peer]
<rsalvaterra>
stintel, rmilecki, on a deeper analysis, I'm lead to believe 020-backport_netfilter_rtcache.patch is just broken.
<rsalvaterra>
I see several instances of #if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV6) in that patch…
<stintel>
rsalvaterra: I have that module loaded on all my routers
<rsalvaterra>
… CONFIG_NF_CONNTRACK_IPV6 has been dropped in Linux 4.19.
<rsalvaterra>
stintel: Running which OpenWrt versions?
<stintel>
rsalvaterra: master
<rsalvaterra>
Well, it surely isn't doing anything for IPv6, then.
<stintel>
with the strongswan breakage I noticed I haven't upgraded in a while (like 45 days) but recent enough
<stintel>
rsalvaterra: does anyone use IPv6 then?
<stintel>
(SCNR)
<stintel>
let
<rsalvaterra>
:P
<stintel>
let's see if I can do that setup to test
<stintel>
hmmmz should have ordered some extra Cat6a with those DACs :/
<stintel>
and I need to find the sheet of paper with the VLAN/subnet convention I came up with when configuring my 10GbE switch
<stintel>
welp
* rsalvaterra
was very happy to know Cat.6A doesn't require special tools for termination…
<rsalvaterra>
You're going to test conntrack at 10 Gb/s? Now that's torture. :P
<stintel>
:D
<stintel>
no no, on my spare ERL
<stintel>
so that there's no influence from real traffic
<stintel>
oh, I actually made an ods!
<rsalvaterra>
Uh?
<stintel>
open document spreadsheet (with the VLAN/subnet info)
<rsalvaterra>
Ah! I was totally out of context. :P
<stintel>
uhhh I wanna play with the CN6640 :(
astylian_ has quit [Ping timeout: 240 seconds]
<Grommish>
rsalvaterra: I've got a 350m spool of cat6a sitting next to me :D But i only use 2-part rj45 connectors, single piece connectors aren't worth the hassle
<Grommish>
Or, can always cheat and just get a keystone jack and punch it in
Acinonyx_ has joined #openwrt-devel
Acinonyx has quit [Ping timeout: 265 seconds]
shibboleth has joined #openwrt-devel
mm__ has quit [Quit: Connection closed for inactivity]
lukedashjr has joined #openwrt-devel
luke-jr has quit [Ping timeout: 265 seconds]
lukedashjr is now known as luke-jr
Borromini has joined #openwrt-devel
Neighbor11111117 has joined #openwrt-devel
cheakoirccloud has joined #openwrt-devel
goliath has quit [Quit: SIGSEGV]
Acinonyx has joined #openwrt-devel
j007 has joined #openwrt-devel
Acinonyx_ has quit [Ping timeout: 240 seconds]
paulcarroty has quit [Ping timeout: 248 seconds]
j007 has quit [Quit: Leaving]
madwoota has quit [Ping timeout: 265 seconds]
madwoota has joined #openwrt-devel
Tost has joined #openwrt-devel
zkrx has quit [Ping timeout: 265 seconds]
astylian_ has joined #openwrt-devel
<stintel>
argh, been on the phone for over 2h, let's see if I can get to testing
zkrx has joined #openwrt-devel
ivanich_ has joined #openwrt-devel
ivanich has quit [Remote host closed the connection]
Hayate has quit [Ping timeout: 268 seconds]
Tycale has quit [Ping timeout: 268 seconds]
Nyakajima has joined #openwrt-devel
Tycale has joined #openwrt-devel
astylian_ has quit [Ping timeout: 240 seconds]
<stintel>
pffft can't even get the firewall rules straight
<rsalvaterra>
Ouch… what happened? :P
<stintel>
I've been using this device for trying to reproduce the horrible WG breakage, with doing that renamed some interfaces etc
<stintel>
I allowed forwarding from test to wan but in fact I needed to allow from test to lan
<stintel>
I should probably start documenting my network a bit
<stintel>
had been eyeing netbox but overly complex imo
<stintel>
so it seems to me that nf_conntrack_rtcache is useless in combination with flow offload
<stintel>
and flow offload improves performance much better
<stintel>
so given that + fact that nf_conntrack_rtcache was never accepted upstream and flow_offload was ... we should probably just drop nf_conntrack_rtcache and focus on flow_offload
<stintel>
ahhh and rmmod nf_conntrack_rtcache on x86/64 -> crash
<stintel>
well maybe not a crash
<stintel>
but I almost can't believe those speeds without rtcache and without offloading
<stintel>
35Mbps?!
<stintel>
even with rtcache 65Mbps seems crazy
shibboleth has quit [Quit: shibboleth]
<stintel>
26|07:14:04< stintel> I'm doing 100/60 on EdgeRouter Lite
<stintel>
26|07:14:08< stintel> with sqm
<stintel>
that was december 2016. smells like a regression. then again I have always suspected a general network regression at some point
<stintel>
also with my apu2
<stintel>
I can probably try some official images, wiped config, and connect the spare ERL directly to 2 physical machines to do some comparisons between older openwrt/lede releases and now
<rsalvaterra>
stintel: Back, sorry for the delay.
<rsalvaterra>
Heh… rmmod is mostly best-effort, I think. :P
<rsalvaterra>
So, there's the reason why the rtcache patch wasn't merged. :)
<stintel>
well it predates flow offload afaik, and it does improve performance
ivanich_ has quit [Quit: Konversation terminated!]
<stintel>
pretty sure that's the reason we kept it
<rsalvaterra>
In any case, it's probably incompatible with SQM, just like flow offloading…
<stintel>
that's an interesting thought
* stintel
tries speedtest without sqm and without flow offload on his main router
<rsalvaterra>
Wait, you had SQM enabled?
<stintel>
no no the gist is without sqm
<rsalvaterra>
Phew… :P
<stintel>
and on a spare ERL, not doing an real traffic
<stintel>
but if disabling flow offloading shows a similar slowdown as enabling sqm on my main router ...
<stintel>
which kind of looks like it
<stintel>
so maybe enabling sqm just breaks flow offloading
rmilecki has quit [Read error: Connection reset by peer]
rmilecki has joined #openwrt-devel
black_ant has quit [Ping timeout: 240 seconds]
<rsalvaterra>
It does. I had some really weird latency spikes and wild throughput variability with SQM and flow offloading both enabled. Took me a while to figure out the cause.
rmilecki has quit [Ping timeout: 265 seconds]
indy has quit [Read error: No route to host]
indy has joined #openwrt-devel
<stintel>
hmmm.. would it be awkward if I ordered another pizza just 10 minutes after the first one was delivered :P
<rsalvaterra>
I don't think they're in the business of judging… :P
<stintel>
ERROR: package/feeds/routing/bird2 failed to build.
<stintel>
derp
Tapper has quit [Ping timeout: 260 seconds]
<jow>
stintel: rtcache is indeed obsolete since there's upstream endorsed flow offloading
<jow>
it was kind of a stop gap solution to speed up slow ar71xx/ath79
<stintel>
rsalvaterra: feel like sending a patch? jow can ACK it and I can merge it ;)
<rsalvaterra>
jow: Yay, thanks for the authoritative explanation. :)
<rsalvaterra>
stintel: Sure, let me cook it up. Should be faster than that pizza… :P
<stintel>
should we even nuke it from 21.02?
<stintel>
rsalvaterra: hahaa
<jow>
at some point netfilter performance nosedived with newer kernel versions
<stintel>
rsalvaterra: yeah, no dr oetker in storrage :P
<rsalvaterra>
Oh…
<jow>
but before flow offloading existed
* rsalvaterra
remembers already having bumped 5.10 to 5.10.28.
<jow>
so nbd merged the rtcache stuff which never ended up upstream
<stintel>
I might do some effort tomorrow to rip out the spare ERL from my rack, throw it between two beefy physical machines, and do some proper testing with default config
<stintel>
I'm no longer working full time, so I should have some more time for OSS, but will try to spread it between that and life
<jow>
as for flow offloading and sqm/qos... isn't that conflicting goals by definition?
<jow>
flow offloading is essentially kernel subsystem bypassing for most packets
<jow>
so no wonder stuff can't mangle these properly anymore
<rsalvaterra>
jow: Yes, especially when the SQM flow dissector does NAT lookups… :P
<rsalvaterra>
The connection still "works", but the performance is all over the place.
<philipp64>
how do you fail out of a init.d script that uses procd if you find a broken configuration?
<jow>
philipp64: one way is using procd_set_param error "whatever"
<jow>
this will still submit the service state to procd and register it, but procd will nto launch the process and indicate the errors in syslog instead
<philipp64>
how does that affect the flow of execution? does that return?
<karlp>
I've always just returned before procd_open_service.
<jow>
yes, it will return like any other call
<jow>
the other way is what karlp said, just don't submit the service
<jow>
means avoid calling procd_open_service or procd_open_instance (which implies procd_open_service)
<jow>
so essentially "return" before that point is reached
<rsalvaterra>
stintel: Refreshing the kernel patches (after deleting the rtcache patch)…
<jow>
time to hit the bed. bbl
<guidosarducci>
stintel: hey there, still seeing that weird perf behaviour w/wo sqm?
<stintel>
jow: nn!
<stintel>
guidosarducci: well yeah
<stintel>
guidosarducci: I don't have a super reliable way to test (speedtest.net), but it's pretty consistently much slower with SQM enabled
<stintel>
guidosarducci: but haven't done more debugging/reading/experimenting since you threw me that forum link
<stintel>
~745/605 w/o SQM and ~477/205 w/ SQM
<stintel>
but as I said, it's using speedtest.net (to a server of my own ISP though)
* stintel
tries to find that forum post in his 200 browser tabs :/\
<rsalvaterra>
stintel: You've got mail. :P
<stintel>
I noticed :p
<stintel>
too bed jow hit the sack already
<rsalvaterra>
No rush… 5.4 is going the way of the dodo, anyway… XD
<stintel>
but I can ack it :)
<stintel>
rsalvaterra: thanks, acked
<stintel>
I should probably hit the sack too. not working tomorrow but weather is improving so summer wheels
<rsalvaterra>
stintel: Oh, I remembered…
<rsalvaterra>
We probably should backport this to 21.x, right?
<stintel>
I think it makes sense
<rsalvaterra>
The patch I sent is against master.
<rsalvaterra>
(But it should apply to 21.x.)
<mangix>
rsalvaterra: in what way is 5.4 going the way of the dodo?
<rsalvaterra>
mangix: In the master's way… :P
<rsalvaterra>
… hopefully…
<mangix>
right. but not in kernel.org terms
<mangix>
4.4 will apparently be supported until 2037...
<stintel>
o_O
<rsalvaterra>
2037?! Jesus…!
<mangix>
yeah. japan wants super long LTS
<mangix>
for their street lights and whatnot
<mangix>
speaking of japan, I should probably email the NILFS2 maintainer...
<rsalvaterra>
Wait… they are *updating* their kernels in the street lighting system? Shouldn't that be a completely hermetic system? o_O
<rsalvaterra>
mangix: Gregkh's presentations are always brilliant. :)
<mangix>
funny, he said he'll probably have a stop light on his desk eventually
<mangix>
it always amazes me just how many changes get backported
Tost has quit [Ping timeout: 252 seconds]
<rsalvaterra>
mangix: Wouldn't shock me. Have you seen his box of USB devices? :P
<mangix>
i have not
<mangix>
I wonder if ksmbd should be moved to base
<Mister_X>
I have an old style traffic light with incandescent light bulbs, and thought about using it in my garage to let me know when it's good enough to close it
<mangix>
doing updates in the packages feed is a nightmare
<Mister_X>
there is a company that does boards to automatically switch between the different colors, but that's the boring thing to do
<stintel>
hurricos: I've got two of those cards. I didn't find 1GiB NAND, but didn't look very hard either. found the 64Mb NOR, and a 256Kb and a 512Kb I2C serial flash (never even heard of those)
<stintel>
hurricos: right now I'm waiting for some DAC cables so I can mess around with tftp from u-boot. I can probably help with sysupgrade