Raspberry Pis - anyone else?

[Roadster280]

I just had a look at the Box86 Github page, and it states that you need a 32 bit build system. You should be able to build 32 bit software on a 64 bit system, but you need the right libraries. If you stick to a 32 bit distro then you don't have that issue. I mentioned Ubuntu runs on ARM, but that is 64 bit. It's a factor to keep in mind.

Wine is mainly used for running Windows games on Linux or MacOS. Development tend to focus on fixing bug reports from people playing games. I'm not sure what the Lightbox errors you are getting are, but it may be hit and miss to find a version of Wine that works around them.

I also just had a look at the Lightburn web site. They have a Linux version of Lightburn. Is there any reason why you don't run that directly in an x86 emulator instead and forget about Wine?

I think that’s back to QEMU, no? I’d be happy with that as a solution. Any suggestions on the x86 emulator beyond QEMU?

 

[terminal]

I think that’s back to QEMU, no? I’d be happy with that as a solution. Any suggestions on the x86 emulator beyond QEMU?

I thought you had the x86 emulation sorted and I was just suggesting skipping Wine and running a Linux binary instead. I have a couple of Raspberry Pi systems, but I've never had a reason to want to emulate x86 on them.

Google turns up the following. If it works, let us know.

 

[Roadster280]

I thought you had the x86 emulation sorted and I was just suggesting skipping Wine and running a Linux binary instead. I have a couple of Raspberry Pi systems, but I've never had a reason to want to emulate x86 on them.

Google turns up the following. If it works, let us know.

Sadly no, Box86 runs 32bit apps only, not 64-bit. It’s another avenue to try. I’m sure I can get It done, it‘s now an effort/return on effort thing. I’ll replace the Mac that likes beer IDC, so it‘s more academic interest at present. Which is fcuking bizarre, since I’ll replace it with an ARM Mac

 

[tgo]

Thx - i've seen most of these before & had been musing running pure or ubuntu. Just thought some of you chaps who are deeply into these areas would have a "highly recommended" - quite happy to load the os onto the phone.
If i brick it - meh wtf !!

Might be worth taking a look on here

XDA Portal & Forums

www.xda-developers.com

and then onto here

XDA Forums

Android Forum for Mobile Phones, Tablets, Hardware & App Development

forum.xda-developers.com

There's nothing intrinsically #wrong# with Android, but if you're concerned about GMS get something without it in

 

[Roadster280]

A couple of ups and downs with RPis recently.

Up:

I have a 2006 Jag that while it has a navigation system, it is a very early one, complete bag of shite in terms of modern ones. So I’ve built a system around a Pi 4 that will wirelessly connect to my iPhone and give me Apple CarPlay on a 5.5” touchscreen to replace the OEM Nav screen. But I only had an 8GB RPi 4, and that’s a bit of overkill. Raspberry Pi’s in general are like rocking horse shit, the 8GB in particular. So I was pleased to find a 2GB system for $45, and will use that - releasing that 8Gb system.

Down:

I’d been using another 8GB Pi to control my Ham radio, but I’ve come to the conclusion that it just does not have the balls to handle the applications. There are some heavy duty esoteric maths for some of the digital modes, and it was being slow. I replaced it with an M1 Mac and the difference was shocking, despite them both being arm64 architecture with 8GB. I’ll confess to being really disappointed in the Pi’s performance. With 64-bit Bullseye OS and running it off an SSD, I expected better.

Ham radio thread post: https://www.arrse.co.uk/community/threads/ham-radio.302300/post-11263830

Up:

Pi’s are rocking horse shit at the moment. But I found a supplier with Pi400s for $78. So two of those coming this week. Coincidentally, eBay is running about $100 for Pi 3Bs, which I have two of. So they’re on the Bay this week, and I should be about $40 up, upgrading from 3Bs to 400s. It’s barking mad. The 400 is a much more capable system and they go for less. So I’ll have 2x 400s, and 2x 4B 8GB and a 4B 2GB for the nav system. Also a Zero W, but not used that so far.

I think there’ll be a place for one of the Pi 400s with breadboard for electronics, the other as a test bed. The 8GB 4s can go in the server rack as erm, file servers, Pi-hole etc, and the Zero I may as well sell. The 2GB 4 will go in the Jag in the Spring.

Bit disappointed if I’m honest to not be using them to control the radio, but there’s still a place for them.

 

