Rpi4 < $(community_build)

Community Builds, Projects & Packages
725

no ~931 is the restriction... ( not cpu )

ive never used pie... should be cake for that shaper...

off-topic-note: realized recently that script should really be called;

ctinfo_8layercake_rpi4.qos

due to it instantiating with diffserv8... but i'm happy to just keep the name aligned with where it was pilfered from for provinence reasoning...

i've never really provided much guidance for the SQM-CONFIG setting for use with that script...

verbage

partly because i'm not sure what it can support... but for reference... i've always used it with a bone standard up/down on single wan with practically no other options...

sqm.wan=queue
sqm.wan.interface='eth1'
sqm.wan.download='49470'
sqm.wan.upload='16980'
sqm.wan.linklayer='none'
sqm.wan.enabled='1'
sqm.wan.qdisc='cake'
sqm.wan.script='ctinfo_4layercake_rpi4.qos'
sqm.wan.debug_logging='1'
sqm.wan.verbosity='5'

up to you... but you need to ressign eth0 interrupt affinity (or use packet_steering ) to achieve max throughput...

verbage

i (got off my rear) ran controlled 'internal-fake-GB-wan' testing yesterday ( @dlakelan did so a long time ago ) with and without sqm... so we know where the main impediments are... we just don't know what is 'perfect'-value-s/sane-default/alternate nic behavior... which is something only a user comfortable with messing with IRQ etc. can really assist with... even with my mediocre ( witness-me ) skills its difficult to isolate or interpret tweaking all of these values...

fwiw... i'm now semi-randomly setting...

echo -n c > /proc/irq/32/smp_affinity
echo -n c > /proc/irq/33/smp_affinity
echo -n a > /sys/class/net/eth0/queues/*/*_cpus

and to avoid panic / confusion... most of this is only really relevant for people with WAN OVER ~250-350Mb/s hence why it took me so long to dig into this at all...

726

this graph is pretty interesting/evident... the spike at the end of monday is the perf testing with defaults which was cpu bound...

you can see high sirq and little to no load on cpu3/4 in the proceeding days...

tuesday onwards are with the current tweaks... sirq barely registers and load is distributed much more evenly across all cores... ( the big spike on tuesday are identical perf tests yet thresholds are almost halved due to interrupt levelling and better cpu allocations )

week-perf1-CPU
week-perf1-CPU714×785 89.2 KB

edit: higher base-clock of 900000 likely effected the normalisation of the current tweak results...

1 Like
727

@anon50098793

Tried your build and couldn't find any poweroff button. Is it hidden somewhere? Could only find reboot. Didn't want to corrupt the SD card. Had to SSH in to use poweroff command. Any shortcut for this?

1 Like
728

system > custom_commands > docmd@ARGUMENTS: "poweroff" > click RUN

2 Likes
729

@anon50098793
Seems like changing wifi to VHT80 or 80mhz channel width kills all wifi, requires reboot.

Is VHT80 working for you?

730

you may wish to start here then look into this both via the raspberrypi forums or a specific thread on the general forum...

apart from making sure;

  • wpad is enabled/started...
  • wpad-openssl<->wpad... (unlikely to create probs)
  • some alternative defaults... (will not create probs)

nothing about the rpi4 wifi is build specific and most people who can help you likely don't read / post on this thread...

1 Like
731

Damn you're fast at replying. :grinning:

No, its fine. Just want to let you and others know about it, 80mhz onboard is a nono.

Since you're here and it hasn't been mentioned anywhere, I stumbled upon this.

https://mlapp.cn/376.html

https://www.youtube.com/watch?v=6NHwnvsMPqk

The chinese scene towards SBC are unexpectedly great. Thought it would be a good read, with google translate.

Don't think anyone has done docker openwrt RP4.

1 Like
732

up to you... but you need to ressign eth0 interrupt affinity (or use packet_steering ) to achieve max throughput...

How do I do this?

echo -n c > /proc/irq/32/smp_affinity

Goes through.

echo -n c > /proc/irq/33/smp_affinity

nonexistent directory

echo -n a > /sys/class/net/eth0/queues//_cpus

nonexistent directory

733

those commands were examples for

I have provided a means and instructions from which to do so... otherwise you may need to wait until others have fully test

734

Ah those instructions was for that, I will try them out!

Edit: Just with

curl -sSL https://raw.githubusercontent.com/wulfy23/rpi4/master/utilities/20-smp-packet-steering > /etc/hotplug.d/net/20-smp-packet-steering
#and reboot or restart networking

I am hitting my target speed with SQM, should I test the rest too?

image_2021-04-07_174816
image_2021-04-07_1748161095×700 50.8 KB

1 Like
735

great... so you pulled down the main part which was the packet_steering (FORCEON) for testing ... then rebooted...

if you have improved speeds... then there is no real need to run the other (2nd) script from which you would have needed/wanted to test mostly the IRQ-AFFINITY part...

no... you don't really need it... what you can do is run

htop

then do a speedtest... (edit: it's worth using a few sites as they vary how they work)

and look for peaks of over 80% on any core...

736

Peaked at 60%.

1 Like
737

excellent news!

thankyou very much for testing and providing valuable feedback...

738

No problem, if there's anything else you want me to test, let me know.

1 Like
739

htop is sometimes also a little slow also...

you can also run 'top' then press 'c' and watch the idle column... it's inverted... ( i.e. 100% means no load )...

or in htop there is F2 > display options > Update Interval ( set it to 0.5 or something )

740

Doing a couple of htop speed tests more, it spikes to 96%. But I have seen this once of like 20 speedtests. It goes frequently to high 80~%.

No OC.

1 Like
741

What about wireguard? Heard you need to OC to get maxed wireguard speeds.

742

fyi... you'll likely find this is from nlbwmon/collectd_sqm kicking up and gathering stats for brief spikes every 30seconds or so...

script2 partly addresses this (or provides tools to) or power users may wish to disable those either during testing or on an ongoing basis...

to be honest tho' i'm pretty damn happy with my 50/15... ( I have no idea what you guys would ever do with that kind of bandwidth... apart from maybe site-to-site large backups... sell it to the neighbours? )

yes... I am a little jealous... just a little :wink:

743

WG is capping everything around 500-700~ so I am running it client side.

744

Should I just test all the steps instead?

1 Like