New Raspberry PI 4
 

Please send your impressions using it with mlucas :smile:

[url]https://www.raspberrypi.org/blog/raspberry-pi-4-on-sale-now-from-35/[/url]

Looks good from a cost/expected-performance perspective ... the Odroid N2 a73 core runs at 1.8GHz vs the Pi4's a72 @1.5GHz, so assuming the RAM/caches are similarly good at keeping the CPU fed, Pi4 should run at ~80% of the N2's a73 CPU, for a little over half the cost, including the minimum accessories.. As I've noted over in the next-gen Odroid thread, running a second Mlucas job on the 2xa53 sub-CPU of the N2 only boosts total throughput by around 1/8th, due to memory contention. Looking forward to seeing some timings from a purchaser of one of these - Luigi, did you order one or are you waiting for someone else to try before you decide whether to buy?

[b]Edit:[/b] Only saw [url=https://mersenneforum.org/showthread.php?t=24540]this thread on the Pi4 over in Hardware[/url] after writing the above ... so a 28nm process vs the N2's 12nm, that will likely need an added heatsink/fan to prevent throttling (the N2 somes with a big honking heatsink covering the bottom of the board, in my monthlong all-6-cores Mlucas running I detected no throttling.) And the Pi4 ships with 32-bit Raspbian, ugh - you'll want to load a 64-bit Linux to run Mlucas, since the Mlucas SIMD build requires it.

I'll get one as soon as I can. Yesterday, when I heard the news, there were 15 pcs left of the 2GB version on Farnell, but being at work, had to do other things for a short while. And when I came back, those had gone. Now their website shows that the next batch (both 2GB and 4GB models, but no info on 1GB) will arrive on September 23rd, but those estimates have been wildly inaccurate in the past, at least for the last couple launches (3B+ and 3A+)

I just wonder how much magic will be needed to make all the new bits work in e.g. Gentoo, but let's hope that someone else does the work by the time I get the device. :smile:

Nomead, when your Pi4 arrives and you have a 64-bit install, I'll be interested in the CPU temps running Mlucas on all cores. Over in the next-gen odroid thread someone mentioned using 'cat /sys/class/thermal/thermal_zone0/temp' (divide result by 1000 to get temp in C) to monitor temps ... my Odroid C2 - no fan but with a 40x40mm factory-mounted heatsink, and the board inside a clear plastic case, which is surely not good for temps but crucial to allow the thing to be handled to plug in stuff - typically ranges 60-70C, and only starts to show signs of throttling (based on Mlucas checkpoint timings) around 70C and above.

[URL]https://www.cnx-software.com/2019/06/27/nanopi-m4-price-drop-rk3399-sbc/#comment-564167[/URL]
[quote]With all packages updated my RPi 4 now idles at close to 65°C (ambient temp 27°C).[/quote]That doesn't look good :sad: I hope it's not representative...

[QUOTE=ldesnogu;520167][URL]https://www.cnx-software.com/2019/06/27/nanopi-m4-price-drop-rk3399-sbc/#comment-564167[/URL]
That doesn't look good :sad: I hope it's not representative...[/QUOTE]

Oof - I mean, how much effort would it have required, during Pi4 board development, to experiment with a couple different CPU+RAM configurations to find a quasi-optimal one from a thermal standpoint, and slapping a small Alu heatsink on at the factory would cost an extra what, maybe 50 cents? We'd be happy to pay a couple bucks more for a Pi4 which can actually run under load without massive throttling, guys. The article you link does note this:
[i]
so far one of the cheapest RK3399 boards was NanoPi M4 going for $65. FriendlyELEC has now decided, certainly in response to Raspberry Pi 4 offering, to lower the price to $50 for the 2GB RAM version which compares to $45 with Raspberry Pi 4 2GB
[/i]
The NanoPi M4 is 2xa72 + 4xa53, so using the general rule that an a72/a73 core = 2 a53 cores an ignoring throttling and multi-CPU memory contention issues, here are the relative strengths of the various offerings being discussed around here in terms of 'equivalent a53 cores':

o Odroid C2: 4
o NanoPi M4: 8
o RPi4: 8
o Odroid N2: 10

But designed-to-throttle-under-load-ness will knock the number down, potentially by as much as 2x. Hopefully one of our RPi4 guinea-piggers will find a relatively cheap way to affix a heatsink and get some airflow around same. In a sense it's not that different from my Galaxy S7-compute-cluster phones, which need external airflow to keep throttling levels reasonable under load, although those at least use a highly sophisticated compact internal heat-spreading system to get the heat out to the case.

Also the RK3399 has higher frequency than the Pi 4. The NanoPi M4 looks a better choice to me.



An article about the throttling issue in Pi 4: [url]https://www.cnx-software.com/2019/06/27/raspberry-pi-4-benchmarks-heatsink-edition/[/url]


The heatsink is definitely required.

I'm guessing under all-cores SIMD-using load, there will be much larger than a mere 20% throttling penalty, sans heatsink. With heatsink, a good "free airflow" place for the unit might be next to a vent fan in an ATX-cased system - even if the exhaust air is warm from the PC's CPU, warm moving air beats room-temp still air, as long as its temperature is still appreciably less than that of the Pi4 CPU. Or one could stack several PI4s-with-heatsink next to a USB fan.

[QUOTE=ldesnogu;520217]Also the RK3399 has higher frequency than the Pi 4. The NanoPi M4 looks a better choice to me.

An article about the throttling issue in Pi 4: [URL]https://www.cnx-software.com/2019/06/27/raspberry-pi-4-benchmarks-heatsink-edition/[/URL]

The heatsink is definitely required.[/QUOTE]
When someone does the 100M jest benchmark with the pi 4 we'll be able to directly compare with the M4 ( [URL]https://www.mersenneforum.org/showpost.php?p=505965&postcount=229[/URL] ). From what I remember I was somewhat underwhelmed with how the RK3399 performed. Testing was done with the included massive aluminium heatsink and no airflow.

The pi 4 definitely needs a $2 copper heatsink at least, airflow might be optional but it'll need testing to confirm.

[QUOTE=M344587487;520247]The pi 4 definitely needs a $2 copper heatsink at least, airflow might be optional but it'll need testing to confirm.[/QUOTE]

My favourite for the Pi3B+ and 3A+ :
[URL="https://uk.farnell.com/fischer-elektronik/ick-pga-6-x-6-x-14/led-heatsink-pins-size-14x14x14mm/dp/1850037"]https://uk.farnell.com/fischer-elektronik/ick-pga-6-x-6-x-14/led-heatsink-pins-size-14x14x14mm/dp/1850037[/URL]
It's aluminium though, but taller than most heat sinks sold for the Pi so its thermal resistance is lower. Then I use thermally conductive glue to stick it on. The conductive two-sided tapes aren't that good. Handy, but crap. The conductivity might seem OK but the tape is much thicker than a layer of that glue. But still, even the 3A+ at stock clock needs moving air in addition to this heat sink, if running Mlucas. The whole card draws about 0.9 A then, no idea how much goes to the CPU. This current draw, by the way, is also much higher than most "full load" measurements on the web. I guess they don't use the NEON instruction set, then.

Now, the BCM2711 on the Pi 4 is about the same size, so I'll probably use the same cooling solution for it. I managed to order one from Denmark, so maybe next week... but getting it to run any flavour of 64-bit Linux is still likely to be a problem.

Okay I'm in a bit of a hurry now. So I only have incomplete results for now. Received one 1GB Pi4 yesterday. I got lucky, the maintainer of the Raspberry Pi 3-compatible 64-bit Gentoo image was very fast and managed to make a quick patch set that misses some features (like, ahem, accessing memory over 1 GB) but it's good enough to check the performance. And I have to say I'm disappointed. It seems to be about 2.2x faster than a Pi3B+ but let's hope that some of it is due to the kernel being a quick hack and some part of the memory subsystem is somehow being used wrong. I mean, the Jetson Nano with 4x Cortex-A57 running at a slower clock speed seems to be about 15% faster than this.

So I fetched [URL="https://github.com/sakaki-/gentoo-on-rpi3-64bit/releases/download/v1.4.2/genpi64.img.xz"]a fresh v1.4.2 image of Pi3 64-bit Gentoo[/URL] upon which the [URL="https://github.com/sakaki-/gentoo-on-rpi3-64bit/releases/download/v1.4.2/deploy_root_p4.tar.xz"]update package[/URL] is written. See instructions at [URL="https://www.raspberrypi.org/forums/viewtopic.php?p=1491136#p1492322"]https://www.raspberrypi.org/forums/viewtopic.php?p=1491136#p1492322[/URL] There were some other performance related surprises earlier in that thread (Merge sort benchmark as compiled by GCC was actually slower than on a Pi3; but with Clang it was faster). Same guesses there, probably something wrong with the memory access.

Running idle without a heat sink, core temperature 55C.

Running Mlucas self-tests without a heat sink will result in throttling in under two minutes. First from 1.5 to 1.0 GHz and after a longer period the hard thermal limit of 85C is reached and it will throttle down to 750 MHz. Maybe even lower, but I didn't feel like waiting that long.

Idle, 14x14x14 mm heat sink but no fan, core temperature 51C after about 10 minutes. So no huge difference there. But running Mlucas self-tests, the core temperature now only rises to about 73C and there is no throttling. Running as a bare board on the table though, so in a case, some extra airflow would be needed.

So next I placed a small undervolted fan (12V fan fed with 5V) next to the Pi and now it stays at around 52-55C while running self tests, even for a longer period. And the fan really only makes a slight breeze and is pretty much silent in an office environment. I might be able to hear it at home though.

mlucas.cfg, as far as I let it run, precompiled Mlucas v18.0 :
[CODE]18.0
2048 msec/iter = 56.03 ROE[avg,max] = [0.000306411, 0.375000000] radices = 128 32 16 16 0 0 0 0 0 0
2304 msec/iter = 61.13 ROE[avg,max] = [0.000249863, 0.343750000] radices = 288 16 16 16 0 0 0 0 0 0
2560 msec/iter = 67.98 ROE[avg,max] = [0.000236003, 0.312500000] radices = 160 16 16 32 0 0 0 0 0 0
2816 msec/iter = 77.15 ROE[avg,max] = [0.000259256, 0.343750000] radices = 176 16 16 32 0 0 0 0 0 0
3072 msec/iter = 85.38 ROE[avg,max] = [0.000267585, 0.375000000] radices = 192 16 16 32 0 0 0 0 0 0
3328 msec/iter = 93.26 ROE[avg,max] = [0.000280428, 0.406250000] radices = 208 16 16 32 0 0 0 0 0 0
3584 msec/iter = 99.89 ROE[avg,max] = [0.000254826, 0.343750000] radices = 224 16 16 32 0 0 0 0 0 0
3840 msec/iter = 111.78 ROE[avg,max] = [0.000247071, 0.312500000] radices = 240 16 16 32 0 0 0 0 0 0
[/CODE]

mlucas.cfg, another run with the "preview" binary posted a short while ago:
[CODE]18.0
2048 msec/iter = 55.83 ROE[avg,max] = [0.256171472, 0.312500000] radices = 128 16 16 32 0 0 0 0 0 0
2560 msec/iter = 67.83 ROE[avg,max] = [0.235211654, 0.312500000] radices = 160 16 16 32 0 0 0 0 0 0
2816 msec/iter = 76.70 ROE[avg,max] = [0.276159794, 0.343750000] radices = 176 16 16 32 0 0 0 0 0 0
3072 msec/iter = 85.49 ROE[avg,max] = [0.266928258, 0.406250000] radices = 192 16 16 32 0 0 0 0 0 0
3328 msec/iter = 91.66 ROE[avg,max] = [0.254067332, 0.343750000] radices = 208 16 16 32 0 0 0 0 0 0
3584 msec/iter = 100.41 ROE[avg,max] = [0.271899162, 0.375000000] radices = 224 16 16 32 0 0 0 0 0 0
3840 msec/iter = 107.90 ROE[avg,max] = [0.247359254, 0.312500000] radices = 240 16 16 32 0 0 0 0 0 0
[/CODE]
The Pi3B (and 3A) likes to use radix-352 at 2816K FFT size, but the Pi4 for some reason is slower with it (not by much, 78.82 ms/iter for radix-352 vs. 76.70 ms for radix-176). By the way, the same thing happens on the Cortex-A57 on the Jetson Nano. Also, only 2 of 5 radix sets for 2304K passed, so it was skipped, no entry in mlucas.cfg .

For monitoring, I used these Raspberry Pi - specific commands:
[CODE]vcgencmd measure_temp
vcgencmd measure_clock arm
vcgencmd get_throttled[/CODE]
Especially the last one is important. It shows even if throttling has occurred at all. The clock rate might seem normal at the time of polling, but if this value stays at 0x0, then no throttling has happened for any reason at any time.

Current consumption on the 5V supply:
0.69A idle, wired LAN in use, WLAN off
1.32A highest during Mlucas self-tests
The idle consumption seems really high, no wonder the board is running so hot...

I don't have one to play with, but I wonder what sort of difference in idle power it makes if HDMI is disabled. From what I just read, on the earlier pi3 it saves about 30mA. Maybe more savings available for rpi4 since it has two HDMI ports, or at least more powerful graphics processing?

Also maybe USB ports could be disabled too(assuming you just access via SSH) for some savings?

Is there a build of powertop or similar program which breaks down what devices power is going towards?

[QUOTE=hansl;520809]I don't have one to play with, but I wonder what sort of difference in idle power it makes if HDMI is disabled. From what I just read, on the earlier pi3 it saves about 30mA. Maybe more savings available for rpi4 since it has two HDMI ports, or at least more powerful graphics processing?[/QUOTE]
I can test this, but I left the thing on my desk at work... Monday at the earliest, then.

Also, I don't know what power saving tricks the official Raspbian distribution does by default, maybe it runs cooler? But yeah, Monday.

[QUOTE=hansl;520809]Also maybe USB ports could be disabled too(assuming you just access via SSH) for some savings?[/QUOTE]
Hmm... will have to look into it. Anyway, there is apparently a firmware update for the USB chip now available, that can reduce the power consumption somewhat - by about 300 mW.
[URL="https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=243500&p=1490467&hilit=vl805#p1490467"]https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=243500&p=1490467&hilit=vl805#p1490467[/URL]
But apparently this needs to be done under 32-bit Linux (for example plain old Raspbian), trying to run the upgrade utility just gives an error message for me.

[QUOTE=hansl;520809]Is there a build of powertop or similar program which breaks down what devices power is going towards?[/QUOTE]
Not to my knowledge, no. I was under the impression that it can only tell where the CPU power consumption is going, not the peripherals.

Nomead, thanks for the data. Re. idle-power, on the Odroid-C2 there is a removable jumper whose pulling-off saves some power, not sure if anything similar on your board.

[QUOTE=nomead;520797]The Pi3B (and 3A) likes to use radix-352 at 2816K FFT size, but the Pi4 for some reason is slower with it (not by much, 78.82 ms/iter for radix-352 vs. 76.70 ms for radix-176). By the way, the same thing happens on the Cortex-A57 on the Jetson Nano. Also, only 2 of 5 radix sets for 2304K passed, so it was skipped, no entry in mlucas.cfg .[/QUOTE]

352 is mainly geared for 5632K where it makes a significant difference on most of my ARM devices, whether it also helps at 2816K is hit or miss.

Do you still have the screen log from your self-tests? I'd like to look at the 2304K self-tests outputs to see why only 2 of the various FFT-radix combos at that length passed. Thanks.

[QUOTE=ewmayer;520817]Nomead, thanks for the data. Re. idle-power, on the Odroid-C2 there is a removable jumper whose pulling-off saves some power, not sure if anything similar on your board.

352 is mainly geared for 5632K where it makes a significant difference on most of my ARM devices, whether it also helps at 2816K is hit or miss.

Do you still have the screen log from your self-tests? I'd like to look at the 2304K self-tests outputs to see why only 2 of the various FFT-radix combos at that length passed. Thanks.[/QUOTE]

No jumpers on the Pi4... if something can be disabled, it needs to be done via software or firmware.

352 happens to help on Pi3 / BCM2837 so there it's a definite hit.

I'll attach the screenlog to this message.

[QUOTE=nomead;520819]352 happens to help on Pi3 / BCM2837 so there it's a definite hit.

I'll attach the screenlog to this message.[/QUOTE]

Thanks - looking at the 2304K self-tests in the log, 3 of the 5 runs suffer ROE >= 0.4375, and since that means fewer than half the tests passed, the code treats that FFT length as having failed the self-tests. Based on the good data points, here is a manually created cfg-file line for that length:
[code] 2304 msec/iter = 61.16 ROE[avg,max] = [0.249911153, 0.343750000] radices = 288 16 16 16 0 0 0 0 0 0[/code]

I quick-checked that length on my Odroid C2 just now and 3 of 5 tests passed so it wrote a cfgfile entry for me ... that difference had me puzzled - same code, same CPU hardware - until I recalled that the random residue shift can lead to such otherwise-identical-everything differences. If you try rerunning just that one FFT length in self-test mode via
[i]
./Mlucas -fftlen 2304 -iters 100 -cpu 0:3
[/i]
you should see different residue shifts from your Mlucas -s m run, and perhaps will get the one more good data point that is needed for the cfg-file to get written. The self-test exponents are already set at the extreme high end of the range computed for each FFT length, so sometimes a little manual hackery of this kind is needed to get a complete set of cfg-file entries.

[QUOTE=ewmayer;520822]T
[i]
./Mlucas -fftlen 2304 -iters 100 -cpu 0:3
[/i]
you should see different residue shifts from your Mlucas -s m run, and perhaps will get the one more good data point that is needed for the cfg-file to get written. The self-test exponents are already set at the extreme high end of the range computed for each FFT length, so sometimes a little manual hackery of this kind is needed to get a complete set of cfg-file entries.[/QUOTE]

Yup - and it gives the same [C]288 16 16 16[/C] radix set on three consecutive tries, with 3 of 5 sets passed.

Oh, and here are the rest of the self-test runs.
v18.0:
[CODE] 4096 msec/iter = 116.38 ROE[avg,max] = [0.000227303, 0.312500000] radices = 256 16 16 32 0 0 0 0 0 0
4608 msec/iter = 129.56 ROE[avg,max] = [0.000248429, 0.312500000] radices = 288 16 16 32 0 0 0 0 0 0
5120 msec/iter = 181.85 ROE[avg,max] = [0.000234485, 0.281250000] radices = 160 32 32 16 0 0 0 0 0 0
5632 msec/iter = 204.47 ROE[avg,max] = [0.000257845, 0.343750000] radices = 176 32 32 16 0 0 0 0 0 0
6144 msec/iter = 225.43 ROE[avg,max] = [0.000247003, 0.312500000] radices = 192 32 32 16 0 0 0 0 0 0
6656 msec/iter = 242.89 ROE[avg,max] = [0.000266479, 0.375000000] radices = 208 32 32 16 0 0 0 0 0 0
7168 msec/iter = 262.44 ROE[avg,max] = [0.000226100, 0.281250000] radices = 224 32 32 16 0 0 0 0 0 0
7680 msec/iter = 290.09 ROE[avg,max] = [0.000236377, 0.312500000] radices = 240 32 32 16 0 0 0 0 0 0[/CODE]
preview version:
[CODE] 4096 msec/iter = 124.18 ROE[avg,max] = [0.227270067, 0.281250000] radices = 256 16 16 32 0 0 0 0 0 0
4608 msec/iter = 130.03 ROE[avg,max] = [0.249110271, 0.312500000] radices = 288 16 16 32 0 0 0 0 0 0
5120 msec/iter = 154.51 ROE[avg,max] = [0.296955541, 0.375000000] radices = 320 16 16 32 0 0 0 0 0 0
5632 msec/iter = 166.74 ROE[avg,max] = [0.223459145, 0.281250000] radices = 352 16 16 32 0 0 0 0 0 0
6144 msec/iter = 226.16 ROE[avg,max] = [0.246091736, 0.343750000] radices = 192 32 32 16 0 0 0 0 0 0
6656 msec/iter = 243.35 ROE[avg,max] = [0.230394501, 0.312500000] radices = 208 32 32 16 0 0 0 0 0 0
7168 msec/iter = 265.73 ROE[avg,max] = [0.236601462, 0.312500000] radices = 224 32 32 16 0 0 0 0 0 0
7680 msec/iter = 283.72 ROE[avg,max] = [0.235477282, 0.343750000] radices = 240 32 32 16 0 0 0 0 0 0[/CODE]

Indeed, there's a huge difference in 5120K and 5632K FFT sizes' speeds, because of those radix sets with 320 and 352.

[QUOTE=nomead;520830]Yup - and it gives the same [C]288 16 16 16[/C] radix set on three consecutive tries, with 3 of 5 sets passed.[/quote]
If you rerun the same single-FFT-length way, you will get the same initial radix shift, and thus run-to-run data will be identical. You can, however, manually fiddle the initial shift via the -shift flag, if you like.
[timings snipped]
[quote]Indeed, there's a huge difference in 5120K and 5632K FFT sizes' speeds, because of those radix sets with 320 and 352.[/QUOTE]

Hmm ... a healthy speedup at 5632K I can believe because radix-352 is new in v19, but radix-320 was already there in v18. Maybe rerun the 5120K self-test once more using each of the v18 and v19 builds?

[QUOTE=ewmayer;520839]Hmm ... a healthy speedup at 5632K I can believe because radix-352 is new in v19, but radix-320 was already there in v18. Maybe rerun the 5120K self-test once more using each of the v18 and v19 builds?[/QUOTE]

Apparently v18 happened to give excessive roundoff on both [C]320 16 16 32[/C] and [C]320 32 16 16[/C] so that's why it wasn't using it. So again, yes, hand-massaging the test would help here.

[QUOTE=nomead;520861]Apparently v18 happened to give excessive roundoff on both [C]320 16 16 32[/C] and [C]320 32 16 16[/C] so that's why it wasn't using it. So again, yes, hand-massaging the test would help here.[/QUOTE]

Sounds like I need to back off a bit on the self-test exponents in v19, to make sure faster but slightly more roundoff-prone FFT radix combos don't go by the wayside like that.

Okay, power saving measurements:

[C]force_turbo=1[/C] in the configuration file for both Gentoo and Debian to keep it at 1.5 GHz even when idle.

Baseline (Gentoo 64-bit, nothing disabled yet)
0.69A idle -> 1.29A Mlucas running a doublecheck at 2816K FFT

Raspbian (because the firmware updater only runs on 32-bit Linux) :
0.65A idle before USB update
0.59A idle after USB update
So yes, Raspbian does something different and saves a bit more power at idle.

Gentoo after USB firmware update, HDMI still on:
0.61A idle -> 1.21A Mlucas
Turning HDMI off with [C]tvservice -o[/C] saves a further 0.02 Amps apparently.

powertop is worth a shot if it works, on my laptop it can disable controllers for USB, ethernet, SATA and other PCI devices. The older pi's USB/ethernet controller was a power hog if I remember rightly.

[QUOTE=M344587487;520990]powertop is worth a shot if it works, on my laptop it can disable controllers for USB, ethernet, SATA and other PCI devices.[/QUOTE]
I'm afraid powertop is Intel-only (not even AMD as far as I understand).

[QUOTE=ldesnogu;520991]I'm afraid powertop is Intel-only (not even AMD as far as I understand).[/QUOTE]
It started as an intel thing but that's the beauty of open source:
[quote][B]PowerTOP[/B] is a software [URL="https://en.wikipedia.org/wiki/Utility_software"]utility[/URL] designed to measure, explain and minimise a computer's [URL="https://en.wikipedia.org/wiki/Electric_power"]electrical power[/URL] consumption. It was released by [URL="https://en.wikipedia.org/wiki/Intel"]Intel[/URL] in 2007 under the [URL="https://en.wikipedia.org/wiki/GNU_General_Public_License"]GPLv[/URL]2 license. It works for [URL="https://en.wikipedia.org/wiki/Intel"]Intel[/URL], [URL="https://en.wikipedia.org/wiki/Advanced_Micro_Devices"]AMD[/URL], [URL="https://en.wikipedia.org/wiki/ARM_architecture"]ARM[/URL] and [URL="https://en.wikipedia.org/wiki/UltraSPARC"]UltraSPARC[/URL] [URL="https://en.wikipedia.org/wiki/Processors"]processors[/URL][/quote]

Okay I assumed wrong earlier, that it's x86 and CPU only... Well, it happens to be available on that Gentoo 64-bit image, but unfortunately none of the Tunables make any difference to the current consumption.

If you don't mind feeling around in the dark you could try a modified version of a suggestion from here: [URL]https://stackoverflow.com/questions/23487728/ethernet-disabling-in-raspberry-pi[/URL]

Namely:
[quote]Disabling an ethernet interface actually doesn't power down the hardware. You have to disable the chip via bus power. But I'm afraid, that the same chip which contains the ethernet driver also contains the USB driver.
See this question on [URL="https://raspberrypi.stackexchange.com/questions/8498/disable-lan9512"]raspberrypi.stackexchange.com[/URL]. There is different chip (LAN9512) discussed, but disabling it should be same. I just wonder why you have different chip, maybe different Raspberry Pi's revision?
So to power down the chip, just write 0 to the file /sys/devices/platform/bcm2708_usb/buspower:[/quote]If this even applies the pi4 will have different chips (and I assume they no longer have a unified USB/ethernet chip), so list the contents of /sys/devices/platform, figure out which are for ethernet, USB and whatever else is unnecessary and see if they can be disabled.

[QUOTE=M344587487;520997]
If this even applies the pi4 will have different chips (and I assume they no longer have a unified USB/ethernet chip), so list the contents of /sys/devices/platform, figure out which are for ethernet, USB and whatever else is unnecessary and see if they can be disabled.[/QUOTE]

Yeah the Pi4 has Ethernet on the SoC now, and USB (and only USB) is handled by the external VL805 chip, that just got the firmware update. But anyway, poking around, I only found [C]/sys/devices/platform/soc/fe980000.usb/buspower[/C] that I could write to, and writing a zero to it didn't have any effect on current consumption. So probably that isn't the VL805 but something else, then. There's supposed to be USB 2.0 functionality on the SoC so maybe that's it. Some other power controls only suspend 5V power to the USB ports if they're not in use. But again, maybe some things are not yet accessible in the kernel version that the Gentoo build is using. Let's see on the Raspbian side.

There's certainly extra stuff visible on Raspbian, under [C]/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0[/C] but I think none of that applies either for disabling the whole module...