[terminal]

(...) I’d been using another 8GB Pi to control my Ham radio, but I’ve come to the conclusion that it just does not have the balls to handle the applications. There are some heavy duty esoteric maths for some of the digital modes, and it was being slow. I replaced it with an M1 Mac and the difference was shocking, despite them both being arm64 architecture with 8GB. I’ll confess to being really disappointed in the Pi’s performance. With 64-bit Bullseye OS and running it off an SSD, I expected better. (...)

I can't speak to your particular application, but there are several factors which can come into play aside from clock speed.

I'll just address two in this post. The simple one is does your Pi4 have a CPU fan? If not, then the speed will throttle down fairly soon to keep heat build up down.

The more complex factor has to do with how the math libraries are written and compiled. If you have an application with a lot of heavy duty math then there's a good chance it is using SIMD (Single Instruction Multiple Data) operations to do calculations in parallel. Depending on the data types used then SIMD can make it anywhere from a bit faster to ten times faster, or more. This is particularly useful when doing repetitive math operations.

I started explaining how complicated and ugly it can get to use SIMD features but the explanation started getting complicated or ugly so I'll just stick with saying that it's a CPU architecture and model specific feature. You need to have the hardware to test it on before you can use it, otherwise you need to default to a generic non-SIMD algorithm. If you are writing the software in C then it will be full of #ifdefs and either assembly language or built-ins (sort of half way between C and assembly).

So the hardware it was enabled for will tend to be limited to the hardware that the person responsible for it has. I have a Pi3 and Pi4 but I don't have an Apple Mac with Arm, so I have written software will use SIMD on those Pi models but not on an Apple Mac. It is quite possible that in this case my software could be faster on a Pi4 than on a Mac. The reason that I bought the Pis that I have was to do this sort of software testing and optimization on ARM.

You may wish to enquire with the author of the software or on any associated forums if the software in question has been optimized for and tested and benchmarked on a Pi4. I can't say this is indeed related to your problem, but it's an area that I would look into if I were asked to look at a performance problem.


Aside from the above items, I would expect the Apple ARM based PC to be on average faster than a Raspberry Pi (although this may not account for the difference you are seeing). The Apple ARM PC is an order of magnitude more expensive and so will have far bigger CPU caches and faster RAM, both of which will make a difference in CPU bound applications. My own benchmarks on a mix of mathematics intensive applications puts a Pi4 at roughly 50 to 60 percent of the speed of my x86 PC. This is very impressive considering the difference in cost and size.

 

[Roadster280]

I can't speak to your particular application, but there are several factors which can come into play aside from clock speed.

I'll just address two in this post. The simple one is does your Pi4 have a CPU fan? If not, then the speed will throttle down fairly soon to keep heat build up down.

The more complex factor has to do with how the math libraries are written and compiled. If you have an application with a lot of heavy duty math then there's a good chance it is using SIMD (Single Instruction Multiple Data) operations to do calculations in parallel. Depending on the data types used then SIMD can make it anywhere from a bit faster to ten times faster, or more. This is particularly useful when doing repetitive math operations.

I started explaining how complicated and ugly it can get to use SIMD features but the explanation started getting complicated or ugly so I'll just stick with saying that it's a CPU architecture and model specific feature. You need to have the hardware to test it on before you can use it, otherwise you need to default to a generic non-SIMD algorithm. If you are writing the software in C then it will be full of #ifdefs and either assembly language or built-ins (sort of half way between C and assembly).

So the hardware it was enabled for will tend to be limited to the hardware that the person responsible for it has. I have a Pi3 and Pi4 but I don't have an Apple Mac with Arm, so I have written software will use SIMD on those Pi models but not on an Apple Mac. It is quite possible that in this case my software could be faster on a Pi4 than on a Mac. The reason that I bought the Pis that I have was to do this sort of software testing and optimization on ARM.

You may wish to enquire with the author of the software or on any associated forums if the software in question has been optimized for and tested and benchmarked on a Pi4. I can't say this is indeed related to your problem, but it's an area that I would look into if I were asked to look at a performance problem.


Aside from the above items, I would expect the Apple ARM based PC to be on average faster than a Raspberry Pi (although this may not account for the difference you are seeing). The Apple ARM PC is an order of magnitude more expensive and so will have far bigger CPU caches and faster RAM, both of which will make a difference in CPU bound applications. My own benchmarks on a mix of mathematics intensive applications puts a Pi4 at roughly 50 to 60 percent of the speed of my x86 PC. This is very impressive considering the difference in cost and size.

