There’s a strange issue here in raspberry Github:
1 Like
Seems like it was resolved by manipulating the sdram timing? Also, be careful when overclocking.
Looks like the discovery may actually lead to significant performance boost of the Pi5 (slightly relevant for Pi4 too). People measured up to 164% boost in some tasks (compression), but 46% on average for multicore tasks. However, it concerns memory access, so that I wouldn’t expect any significant boost for pure computations within sound engines.
1 Like
Hi @wanthalf 
It looks like the by now experimental hack is as follows:
sudo rpi-update
then edit your bootloader config:
sudo rpi-eeprom-config -e
adding this line for pi5:
SDRAM_BANKLOW=1
or this line for pi4:
SDRAM_BANKLOW=3
and reboot.
You should find “/proc/cmdline” contains the line “numa=fake=”.
It seems that Micron, the SDRAM manufacturer, has been contacted by the Raspberry Foundation, and confirmed that this setting should solve the detected speed difference between 4 GB and 8 Gb Pis.
They warn that this is still experimental and under testing. As soon as they have ascertained that it is safe to drive the SDRAM memory in this way, they will push it as an official Eeprom update for Pi 4 and Pi 5.
1 Like
Ahm. Overclocking brings danger with this.
I’ve actually shredded a Pi 5 Wi-Fi module with onboard antenna and a second one with an external antenna mod, just by overclocking 10%. (intention was to move Pi 5 away from 2.4GHz to reduce interference with BT.
Result: Timings too fast, CYP burnt out. Even with old EEPROM, everything reset and older Bookworm, there is no response on SDIO.
So nice, I got to vomit twice… 
@jofemodo
We should definitely disable overclocking for Pi 5 and not present the option in Webconf, as it is too inviting and the outcome is definitive.
Hi @fussl,
Sorry for your double and expensive mishap with overclocking Pi5.
Many of us happen to have mistakenly gone In good faith for the 8 Gb version, in my case with the prospect of loading large soundfonts while still letting appropriate RAM space, for CPU computations and related OS buffer.
My current expectation is to run the Pi5s at nominal speed, once and if the SDRAM paging update is officially pushed by the Raspberry Foundation.
I am detecting too an appreciable degrading of the Pi5 performance with overclocking (just medium), under intense computational load, like with OsTIrus, Osirus or Surge.
Well, thank you, but I must say, Pi 5 actually work better without the crappy builtin Wi-Fi. Yes, external Wi-Fi and bluetooth consumes one of the USB ports, but that is definitely worth the deal. 8 Euros at the local chinese market for a REAL Wi-Fi 5 with BT 5.3 (That grey little USB brick with the lime print marks), and everything works like a charm. It is more the USB port I’m missing.
To get rid of the builtin sh**e-Fi, just add
dtoverlay=disable-wifi-pi5
dtoverlay=disable-bt-pi5
to the config.txt, then install proper Wi-Fi and bluetooth, that collaborate and just work.
3 Likes
Yes, I have found that Bluetooth is pretty much unusable but WiFi hasn’t been so bad. I use a Bluetooth USB dongle but may get something like what you describe to provide both (if I find I need more wifi range but I seldom use wifi).
I’m finding a zynth connected via wifi frequently drops ssh connections. Ok on wired and webconf seems.
Might be my crazed environment but it can be irritating.
Hi @wyleu
I have been detecting the same behaviour for a long time, but initially put the blame on the shoulders of my Mac LAN interface or SSH server app. Nevertheless, it all goes just the same with my windows laptop.
I tend to blame my wifi rig but I’ve never had problems with direct Ethernet connections which is what I tend to use.
I am experiencing the same wifi issues… Webconf seems OK, but ssh terminal and sftp sometimes takes long to respond.
Cheers,
Maarten
Yes, and I also noticed that Ethernet and WiFi tend to conflict somehow. Still, I don’t have a physical Internet router close to the Zynth, so I need both WiFi for reaching the outer world and LAN for accessing the Z from an external computer.
Well, I might exclusively resort to WIFi for both functions, but using webconf or SSH/FSTP through radio-transmitted connection does not feel a particularly reliable solution, with a Pi enclosed in a metal case (unless I switch to an external WiFi USB dongle, or else I am missing something… 
)
I’m going to be picking up a Pi 5 in a couple days, what’s the general opinion here on 8gb vs 4gb now?
4GB can easily be filled up if you load many instruments or huge soundfonts.
I have two 8GB (one testing, one production) and often read less than 4GB free.
Edit: Speed is enough for most things. Loading two of the DSP emulations works safely, plus some other effects and tings.
1 Like
I also experience unstable WiFi connections on rpi5, even wired drops sometimes. It takes minute or two to get IP pringable after restart. I blamed my adapter for network over power cable for slow wired connections as well as my study is not that close to WiFi router.
Yesterday it took me almost hour to download compressed rpi kernel source that is around 220mb (done by rpi-source script). On my Mac that seats near to the same zynthian box it took few minutes over WiFi to download the same.
I’ve tried Kali Linux on the Pi 5, because this seems to be specialized in Wi-Fi and network business. Interesting is the fact, that Wi-Fi and BT and even Ethernet work flawlessly with this, while it is shaggy with RPi OS and Zynthian.
It couldn’t heal the broken Wi-Fi modules on the other Pi 5, though.
Kali does not overclock or underclock, but still the onboard frequencies seem to interfere less with BT. I could use headphones two rooms away from the Pi 5, streaming youtube via Wi-Fi to the screen and audio with full quality APTX HD, on my Zynthian hardware (acrylic enclosure and passive cooler, no metal box). Running with RPi OS it even crackles when turning the head. Same is with BT-MIDI, this works with imperceptible latency in Kali, while in Zynthian there seem to be some two-digit milliseconds of delay.
I think it is a driver or firmware problem. Whatever the experts at Kali do with the Wi-Fi module, they do it better than the creators of RPi are able to.
Do we have a WiFi and Bluetooth geographical region problem? I’ve noticed that my usb keyboard does not seem to have the correct US 104 key mapping and have not figured out how to fix it.
Yes, indeed. sudo raspi-config nonint do_wifi_country __,with __ being the country code, has to be done at least once, as well as iw reg get after a power cycle, to verify the setting. In pre-Vangelis, this region setting had been annihilated and set to 98 by any save in Webconf. For recent Vangelis, this seems to not happen any more and the settings seem to be persistent.
Documentation is lacking here.
In Kali, I’ve set the region according my local requirements, in order to not interfere with weather radar and a local Carrier Mesh Network, which still shows up in passive scanning, but still I get the far better wireless performance with Kali, so I would rather exclude reg domain settings from this issue. Scanning the spectrum, I see the same noise floor, the same interference and no larger signals, it is the receiving side performing better, whatever they do. In isolated thest with close antenna probe, I see the transmission less distorted, but not larger in transmitted power, as if some PA has been matched better, so I really think it is a firmware thing with better parameter settings.
Maybe even the software flow produces lesser spikes on power rails from core power consumption and thus lower distortion in transmission due to skimpy hardware. Pi make a mystery of the schematics, so that’s probably why.
Looking at the published part with USB-PD gives a glimpse on what is to be expected.
I’ve soldered low ESR caps and some polycaps and cermaics to the exposed power rails on the GPIO, which does not change anything anyhow, changed power supply for the entire periphery directly to source instead of using the GPIO power pins but no avail.
I have bettert hings to do than trying to polish the Pi.
As most of the hardware management is done by kernel drivers, the linux distribution should not be the real difference, but the kernel version and the specific drivers used for managing WIFI and BT.
BTW, does kali use the network manager interface “nmcli”?
My 2 cents