Don’t get me wrong - I agree that the Pi is a very impressive thing - it’s just that there are much more performant solutions to running this app, so it seems. I don’t have a fan on it, but do have a hefty heatsink. As it goes, I found a box of small fans the other day that I forgot I had, so I’ll try that. Wsjtx does use SIMD, but not sure if there’s an optimization for the Broadcom CPU. I’ll have a dig later. Unfortunately, it’ll probably be a while before any Pi-specific stuff is (re-)done in the software. One of the main developers, who was a Pi fan passed away in December.

I suspect that it’s NOT optimized for the Pi though. I’ve built a virtual machine using Raspberry Pi OS on the Mac. I can only give it 4GB RAM, but it absolutely flies. Boots from cold to desktop in about 12 seconds. The annoyingly slow operations on the Pi like dragging large windows in higher resolutions are no longer drags. However, I would say that wsjt-x on the VM is even worse than the actual Pi, so given that it’s the same OS and CPU architecture, it seems there are probably not optimizations in play.

I’ve played with this before, but didn’t have a radio at the time - VMWare’s hypervisor - ESXi is available for the Pi/arm64. I remember the same thing as I see on the Mac - a VM of Raspberry Pi OS runs faster than the same thing running natively. Perhaps in native mode, the CPU is bogged down with interrupts etc servicing hardware that I’m not interested in. So ESXi, being a very bare-bones OS perhaps isn’t dicking about with GPIO, I2C etc, nor Mouse, displays etc. The Raspberry Pi OS in that environment could perhaps be a bit more speedy. Again, I’ll have a play later.

More experimentation required - which is sort of the point of the Raspberry Pi, so all is good.

 

[Morticiaskeeper]

I bought a pi zero 2 last week to use as a node-red dashboard server and a mqtt broker. Im finding that Esp8266 in the form of a Wemos D1 mini is more useful for a lot of jobs. Currently reading temperature & humidity while switching relays via a D1 & mqtt.

Still using Pi 4 4gb as 3d print server, Pi 4 8gb as desktop PC, Pi 3 ADSB receiver & NAS, Pi 3 security system and Pi zero ad blocker

 

[Drazyl]

Down:

I’d been using another 8GB Pi to control my Ham radio, but I’ve come to the conclusion that it just does not have the balls to handle the applications. There are some heavy duty esoteric maths for some of the digital modes, and it was being slow. I replaced it with an M1 Mac and the difference was shocking, despite them both being arm64 architecture with 8GB. I’ll confess to being really disappointed in the Pi’s performance. With 64-bit Bullseye OS and running it off an SSD, I expected better.

Considering the M1 chip is about 8-10x more powerful, that's not surprising. It's also somewhat more expensive.

 

[Roadster280]

Considering the M1 chip is about 8-10x more powerful, that's not surprising. It's also somewhat more expensive.

Perhaps I was naive, but I did not expect 8-10x (which is an order of magnitude) difference. I expected maybe 2-3x the performance.

My gut says the physical RPi is bottlenecked, whereas the virtualized RPi removes some of that hardware drag. I’ve been trying to find an hour to play with it, but keep getting sidetracked

 

[terminal]

Don’t get me wrong - I agree that the Pi is a very impressive thing - it’s just that there are much more performant solutions to running this app, so it seems. I don’t have a fan on it, but do have a hefty heatsink. As it goes, I found a box of small fans the other day that I forgot I had, so I’ll try that. Wsjtx does use SIMD, but not sure if there’s an optimization for the Broadcom CPU. I’ll have a dig later. Unfortunately, it’ll probably be a while before any Pi-specific stuff is (re-)done in the software. One of the main developers, who was a Pi fan passed away in December.

I suspect that it’s NOT optimized for the Pi though. I’ve built a virtual machine using Raspberry Pi OS on the Mac. I can only give it 4GB RAM, but it absolutely flies. Boots from cold to desktop in about 12 seconds. The annoyingly slow operations on the Pi like dragging large windows in higher resolutions are no longer drags. However, I would say that wsjt-x on the VM is even worse than the actual Pi, so given that it’s the same OS and CPU architecture, it seems there are probably not optimizations in play.

I’ve played with this before, but didn’t have a radio at the time - VMWare’s hypervisor - ESXi is available for the Pi/arm64. I remember the same thing as I see on the Mac - a VM of Raspberry Pi OS runs faster than the same thing running natively. Perhaps in native mode, the CPU is bogged down with interrupts etc servicing hardware that I’m not interested in. So ESXi, being a very bare-bones OS perhaps isn’t dicking about with GPIO, I2C etc, nor Mouse, displays etc. The Raspberry Pi OS in that environment could perhaps be a bit more speedy. Again, I’ll have a play later.

More experimentation required - which is sort of the point of the Raspberry Pi, so all is good.

I had a brief look at the WSJT-X source code and realized that taking a serious look at it was way more work than I wanted to even consider doing, so I put that aside as there's no obvious simple thing for you to do.

However, my own experience (using a different build system) is that I needed to specify the actual CPU type as a compiler flag or else it defaulted to an older model. The Pi3 and Pi4 are different CPU models (a53 versus a72 if I recall correctly).

As for slow graphics on the Pi, that's down to the GPU rather than the CPU. The GPU is of course a very low end inexpensive model. The graphics performance won't correlate with the CPU performance.

I also wouldn't draw too many conclusions from boot time. The Pi is booting from a micro-SD card, which is going to have much slower I/O than an SSD, and that will likely be the bottleneck there. Boot speed may to some extent be dependent on the brand of micro-SD card you are using.

I don't know what the actual bottlenecks are in the application, but if it's in the math libraries then the answer may be faster math libraries. I noticed what I believe was FFTW (a Fast Fourier Transform library), so I assume there are a variety of third party libraries in there. I'm not going to speculate any further however, and again I didn't see anything in there which looks like a quick and simple fix.

However, give the CPU fan a try, and keep in touch with what other people are doing with it. I noticed several Youtube videos from people where apparently running WSJT-x on Raspberry Pis, so someone may come up with a solution for you eventually.

Good luck.

 

[Roadster280]

I had a brief look at the WSJT-X source code and realized that taking a serious look at it was way more work than I wanted to even consider doing, so I put that aside as there's no obvious simple thing for you to do.

However, my own experience (using a different build system) is that I needed to specify the actual CPU type as a compiler flag or else it defaulted to an older model. The Pi3 and Pi4 are different CPU models (a53 versus a72 if I recall correctly).

As for slow graphics on the Pi, that's down to the GPU rather than the CPU. The GPU is of course a very low end inexpensive model. The graphics performance won't correlate with the CPU performance.

I also wouldn't draw too many conclusions from boot time. The Pi is booting from a micro-SD card, which is going to have much slower I/O than an SSD, and that will likely be the bottleneck there. Boot speed may to some extent be dependent on the brand of micro-SD card you are using.

I don't know what the actual bottlenecks are in the application, but if it's in the math libraries then the answer may be faster math libraries. I noticed what I believe was FFTW (a Fast Fourier Transform library), so I assume there are a variety of third party libraries in there. I'm not going to speculate any further however, and again I didn't see anything in there which looks like a quick and simple fix.

However, give the CPU fan a try, and keep in touch with what other people are doing with it. I noticed several Youtube videos from people where apparently running WSJT-x on Raspberry Pis, so someone may come up with a solution for you eventually.

Good luck.

Thanks for taking the time to have a look at it!

I’m not actually using an SD card at present, both my Pi4s have USB3-connected SSDs, so that’s unlikely to get any better. The Pi400s should turn up tomorrow. They have no fans, but apparently the keyboard backing is designed as a heatsink.

The Pi400s have a better CPU stepping and are clocked at 1.8G vs 1.5G. I’ll put one of the SSDs on it, and start from scratch. That’s either going to yield results, or not. Can’t do much better than that in terms of system spec at present.

I’ve been playing with Pi virtualisation this evening on both the Pi itself and the M1. I think that’s probably a dead end, unless I can figure out if there’s any optimisation to be had with the Pi image on the M1, but the Pi itself isn’t likely to yield dividends, especially as I would have to use VNC to get a display out of it (or use ESXi’s monitor tool). With no VMs running, it was using 35ish% CPU. Not really a surprise, but it was worth investigating. It’s frustrating that both ESXi on the Pi and Fusion on the Mac are both in pre-production state, and don’t support importing each others’ VMs. In x86 world, you could do that all day long.

Away from virtualisation, it’s not that wsjtx doesn‘t work at all on the Pi, it absolutely does. In operation, there are 15-second blocks of either TX or RX, and the software receives and decodes as much as it can in those 15 second blocks. Obviously the faster it can process the signals, the more signals it can decode - ie the more stations you see. But at 15 seconds, it’s moving on to either the next RX block, or initiating a TX block. Receiving FT8 signals from all over the world, it has its work cut out for sure, and while I don’t understand the intricacies of the software, I am aware that’s it is enormously complex.

Still, I had a pleasant hour playing with the radio using the native Mac app, and had two-way contacts in Slovenia, Israel, Switzerland, Poland, Austria, Germany, UK and Belgium. Even got Brazil through the sidelobes of my antenna.

I’ll give it another bash with the Pi400, and take it from there, but again, I appreciate you looking into it for me.

 

[Notachance]

Just got my Pi400 at lunch time, only ordered yesterday afternoon from Amazon so less than 24 hours for a delivery in the Highlands is fairly impressive, which many suppliers charge extra for. Word of warning, mine came set to USA and so the Wireless (WiFi) failed to work. I had to set it to UK Wireless. Apart from that all good.

Edited to add, logged on here with it, just as a test.

 

[Roadster280]

Just got my Pi400 at lunch time, only ordered yesterday afternoon from Amazon so less than 24 hours for a delivery in the Highlands is fairly impressive, which many suppliers charge extra for. Word of warning, mine came set to USA and so the Wireless (WiFi) failed to work. I had to set it to UK Wireless. Apart from that all good.

Edited to add, logged on here with it, just as a test.

That’s a bit weird.. UK or US keyboard? Raspberry Pi OS defaults to UK, so I have to piss about setting it to US to match the physical keyboard.

 

[Notachance]

That’s a bit weird.. UK or US keyboard? Raspberry Pi OS defaults to UK, so I have to piss about setting it to US to match the physical keyboard.

UK Keyboard but it opened set to US Radio. It wouldn't wirelessly join my hub and after several attempts I just bypassed the setup start. Went into settings later and it was showing US Radio, UK keyboard. Quick change to UK and it automatically connected. I was scratching my head a bit until I read the setup guff in the back of the manual.

 

[terminal]

Just got my Pi400 at lunch time, only ordered yesterday afternoon from Amazon so less than 24 hours for a delivery in the Highlands is fairly impressive, which many suppliers charge extra for. Word of warning, mine came set to USA and so the Wireless (WiFi) failed to work. I had to set it to UK Wireless. Apart from that all good.

Edited to add, logged on here with it, just as a test.

After you've had a chance to try it out for a week or so let us know how well it works out for you.

 

[Splitz]

Rasberry pis? Mate, if your pis anything like that colour you need to see the MO pdq...

 

[terminal]

The 64 bit version of Raspberry Pi OS has been out for a couple of days now. I haven't tried it out yet.

Raspberry Pi OS (64-bit)

Operating system images

I just checked my copy of the Raspberry Pi Imager (the program which downloads and burns the image to an SD card) and it shows up when I go to select an OS. It appears under the Raspberry Pi OS (other) option.

 

[Morticiaskeeper]

I've been running 64bit since it went on beta. Not a lot of difference, except I can run the Web version of Sketchup, where I couldn't before, but that might just be the 8gb machine.

Hopefully some more apps will be compiled for it, yes Kicad 6, I'm looking at you.

 

[terminal]

I've been running 64bit since it went on beta. Not a lot of difference, except I can run the Web version of Sketchup, where I couldn't before, but that might just be the 8gb machine.

Hopefully some more apps will be compiled for it, yes Kicad 6, I'm looking at you.

I tested the beta of the 64 bit version a while ago and ran some numerically oriented benchmarks that I have. Compared to the 32 bit version on the same Pi3 hardware, the 64 bit version ran 20 to 25 per cent faster.

You would probably not notice that degree of difference just in using an RPi on a normal basis unless you had a long running CPU intensive task. However, 64 bit was measurably faster.

Down at the very low levels the 64 bit mode works quite a bit differently than 32 bit. It's not simply 32 bit with more bits added on. The designers had a close look at what design features in the 32 bit architecture were bottlenecks and changed them for the 64 bit version. So, software which is compiled for 64 bits will run faster.

However as I said, it may not be something that you notice if you are using it interactively, as there are a number of factors which go into user perception of speed.