Nieuwe 8GB-versie van Raspberry Pi 4 komt uit voor 85 euro

De Raspberry Pi-stichting brengt een nieuwe versie van zijn Raspberry Pi 4 uit, met meer geheugen. De 8GB-versie staat bij winkels voor ongeveer 85 euro en is een aanvulling op de eerdere modellen met 2GB en 4GB.

De stichting schrijft dat er al langer plannen waren voor een 8GB-versie van de Raspberry Pi 4. Zo gebruikt het ontwikkelbordje een BCM2711-chip, die maximaal 16GB aan lpddr4 kan adresseren. Vorig jaar, toen de Raspberry Pi 4 uitkwam, waren lpddr4-packages van 8GB echter nauwelijks beschikbaar. Micron heeft begin dit jaar zo'n package uitgebracht en die zit nu op het nieuwe bordje.

Omdat de nieuwe geheugenpackage een iets hogere piekstroom vereist, zijn er kleine aanpassingen gemaakt aan de stroomvoorzieningen op het Raspberry Pi 4-bordje. Vanwege de coronacrisis waren de daarvoor benodigde onderdelen moeilijk leverbaar en duurde het maken van de aanpassingen drie maanden. In alle andere opzichten is de 8GB-versie gelijk aan de eerdere uitvoeringen van de Raspberry Pi 4.

Het Raspbian-besturingssysteem gebruikt een 32bit kernel en 32bit userland. Het is mogelijk om al het geheugen te gebruiken, maar per proces kan maximaal 3GB worden toegewezen. Volgens de stichting is dat voor de meeste gebruikers geen beperking, omdat tabs in Chromium bijvoorbeeld ieder een eigen proces krijgen. Gebruikers die meer dan 3GB voor een enkel proces willen gebruiken, kunnen een alternatief 64bit-besturingssysteem installeren.

Hoewel de Raspberry-stichting de 32bit-versie van zijn besturingssysteem nog adviseert, verschijnt er ook een bèta van een 64bit-versie. Die heet nu Raspberry Pi OS. De naam Raspbian vervalt, ook voor de 32bit-versie.

De adviesprijs van het nieuwe bordje is 75 dollar. Omgerekend met btw is dat ongeveer 82 euro. Nederlandse webshops bieden de 8GB-versie op het moment van schrijven aan voor prijzen tussen 80 en 90 euro. De versies met 4GB en 2GB ram kosten ongeveer 60 en 40 euro.

8GB-geheugenchip op Raspberry Pi 4
8GB-geheugenchip van Micron op Raspberry Pi 4

Door Julian Huijbregts

Nieuwsredacteur

28-05-2020 • 10:00

241

Submitter: TheSec

Reacties (241)

241
241
116
15
1
109
Wijzig sortering
Vreemd dat Raspbian nog niet is overgestapt naar 64bit. Dat is toch al enige tijd de standaard in computerland. Zijn er inmiddels niet ook al packages e.d. die niet meer in 32bit worden aangeboden? Zover ik weet is raspbian gebaseerd op Debian, dat al sinds jaar en dag 64 bit al standaard heeft. Weet iemand hoe dit zit?
Raspbian is wel 64 bit, je moet het echter zelf nog activeren door middel van de volgende commando's, copy/paste uit mijn eerdere forum post:

Commando's:
sudo apt-get update
sudo apt-get upgrade
sudo rpi-update

Open met nano de config file:
sudo nano /boot/config.txt

Voeg het volgende toe aan de config file:
arm_64bit=1

Vervolgens de Raspberry Pi herstarten. Als de RPI herstart is kun je met de 'uname -a' commando zien of Raspbian nu op 64 draait:
Linux raspberrypi 4.19.118-v8+ #1311 SMP PREEMPT Mon Apr 27 14:32:38 BST 2020 aarch64 GNU/Linux
Als ik alleen een pihole erop draai, heeft het dan nut om dit te doen?
Dan voegt het niet echt wat toe, althans ik merk geen verschil in performance. Maar ik heb het ook meer omdat het kan ;-)
Ik gebruik de Raspberry Pi zelf ook alleen voor Pihole, Domoticz en als network monitoring. 64 bits is daarvoor niet echt nodig.
Moet je als je de nieuwe 8Gb versie wilt sowieso niet op 64-bit gaan draaien? Anders kan hij toch niet meer dan 3Gb geheugen zien?
Dit staat letterlijk in het nieuws artikel:

Het Raspbian-besturingssysteem gebruikt een 32bit kernel en 32bit userland. Het is mogelijk om al het geheugen te gebruiken, maar per proces kan maximaal 3GB worden toegewezen.
Omgekeerd kan af worden gevraagd hoe vaak het wel niet voorkomt dat één proces daadwerkelijk 3GB gebruikt. Op een embedded bordje.
En weer omgekeerd: het is een embedded bordje. Embedded bordjes vervullen vaak maar 1 of beperkt aantal taken vanwege de beperkte verwerkingskracht. Als gebruikers specifiek een 8GB bordje kopen zou het dus best goed kunnen zijn dat ze 1 of 2 taken draaien die juist veel geheugen vergen. Anders hadden ze wel een 2/4GB bordje gekocht :)
64-bit ARM (Aarch64) Instructions Boost Performance by 15 to 30% Compared to 32-bit ARM (Aarch32) Instructions
Met de komst van 64bit voor ARM-CPU's zijn er ook flink wat uitbreidingen gekomen op ARM. Bij het compileren wordt er veel performantere binaire code aangemaakt.
Voor x86 dient de compiler allerlei extra codepadeb te voorzien voor als er bepaalde existenties niet werken. (Dit werk niet met IF's maar door de functie-calls te substitueren).
Een supergeopitmaliseerde versie voor van openElec voor Atom kon niet starten op mijn veel krachtigere Core2Cuo...dat was nog in de tijd van XBMC nu Kodi.
Volgens mij worden de meeste Pi's gebruikt voor Kodi enzo en daar heb je weer extra software in.
Je kunt 't embedded noemen, maar RPI4 is vergelijkbaar in snelheid met sommige telefoons. Noem je die telefoons ook embedded bordjes? ;)
Nee, die noem je telefoons...
als je een Linux kernel draait met PAE support dan zou je theoretisch gezien zelfs tot 64Gb aan ram kunnen draaien op 32bit.

https://en.wikipedia.org/wiki/Physical_Address_Extension
PAE op een ARM? Zoals het gequote artikel ook zegt, PAE is een x86 hack. ARM is rechtstreeks van 32 bits naar AArch64 gegaan.
Anoniem: 718943 @ggj8728 mei 2020 12:43
Nee, 32bits linux kan best overweg met meer dan 4GB geheugen, alleen voor een proces is er niet meer te alloceren dan die (ongeveer?) 3.7GB. Maar als je dus meerdere processen hebt draaien, kunnen ze best hun eigen stukje geheugen pakken.
Dus aanzetten kan sowieso geen kwaad, dan ga ik het natuurlijk wel doen :).
Never change a winning team. Waarom zou je het aanzetten als het niet direct een probleem voor je oplost of je iets geeft wat je nodig hebt of kan gebruiken?
Gewoon omdat het kan natuurlijk :-) We zijn toch techneuten of niet?
Reken er op dat het trager is dan alles 32 bits: je cache is 2x zo snel vol als je alles 64 bits maakt en het voordeel is minimaal tot zelfs negatief qua de performance (geld ook voor x86, maar 64 bits is beter dan 32 bits want het is meer is daar helemaal doorgeslagen).
"Alles is twee keer zo groot" is vooral een probleem voor interpreters en VM's die excessief gebruik maken van pointers. C en C++ code die gewoon stack variabelen gebruiken merken daar lang niet zoveel van. Ja, de instruction pointer is 64 bits, dus bij elke functie call duw je 32 bits extra op de stack, maar variabelen zelf groeien niet.

De grote winst van x86-64 is overigens de registerset. x86-32 heeft om historische redenen maar een beperkt aantal vrij te gebruiken registers, en registers zijn nog veel sneller dan cache.
In 64 bit mode kunnen alle registers voor alles modes ingezet worden, niet dat (e)CX alleen voor counter kan dienen. etc.
En idd. het was ooit voor een zetten generator in Othello handig om alle lopende variabelen in registers te houden (proppen) en alleen het bordje in het geheugen. Dat was destijds even puzzelen. Het verschil was 4 ply verder kijken, dat was op een 8086.
Reken er op dat het trager is dan alles 32 bits [...] geld ook voor x86
Nou als ik hier kijk is 64-bit RPi vaak juist sneller.
En als ik hier kijk (nee, niet de beste bron) is ook x86-64 vaak sneller.
ARM heb ik minder kijk op, maar bij x86-64 speelt iig mee dat het niet alleen 2x zoveel bits is, maar ook wat extraatjes zoals veel meer registers.
Het hangt natuurlijk af van je workload maar goed.
Dat laatste. Die registers bij x86 zijn virtueel en met register renaming zitten er in de onderliggende core zowiezo meer registers. De benchmark vergelijkt armv7 tegen aarch64. De onderliggende cpu in de raspberrypi2 is armv7. Die in de pi4 is armv8.

[Reactie gewijzigd door latka op 22 juli 2024 18:13]

ARMv7 is gewoon de laatste 32-bit ARM architectuur, en slaat op de architectuur van de software.
Die dan idd wordt uitgevoerd door de Pi4 ARMv8 CPU (die ook ARMv7 software kan draaien).
edit: @latka ok, dan haal ik mijn laatste zin ook weg :)

[Reactie gewijzigd door N8w8 op 22 juli 2024 18:13]

had de laatste zin verwijderd maar te laat. Ik keek inderdaad scheel. Ik begreep dat er ook wat verfijningen in de 32bits core zaten voor v8, maar don't quote me on that.
AArch64 heeft ook 2 keer zoveel registers (32 in plaats van 16) en mandatory NEON in plaats van VFP, dus het is verstandig om ook op ARM 64-bit te draaien. Werk je verder nog met KVM, dan is een 64-bit kernel de enige optie, omdat de ondersteuning daarvoor uit de 32-bit Linux kernel is gehaald.
Benchmarks... Je kan vrijwel alles ermee aantonen... door Appels en Peren met elkaar te vergelijken.

Er ontbreekt een stap in de arm benchmark. armv7 vs. armv8...
En dan een armv8 in AARCH32 en een armv8 in AARCH64. (dat zou op hetzelfde bordje gedaan kunnen worden). Er even van uit gaand dat de CPU clocking etc. allemaal gelijk gehouden wordt.
Bij Arm kan er zelfs een verschil zijn tussen armv7 van fabrikant X en armv7 van fabrikant Y.
er is een core instructie set, maar de verschillende fabrikanten kunnen ook extra co-processoren plaatsen of weglaten. dan wel extra eigen instructies toe laten voegen.

(er ontbrak een halve zin).

[Reactie gewijzigd door tweaknico op 22 juli 2024 18:13]

Je kan vrijwel alles ermee aantonen... door Appels en Peren met elkaar te vergelijken.
Ja, lekker genuanceerd en onderbouwd ook.
Ik neem aan dat de meesten Raspbian/Debian ofzo willen draaien, en niet zelf willen compilen.
Dan heb je de keus uit ARMv8 Aarch64, en ARMv7 Aarch32.
Dat is dan ook een voor de hand liggende vergelijking.
edit: Voor de duidelijkheid, waar je (en @latka) op hint, dat ARMv8 Aarch32 sneller kan zijn, neem ik van jullie aan.

[Reactie gewijzigd door N8w8 op 22 juli 2024 18:13]

Het klopt wat je daar zegt, maar dat is theoretisch. In de praktijk merk je echt geen vertraging, er is voldoende cache beschikbaar.
cash is hier toch evenwel vaak het probleem om te gaan tweaken...
Ik heb toch af en toe wel een cash probleem :+
(geld ook voor x86, maar 64 bits is beter dan 32 bits want het is meer is daar helemaal doorgeslagen).
Dat is wel een beetje overdreven. Je kunt amper nog computers kopen die <4GB hebben en veel programmas zijn tegenwoordig tientallen GBs groot en draaien toch default nog in 32-bit. En natuurlijk hoeft notepad niet 64-bit te zijn. Maar bijvoorbeeld in excel kan het verschil snel enorm oplopen en games gebruiken makkelijk meer dan 4GB. World of Tanks had jaren een 64-bit client klaar maar zetten die default pas een maand geleden aan. Maar de 64-bit versie liep op systemen met veel RAM duidelijk soepeler omdat het veel meer gegevens in het werkgeheugen wist te houden. De 32-bit client moest zo nu en dan data van de HDD/SSD lezen en vooral als je op een HDD zat, zorgde dat voor enorme framedrops en door de manier op die het werkte waren die ook altijd op cruciale momenten (en bijvoorbeeld een nieuwe vijand in beeld kwam).
Als de working set (te zien in je taskmanager) onder de 2gb blijft heeft 64 bits niet zoveel zin en levert het voornamelijk cache vervuiling op. Dat je computer meer dan 4gb heeft betekent niet dat ieder proces dat (nodig) heeft. Dus als je per process 10% geheugen kunt besparen door naar 32 bits te gaan kun je een extra tabblad in chrome openen :+
Ik zou niet met je DNS server teveel risico's nemen... Pak dan een nieuwe RPi ;-)
Ik zou niet met je DNS server teveel risico's nemen...
Stel je tweede DNS server in op die van je router. Probleem opgelost als de eerste (de PiHole) uitvalt.
Tweede DNS server is geen secundaire DNS server: je machine zal allebei gebruiken en dus de helft van de tijd geen PiHole service krijgen, ook al is die beschikbaar.

[Reactie gewijzigd door Vaudtje op 22 juli 2024 18:13]

Je kunt PiHole wel in HA zetten met de volgende handleiding. Werkt prima.
Mja wij hebben denk ik een verschillende opvatting qua definitie oplossing/workaround... Daarnaast, ik ben niet 100% zeker dat DNS server 1 100% van de gevallen wordt gebruikt als je er 2 instelt.
Als je je 2e DNS server instelt op die van je router dan komt de reclame toch alsnog door? Of haalt Pihole hier een slim trucje voor uit?

[Reactie gewijzigd door turbojet80s op 22 juli 2024 18:13]

Nou nee, ik zou eerder zeggen een ander SD kaartje, een PiHole is echt niet zo belangrijk dat het 100% up time hoeft te hebben zeker als het alleen jouw eigen systeem is en de rest van het huis gewoon door kan gaan met het internet gebruik (al dan niet met advertenties) dan is het echt zo'n ramp niet.

Daarnaast is het gewoon leuk om mee te spelen en zo lang je een DNS server op een Pi draait moet je je zelf geen illusies maken en gewoon accepteren dat af en toe een beetje downtime gewoon kan gebeuren. Als je missie kritische software draait en flink geld kan verliezen als je even geen DNS lookup uit kan voeren dan draai je ook geen Pi als DNS server mag ik hopen.
Een pi-hole is bedoeld als vervanging voor de main DNS, dus zonder Pi-hole, geen internet (nouja, geen DNS resolving meer).
Dat is redelijk makkelijk op te lossen, simpel weg 1 systeem van de pi-hole gebruik laten maken terwijl je er mee speelt en de rest de provider dns of cloudfare, google etc dns laten gebruiken.

Als je niet instaat bent dat zo in te stellen in je netwerk is het misschien juist tijd om met het ding te gaan spelen zodat je kan leren hoe dit soort dingen werken. En nogmaals 100% up time op een consumer lijn in een gemiddelde woonwijk ergens in het land gaat je echt niet lukken. Daar betaal je veel te weinig voor en dat is ook helemaal niet nodig.

Als je gewoon een aparte SD kaart hebt om met de pi te spelen en nieuwe instellingen te testen dan kun je als je om welke reden dan ook niet blij bent met je experiment meteen terug naar de originele instellingen (als moeders de vrouw thuis komt en netflix niet werk omdat je nu al weer met het internet aan het klooien bent bijvoorbeeld).

Natuurlijk is een tweede pi ook een optie maar de kosten zijn redelijk wat hoger voor zo'n ding dan een SD kaartje dat je als tweaker waarschijnlijk toch nog wel ergens hebt liggen.
Ik 'speel' er niet (meer) mee, ik gebruik het full-time en in productie hier.
Kan wel kwaad qua beschikbare software op de raspberry.

Aangezien de meesten linux draaien, heeft het voordelen qua code paden. 32 bits paden zijn erg slecht onderhouden. Dit was voor diverse distros zelfs de hoofdreden om 32/bits te laten vallen (en niet de enorme hoeveelheid extra branching werk wat ze hadden, waaronder dubbel testen etc). Ook voor arm.
De beschikbare software wordt minder of meer?
Minder... Maar dat is natuurlijk een tijdelijk probleem.
zou niet meer of minder durven te zeggen momenteel.

Sinds de nieuwere versies meer geheugen gebruiken dan je kunt alloceren onder 32 bits, vermoed ik dat er best wat software is dat te veel geheugen vraagt om (stabiel) te draaien onder 32 bits. Tegenwoordig wordt dat bordje gezien als een volwaardig desktop alternatief (wat nog steeds behelpen blijf vergeleken met een 10 jaar oude laptop, maar toch).
De beschikbare hoeveelheid software blijft hetzelfde, maar als de meeste gebruikers en vooral ontwikkelaars 64-bit draaien, zal de ondersteuning voor 32-bit op den duur achter gaan lopen en op een gegeven moment zelfs stopgezet worden.

Ik draai alleen 64-bit Debian (arm64) direct op de hardware en 32-bit (armhf en armel) in QEMU/KVM met een 64-bit kernel. Voor zover ik weet, ondersteunt alleen Debian nog 32-bit architecturen en daarnaast heb je nog Gentoo en de BSD's.
Dus de Pi0 backward compatibility issue is niet langer aanwezig?
Tegen welk probleem ben je aangelopen of denk je aan te lopen? Heb je een voorbeeld van software die wel als 32-bit binary beschikbaar is, maar niet als 64-bit? Ik probeer via upstream projecten zoveel mogelijk aan de praat te krijgen en eventueel te porten naar 64-bit, maar er is nog maar weinig wat niet werkt.
Gebruik momenteel geen raspberry, zijn doorgestuurd naar andere developers (had ze gekregen). Weet het echt niet meer, maar heb het zeker gemeld. Groot fan van minder complexiteit in code, fijn dat je dit oppakt!
Heb jij niet veel last van sites die niet goed werken door Pihole?
Nog geen enkel moment last van gehad. Hoezo? :-)
Tegenwoordig hebben steeds meer site addblock checks. Met een blocker in je browser kun je hem snel uitschakelen. Voor Pihole lijkt me dat omslachtiger.
Simpel op te lossen door gebruik te maken van de 'disable' en 'enable' API. Snelkoppeling is zo gemaakt in een browser.
Ah wat mooi, dat wist ik niet. Dat scheelt weer ja
Dat valt ook weer mee, je kunt via de admin portal (ip-adres) inloggen om een specifieke site te whitelisten dan wel tijdelijk al het verkeer door te laten of zelfs een specifieke client geheel uitsluiten.
Ik kom dat maar heel zelden tegen, alleen bij vage Amerikaanse nieuwssites ofzo en dat probleem los ik dan op door gewoon die pagina niet te lezen maar het artikel op te zoeken in de google cache of wat dan ook :)
Als aanvulling hierop;

Vaak staan er advertenties/sponsored links in google, en aangezien je pihole google tracking e.d. ook tegen houd kan je bijvoorbeeld de chrome extensie Remove Redirect Everywhere gebruiken.
Je kan dan wel op deze links klikken zonder dat pihole het tegen houd
Je kunt ook een andere adlist gebruiken die daar beter mee omgaat.

Ik gebruik https://dbl.oisd.nl/, die blokkeert (veel) meer dan de lijsten die standaard inbegrepen zijn maar toch kun je advertentie links op bijvoorbeeld Google aanklikken.
Enigszins Off-topic: Hier ook een Pi3B met Domoticz, Pihole en OpenVPN. Wat voor netwerkmonitoring draai jij op je Pi?
Ik zie...

Linux raspberrypi 4.19.118-v8+ #1311 SMP PREEMPT Mon Apr 27 14:32:38 BST 2020 aarch64 GNU/Linux???

aarch64, dat is volgens mij Arch linux en daarvoor zeg je dat je een sudo apt-get uitvoerd wat weer Raspbian/Debian commando's zijn.

Klopt dit wel?
En omdat een beetje context geven bij een linkje wat ooit kaduuk kan gaan wel handig is:
AArch64 is the 64-bit execution state of the ARMv8 ISA. A machine in this state executes operates on the A64 instruction set. This is in contrast to the AArch32 which describes the classical 32-bit ARM execution state.
Jullie hebben helemaal gelijk, bedankt voor het verduidelijken.

8)7
aarch64 is 64-bit ARM, not Archlinux.
Anoniem: 718943 @MvK6828 mei 2020 12:44
arch staat voor architectuur, niet voor archlinux.
Oh wow.. je OS wordt dus 64 bit door simpel een config file aan te passen...
Dat is bijna magie... Ik heb lang geleden wel eens een ubuntu install gesloopt toen ik van 32 bit naar 64 bit probeerde te gaan... Dat moest kunnen volgens iemand op irc, maar niet door mij in ieder geval...
Zo werkt dat natuurlijk niet. Het OS heeft al 64 bit ondersteuning, je moet het echter zelf nog activeren. Dat gebeurd echt niet alleen maar met een magische commando in de config file.
Het valt mee, dat zorgt er alleen voor dat de bootloader de 64-bit kernel start.
De rest is dan nog 32-bit, maar je kan daarmee wel bijv twee (32-bit dus) processen draaien die elk 4GB gebruiken (of kon dat ook al met de 32-bit kernel met LPAE? Maar zal wel langzamer zijn).
Ubuntu geen verstand van, maar op mijn Debian PC heb ik 32-bit wel compleet kunnen vervangen door 64 bit, maar daar waren wel wat meer stappen voor nodig.
If the system had packages that depend on apt like apt-utils, it's possible run into a situation where apt -f install wants to revert apt itself to i386.
Fun times! Het is al lang geleden, maar dit soort dingen gebeurden er... Backup en herinstallatie waren simpeler.
Zegt `dpkg --print-architecture` ook dat er 32bit en 64bit arm wordt geïnstalleerd? Anders draai je alleen de 64bit kernel zonder 64bit userland (programma's).
root@raspberrypi:~ # uname -a
Linux raspberrypi.0wnd.nl 4.19.118-v8+ #1311 SMP PREEMPT Mon Apr 27 14:32:38 BST 2020 aarch64 GNU/Linux
root@raspberrypi:~ # dpkg --print-architecture
armhf
Dat ('armhf') zou betekenen dat dpkg zelf 32bit is. Misschien dat `dpkg --print-foreign-architectures` wel arm64 aangeeft ? Debian heeft hier documentatie over onder de noemer 'Multiarch'

Edit: -s

[Reactie gewijzigd door Henk Poley op 22 juli 2024 18:13]

Zero output (architectures met s):
root@raspberrypi:~ # dpkg --print-foreign-architectures
root@raspberrypi:~ #
Dan draai je dus 32bit programma's op een 64bit kernel.

Lees hier wel dat ze pas vanaf vandaag de transitie naar 64bit officieel in gaan: z1rconium in 'nieuws: Nieuwe 8GB-versie van Raspberry Pi 4 komt uit voor 85 e...

Mag je zelf besluiten hoe avontuurlijk je bent.
Ja haha, maar is die wel dan fully 64 bits? Of ook 64 bits enabled kernel en de rest niet?
Ik weet niet wat je bedoelt. De kernel bij jou is 64 bit, de rest niet. Maar omdat je een 64bit kernel hebt zou je wel 64bit programma's kunnen draaien. Maar je hebt ze niet. Beantwoord dat je vraag?
Nee, deze nieuwe raspbian, 64 bits, is deze wel fully 64bits, dus ook packages?

Overigens heeft deze update naar 64 bits lighttpd gesloopt, ik ga dus terug naar non 64 bits. Voorlopig dan.
Hierna komen er overigens een sloot updates binnen.
Was het niet zo dat de AES-NI ondersteuning alleen werkte met een 64-bit OS? Dan zou switchen naar 64Bit best wel extra performance moeten opleveren als je OpenVPN draait.
Geen idee eerlijk gezegd, ik gebruik ook geen OpenVPN.
Met die ingreep draai je een 64-bit kernel, maar wel nog gewoon 32-bit programma's. Het is met name verstandig vanwege prestatieredenen, want de 32-bit kernel moet truukjes gebruiken om al het geheugen te kunnen zien, terwijl de 64-bit kernel alle 8GB tegelijk kan zien. Ook stijgt de hoeveelheid geheugen die een programma kan zien van 3GB naar 4GB, omdat een 32-bit kernel ruimte moet reserveren in de adresruimte voor de kernel zelf, terwijl bij een 64-bit kernel de kernel buiten de adresruimte van het programma geplaatst kan worden.

Een individueel 32-bit programma kan bij deze ingreep dus maximaal 4GB geheugen alloceren. Bij 8GB totaal aan geheugen is dat nog geen groot probleem. Als de hoeveelheid geheugen nog verder toe zou nemen, begint die 4GB-limiet knellend te worden en wil je op een bepaald moment een echte 64-bit distributie gaan draaien.
Er is een 64bit beta test versie van Raspberry Pi OS ("voorheen Raspbian")

https://www.raspberrypi.o...wtopic.php?f=117&t=275370
We still recommend the 32 bit operating system for all Pis at this time, although have decided it is now time to begin the move toward a 64bit OS. For the moment this is a 'beta' program, the OS is in heavy flux and its functionality is likely to change significantly over the next few months.

Note, the 64bit OS is only install-able on the Pi 3 and Pi 4 devices

Known issues
1) There is no hardware video acceleration in VLC or Chromium
2) libraspberrypi0, libraspberrypi-dev and libraspberrypi-doc have been moved out of /opt/vc/* and into /usr/* instead (making it more standard). Any code built against these libraries will require changing to refer to a more standard location (/usr/lib/ rather than /opt/vc/lib)
3) raspberrypi-bootloader and raspberrypi-kernel contain useless non-64bit binaries and is missing the work done to minimise the delay between files being deleted and installed to /boot
Zou in het artikel erbij mogen, want deze hebben ze ook pas vandaag gedropt.
Arm heeft 64-bit pas aangekondigd in 2011 vanaf ARMv8 (RPi 3/4) en voor veel develop boards is het niet echt een meerwaarde en verbruikt het gewoon meer energie. Natuurlijk gebruiken veel mensen de RPi als media center of retro emulator en dan kan het wel een meerwaarde hebben.
Het is natuurlijk een ARM en geen x86 kernel, ik weet eigenlijk niet hoever Linux is met ARM met een 64bits kernel?
Full support voor 64-bit ARM (AARCH64), basically.

[Reactie gewijzigd door Cilph op 22 juli 2024 18:13]

Gezien Android een Linux kernel draait op ARM en de high-end toestellen toch al een paar jaar op 64 bit draaien denk ik dat dit wel snor zit. :)
Anoniem: 718943 @pennywiser28 mei 2020 12:49
De linux kernel heeft sinds versie 3.7 (eind 2012) support voor aarch64.
Vanaf versie 3 is er toch 64bit support?
Voor zo ver ik weet is dit vanwege compatibiliteit met oude raspberry's die alleen 32-bit ondersteunen.
De BCM2711 is heeft de Cortex-A72 (ARM v8) core en die is wel 64-bit hoor. Maar blijkbaar heeft de soc wel een beperkte adresbus en kan dus niet meer geheugen adresseren.

[Reactie gewijzigd door D-Three op 22 juli 2024 18:13]

Met name om 1 raspbian voor alle RPi bordjes te hebben, dus ivm backwards compatibility.
Daarnaast is/was er weinig winst te halen met 64-bit op een RPi (Nu, met meer dan 4GB geheugen wordt dat misschien anders)
Dat is helemaal niet gek: Raspberry Pi 4 is de eerste waar 4GB geheugen op kan en waarbij de 32-bits ruimte knellend begon te worden. Voor een Raspberry Pi 1 (nog steeds geproduceerd) met 512MB geheugen is 64-bit niet zo nuttig en de processor ondersteunt het niet. Omdat men één Raspbian maakt dat op alle Pi's werkt is het volstrekt logisch dat pas nu omgeschakeld gaat worden.

Je kon overigens al eenvoudig een 64-bit kernal op je Pi4 zetten.
Devuan (Debian met een alternatief init gedeelte) maakt ook gebruik van debian packages. Ik draai de 64 bit Arm variant op een Rpi 3. Het werkt zonder problemen.
Op de Pi zero moest ik wel naar de 32 bit versie, ik geloof vanwege de gebruikte processor. De Pi zero heeft sowieso maar 512 MB ram, dan is 32 bit goed genoeg.
De RPi3 heeft ook maar 1GB, dus is 32bits genoeg :)

Ik wist overigens niet dat Devuan er voor de RPi was, dus dank voor de melding. ("alternatief init gedeelte" betekent "Geen systemd", wat ik eerlijk gezegd erg fijn vind)
Ik heb alweer een tijdje geleden wat benchmarking gedaan tussen 64bits/32bits, en het blijkt dat de 32bits versie van Raspbian zo ongelooflijk goed geoptimaliseerd is dat 64bits alleen maar nadelen brengt: trager, meer geheugengebruik, grotere bestanden.
Dat is overigens wat Eben Upton, de grondlegger van de Raspberry Pi Foundation, altijd al beweerde, maar ik geloofde gewoon niet dat 64bits trager dan 32bits zou zijn. Hij had gelijk.

Het enige voordeel leken snellere 64bits floating point bewerkingen te zijn, maar dat bleek aan een niet helemaal eerlijke benchmark te liggen.

Zie: https://www.raspberrypi.o...=152471&start=50#p1200809
Niet vreemd als je bedenkt dat de Pi1, Pi2, en Pi0 alleen 32 bit zijn, en de ontwerpfilosofie altijd is geweest dat je het zelfde SD kaartje met OS in alle apparaten kan stoppen.

Pas met de RPI4 levert 64bit een duidelijke meerwaarde op. Aanpassen kost tijd. Programma's als Mathematica lopen nog niet op 64bit.
Dat aanpassen kost geen tijd: je kunt heel gemakkelijk de hele debian/ubuntu repository naar 64 bits compileren (sterker nog, die staat gewoon online, ik meen arm64 draait gewoon op de Pi).

En bovendien kun je op het 64 bits OS gewoon 32 bits applicaties draaien, dat is het mooie van Linux, is allemaal backwards compatible....
Tegen dat mijn huis helemaal slim is stappen ze hopelijk over, kan ik eindelijk alles lokaal aansturen! :)
Lange termijn support is een van de hoofd doelen van de RPI. Denk er aan dat het hele project origineel (en nog steeds) voornamelijk educatieve doelen had.

En tot nu toe met 4GB maximaal was 32-bit waarschijnlijk genoeg.
Ik heb het gevoel dat ze afdrijven van het oorspronkelijke doel, een hobby of educatief bordje. Ze worden duurder en duurder. Zwaardere eisen aan koeling en power. Ik zie geen evolutie in de Raspberry pi zero bijvoorbeeld?
Wordt deze 8GB versie samen met een bootable USB SSD harddisk (door middel van: nieuws: Bètafirmware maakt booten via usb-opslag voor Raspberry Pi 4 mogelijk de ideale laag verbruik docker server voor minder zware applicaties/services? (Apps zoals Domitoca applicaties, slimme meter uitlezen, SolarEdge applicaties (zonnepanelen) en Ubiquiti controller) :)

[Reactie gewijzigd door MuVo op 22 juli 2024 18:13]

Het grootste nadeel van een Raspberry Pi tot op heden is mijn inziens het ontbreken van betrouwbare opslag. Elke serieuze single board computer heeft op zijn minst eMMC geheugen en het liefst een M-keyed M.2-slot voor nvme-ssd's (al dan niet via een riser/dochterbordje). Wat betreft performance loopt de RPi ook altijd achter. Op zich niet gek aangezien het een low budget sbc is voor educatieve doeleinden.

Voor power users zijn er veel leukere sbc's zoals de Khadas VIM3(L), Hardkernel Odroid C4, N2 en H2 (Intel J4105), Raxda RockPi 4, X en N10 en Nvidia Jetson Nano.

Het is wel grappig dat de 8GB-versie van de RPi nu wat betreft werkgeheugen tot de top behoort. Meer dan 4GB ram zie je weinig. De RockPi N10 is verkrijgbaar met 8GB en de Jetson Xavier NX met 8GB, maar dat is een bord van 500 euro. De Odroid H2 heeft so-dimm-slots en kan tot 32GB.

[Reactie gewijzigd door Femme op 22 juli 2024 18:13]

Ik herken wat je zegt maar er zijn wel minder fraaie en onpraktische oplossingen voor handen. Ik heb bijvoorbeeld zelf een externe harde schijf als bootable usbdrive aan mijn RPi3 hangen en gebruik dus geen "fragiele" microsd kaartjes meer.
Anoniem: 498327 @Femme28 mei 2020 12:29
Precies dat, en met de prijzen die ze nu vragen. Kan je toch veel beter zoiets kopen:
pricewatch: Intel NUC Kit NUC5PPYH
Dat ding is hws sneller en zuiniger, ik vraag me af of RPi's al op 14nm worden gebakken.
De Pi is nog steeds een 28nm product:
https://www.tomshardware....ben-upton-ama,6206-2.html

[Reactie gewijzigd door Anoniem: 498327 op 22 juli 2024 18:13]

Op zich heb je daar wel gelijk in en daarom wacht ik zelf op de nieuwe generatie SoC's met betere prestaties. Ik denk wel dat het niet een kwestie is van of het een of het ander. Je kunt ze gerust naast elkaar gebruiken, omdat de Linux ondersteuning voor x86-64 en aarch64 tegenwoordig vrijwel even goed is.

Er zal heus nog wel het een en ander te optimaliseren zijn voor aarch64, maar het is nu goed genoeg om bruikbaar te zijn.
Dat de RPi geen betrouwbare opslag heeft en mogelijk ook andere professionele/zakelijke kwaliteiten mist vind de oorsprong in de reden waarom de RPi bestaat. Het is begonnen als speel en/of onderwijs machine. En wat mij betreft staat dat nog steeds. Daar waar de keuze is tussen perfectie en niet onnodig veel licenties wordt gekozen om met minder licenties te werken.

Als je serieus, dat wil zeggen zakelijk/professioneel met dit soort machines wilt werken, dan heb je heel andere eisen en wensen die niet passen op de RPi.

Wel hoop ik dat de boot-mogelijkheid van de RPi wat breeder wordt, dat ze geen sd-kaart nodig heeft maar ook via 1 van de andere interfaces kan booten met een standaard protocol. Dus via het netwerk, via usb-opslag (cdrom/stick/disk) en mogelijke anderen.

Aan de andere kant vind ik het niet verkeerd om een kleine sd-kaart te kunnen maken die read-only gebruikt wordt waar vandaan geboot wordt van het gewenste medium. De sd-kaart problemen voor zover ik weet zijn vooral veroorzaakt door schrijf acties. Die voorkomen voorkomt volgens mij veel issues.
via usb kan al..
Van de nieuwe weet ik dat het in ieder geval in de pen zit. Werkt het al vanaf all usb varianten? stick, disk, cdrom, ...

Het zou mooi zijn als de RPi wat ingebouwde opslag krijgt voor efi of uefi of zo, dan kan er wat meer met de boot mogelijkheden worden gespeeld.

Aan de andere kant, dat efi of uefi opslag is in principe read-only. Misschien kan iemand een sd-image maken om een efi of uefi boot te regelen. Dat hoeft geen gigabytes aan opslag te krijgen. De echte boot gaat dan helaas niet meer van sd kaart maar wel van alle andere boot-devices. Zelfs die nu nog niet zijn voorzien. Misschien wel netwerk-boot via een blue-tooth verbinding.
<Let niet op mij, het is al laat>

[Reactie gewijzigd door Martinirenner op 22 juli 2024 18:13]

Het zou mooi zijn als er ook compute modules komen voor Turing Pi, want dan kan ik Intel echt gedag zeggen.
Tsja, SD kaarten stop je in alle telefoons en in alle fototoestellen. Is dat allemaal niet betrouwbaar?

Je kon al lang van USB of van netwerk booten, en een read-only SD kaart (boot) samen met een SSD voor de root partitie was ook al tijden mogelijk bij de RPI4. Dat werkt als een trein.

Alles heeft een prijs, en wisselbare SD-kaarten hebben weer een groot gebruiksgemak.
Heb nog nooit een kapotte SD kaart gehad bij gebruik in de PI, wel in mijn tablet en telefoon. En kapotte harddisks in mijn pc's en laptops.

Voor HomeAssistant is een SSD zeker aan te raden.

Qua performance, de andere boardjes die je noemt zijn in theorie sneller, maar juist de software ondersteuning is wat een Pi de aankoop waard maakt, en daar schort het nog wel eens bij de concurrenten.

Voorbeeld de RPI3 heeft geen HEVC Hardware ondersteuning, maar uiteindelijk met veel softwareverbeteringen kon de RPI3 wel 1080p HEVC decoden in Kodi.

Dus de theoretisch snelheid van de hardware zegt weinig zonder goed software. Ondersteuning is ook veel waard.

[Reactie gewijzigd door Jan121 op 22 juli 2024 18:13]

Een mediaspeler zal inderdaad niet snel een SD-kaart kapot schrijven en de I/O performance boeit ook niet. Voor smarthomes, IoT en andere vormen van edge computing waarbij snelle en betrouwbare lokale opslag gewenst is wil je liever iets anders dan SD. Om ook de form factor beperkt te houden is dan het wel handig dat je direct op het board een eMMC module of nvme-ssd kunt prikken.
Of betere kwaliteit SD-kaart.

Valt daar geen winst te behalen, hoe zit het met High Endurance SD-kaarten.

Of neem de compute module die heeft eMMC ondersteuning:
https://www.raspberrypi.org/products/compute-module-3/
https://www.raspberrypi.o...mpute-module-io-board-v3/

[Reactie gewijzigd door Jan121 op 22 juli 2024 18:13]

Het probleem van een sd-kaart ten opzichte van andere 'solid-state' opslag is dat er in een sd-kaart geen controller zit. Bij de andere solid-state opslag zorgt de controller voor wear-leveling. De schrijf acties worden daar dan over de hele opslag verdeeld en met een adres-remapping ziet de gebruiker daar niets van.

Bij een sd-kaart die vaak en veel wordt beschreven, gebeurt dat ook veel (te veel) op de zelfde plaats. Een paar issues bij een 'standaard' linux installatie zoals op de RPi gebruikt:
- logfiles worden bij iedere boot en daarna regelmatig geschreven. op zich geen probleem maar ook de inode wordt steeds bijgewerkt. Dat schrijft steeds de zelfde paar bytes. Daarom heb ik een logserver ingericht op de nas. Voor het bijhouden van de log op het systeem zelf is een ramdisk wenselijk.
- swap-ruimte: Omdat de RPi beperkt is in geheugen wordt de swap-ruimte al snel gebruikt. Ook dat begint steeds op de zelfde blokken. Deze zet ik daarom altijd zo snel mogelijk uit.
En zo zijn er nog wel de nodige zaken die te vaak op de zelfde plaats schrijven.
Een SD kaart heeft wel een controller; meestal een kleine ARM cpu. De SD standaard beschrijft inderdaad niet dat wear-leveling verplicht is. In https://www.alliedelec.co...011446889dbd6129e2644.pdf deze datasheet van sandisk micro sd kaartjes uit 2010 hebben ze het over wear leveling, waardoor ik vermoed dat het bij de grote fabrikanten wel prima zit.

De RPI staat berucht om 't kapotmaken van SD kaartjes vooral door 't verwijderen van stroom terwijl naar het kaartje geschreven wordt, en door foute configuratie (swap file onder andere). Een SD kaartje is gewoon kapot na ~300 beschrijvingen. Dus als het systeem de hele tijd zit te swappen dan kun je nog zo goed wear-levelen, 't kaartje houdt het een paar maanden vol

[Reactie gewijzigd door redtails op 22 juli 2024 18:13]

Opslag is de voornaamste reden dat ik de RPi nog links heb laten liggen. Een SD slot vindt ik niet betrouwbaar en je levert in op performance.

Nu is het inderdaad zo dat de RPi achterloopt op performance, maar qua prijs is het altijd een interessant stukje hardware geweest.

Bedankt voor de aanvulling, dat zijn interessante concurrerende bordjes.

Mocht de firmware aanpassing uitkomen zodat er fatsoenlijke boot-opslag mogelijk is met de RPi, dan ga ik RPi overwegen (Als een RPi past bij mijn doel en de services die ik er op wil draaien).
Wat is laag verbruik voor jou?

je kan een PC bouwen met speciaal Fujitsu mATX moederbord en zuinige Core processor die idle net zo weinig of minder verbruikt dan deze RPi4. Met veel meer power en uitbreidingsmogelijkheden.

Unifi Controller is trouwens behoorlijk overrated. Je kan het gebruiken om de boel eenmalig in te stellen. 24/7 laten draaien blijkt niet nodig te zijn..
Laag verbruik in de vorm van een kant en klare computer met een goede prijs/presentatie verhouding. Ik begrijp dat je met Fujitsu mATX een nog zuiniger systeem kunt bouwen welke nog krachtiger is, maar dan kost het ook meer.

Als voorbeeld is laag verbruik van een Pi4 voor mij voldoende om 24/7 te draaien. Ik heb ook een Intel i5 computer met een workstation moederbord welke ik ook als server kan gebruiken. Maar als ik de i5 server 24/7 laat draaien heeft het geen laag gebruik, want het is er niet voor gemaakt. Het geeft wel een betere performance, maar die performance is niet nodig voor de kleine taken die ik 24/7 wil draaien.

Momenteel heb ik docker draaien op mijn QNAP nas, maar gezien docker niet naar mijn wensen ondersteund wordt door QNAP denk ik er over om ooit een Pi4 aan te schaffen en in te richten als docker server.
Unifi Controller is trouwens behoorlijk overrated. Je kan het gebruiken om de boel eenmalig in te stellen. 24/7 laten draaien blijkt niet nodig te zijn..
Tenzij je een guest portal gebruikt voor je wifi.. dan wel.
Dan wel inderdaad, heb ik ook ingesteld maar dat was vooral voor de lol en omdat het kan.

[Reactie gewijzigd door Jazco2nd op 22 juli 2024 18:13]

En dagelijkse backups van je config, en logs van alle verbindingen, en auto-update van je hardware.
Ha ok, maar voor 98% van de thuisgebruikers heb je dat allemaal niet nodig..
dagelijkse backup, ik heb 1x een backup van de config gemaakt. Na het instellen. Klaar :)
Voor de huis-tuin-keuken gebruiker inderdaad misschien niet zo spannend ;)
Backups en logs zou ik nooit naar een RPi doen, beter naar een nas met een log-server. De RPi is niet de beste met opslag.

Hoewel, aan de andere kant is de RPi wel een goede controller voor de aansturing en verwerking.
Unifi controller moet afhankelijk van wat je er mee doet soms wel 27/7 zijn. voor uitgebreide loging volgens mij. Maar zeker als je een captive portal hebt draaien
Een 24x7 controller heb je wel nodig als je bijvoorbeeld persistente niet-standaard configuraties hebt. Zolang alles blijft draaien is er niks aan de hand, maar als om welke reden dan ook de stroom even wegvalt van je router/switch/access point, moet je controller ook aan staan.

Of zoals hieronder al wordt aangegeven een gastenportaal, maar ook bijvoorbeeld voor de DPI-logging. Ik weet niet of het noodzakelijk is voor tijdslimieten te forceren (dus dat een bepaalde client alleen overdag toegangkelijk is)

De ingebouwde RADIUS server om per-apparaat VLANs te gebruiken, enz. enz. enz.

Als je alleen de basisfuncties gebruikt, dan hoeft hij inderdaad niet aan te blijven.
De 3B gebruikt iets van 3 watt.
De combis die ik noem doen dat idle ook :) en je systeem is 90% van de tijd idle.
maar 1) veel duurder 2) veel krachtiger 3) veel flexibeler.
zie ook de first post hier:
Het grote zuinige server topic - deel 2
En dus 4) overkill, als je die kracht en flexibiliteit niet nodig hebt.

Je kunt gewoon een nieuw bord kopen om de aantal jaar, je schijven eraan hangen en verder gaan waar je gebleven was.
Klopt. Ik heb ook jarenlang een RPi 3B gebruikt als NAS en mediaserver. Echter merkte ik meer problemen helaas. Zo werd, zelfs met de officiele voeding en goede USB hub, de HDD toch niet stabiel gevoed, (merkte ik meestal pas na een jaar). Ik heb door de jaren heen (vanaf een RPi2) best wat harde schijven versleten.
Nu met ECC non-registered geheugen (voorkomt HDD write errors) en stabiele voeding, icm zuinigere SATA schijven ipv USB met zijn overhead verbruik ik minder energie en gaan mijn HDDs langer mee.

plus je krijgt er een volwaardig workstation bij als je er een monitor en toetsenbord bij zet. Dat wil niet iedereen natuurlijk, maar kan voordelen bieden.
...of als je een Unifi Security Gateway gebruikt en je wilt zaken monitoren. Nogal onhandig om dan elke keer weer de Unifi controller te installeren. Ook het updaten van devices kan volgens mij niet zonder de controller.
maar als je zo professioneel bezig bent, ga je de Unifi controller dan op een volwaardige server draaien of op een RPi? Want dat is de context hier en daar reageer ik op.
maar als je zo professioneel bezig bent, ga je de Unifi controller dan op een volwaardige server draaien of op een RPi? Want dat is de context hier en daar reageer ik op.
Op een Unifi CloudKey natuurlijk.
Als je toch al 85 euro moet betalen voor zo'n ding zou ik er nog 3 a 4 tientjes bijleggen en voor een brix/nuc/mini zotac gaan. Je koopt dan een stuk meer flexibiliteit.
Een NUC voor 125 euro? Waar dan?
pricewatch: Intel NUC Kit NUC7CJYH (met EU-stekker) voor 110 euro.
Moet alleen nog wel geheugen en opslag bij maar die zijn ook niet vreselijk duur.

Voordeel daar is dat je ook AES acceleratie hebt en dat maakt een hoop verschil als je iets met ge-encrypte opslag doet of een VPN.
Dus dan is het niet vergelijkbaar. Immers een raspberry pi 4 voor 85 euro heeft alles erin zitten. Je hoeft alleen nog maar een sd kaart toe te voegen
Ja het was ook niet mijn comment maar @oef! zei dan ook dat hij dan liever een paar tientjes meer uitgaf voor een NUC.

Zoals je zelf zegt heeft een Raspberry standaard ook geen opslag bijgeleverd. Bij de NUC kom je uit op 110 euro + geheugen voor je op hetzelfde punt uitkomt als een raspberry. Dat is wel duurder maar ook een stuk krachtiger natuurlijk.
Mwah, je wil er natuurlijk ook een behuizing voor hebben en een fatsoenlijke voeding (de laatste modellen zijn iets kieskeuriger). Het is allemaal niet schokkend prijzig maar je komt toch makkelijk boven de 100 euro uit.

In principe zou je natuurlijk een NUC ook gewoon vanaf een USB stickje kunnen laten draaien maar goed, een SSD kost geen donder en performt meestal beter dan externe opslag.

Ik gebruik zelf ook een raspberry pi maar de meeste VM's / containers draai ik op een servertje, dat werkt in de praktijk toch sneller en lekkerder.
Als je toch al 85 euro moet betalen voor zo'n ding zou ik er nog 3 a 4 tientjes bijleggen en voor een brix/nuc/mini zotac gaan. Je koopt dan een stuk meer flexibiliteit.
Waar kun je zoiets kopen voor een 125 euro dan?
Bij vraag&aanbod :)

Ik heb destijds voor 120€ een 2e hands nuc gekocht (quad core, 6g ram) die het met 7W prima doet als zuinige huisserver. En x86 natuurlijk
Zie bijvoorbeeld pricewatch: serie: NUC Kit

Je moet er zelf nog storage en ram bijkopen. Maar goed - voor een Pi moet je ook nog een behuizing, voeding en storage toevoegen.
Wat mij betreft is de RPi al jaren de machine voor de losse taken als het uitlezen van de slimme meter en de zonnepanelen. Voor domotica ben ik nog niet zo ver maar daar gaat juist 1 of misschien wel meer apparte RPi voor gebruikt worden.

Iedere RPi krijgt een eigen boot-medium en eigen instellingen maar de gegevensopslag gaat zo veel mogelijk naar de nas. Het liefst direct zonder dat het eerst op de RPi wordt opgeslagen zodat de RPi zo min mogelijk lokale disk schrijf acties heeft en dus langer heel blijft.

Ik gebruik de RPi zo veel mogelijk voor zo min mogelijk tegelijk: Zowel voor de slimme meter als voor de zonnepanelen heb ik een apparte RPi. Vooral omdat de slimme meter in de meterkast op de begane grond staat en de zonnepanelen op zolder worden uitgelezen. Domotica zal in de toekomst misschien ook wel door meer RPi-s worden gedaan.
Ik gebruik tegenwoordig een ESP8266 voor uitlezen van mijn P1 poort, kan je die Pi weer voor wat anders inzetten. Heb 2x een corrupte kaart gehad aangezien er best wel wat data werd gegenereerd door de P1 data. Deze ESP pompt data naar een 5 node Pi4 4GB K8s cluster met SSD (M2 USB3) die zowel mijn home automation als alle andere taken zoals Plex voor zijn rekening neemt.
Ik lever PI's voor kassa systemen om oa barcodescanners, bonprinters, weegschalen en klantdisplay aan te sturen.
Het zou voor zulke toepassingen interessant zijn, als het stroomverbruik nog meer omlaag gebracht zou kunnen worden, misschien richting de 1-2 W. Dus er moet niet alleen krachtigere hardware komen, maar ook zuinigere en dat hoeven niet dezelfde borden te zijn.

Heb je trouwens voor jouw toepassingen meer kracht nodig dan een Raspberry Pi Zero levert of is dat al meer dan genoeg?
In de meterkast bij de smartmeter hangt nog een RPi 1 of 2. op zolder hangt de RPi Zero, de versie met bluetooth en wifi, zodat ik geen kabels hoef te trekken.
Dat soort taken die jij noemt... die draaien toch ook al prima op de 4GB ( of misschien zelfs de 2GB) versie ? Zelfs als je een aantal dockers hebt draaien ?

[Reactie gewijzigd door GertJan2012 op 22 juli 2024 18:13]

Dat klopt, maar dit zijn voorbeelden. In totaal zijn het meer applicaties en kunnen het er meer worden. Met 8GB geheugen heb je als docker server de ruimte en ben je meer toekomst bestendig.
Zoals in het artikel staat kan alle 8 GB gebruikt worden, maar slechts 3GB per applicatie. Zie het voorbeeld van Chromium.
..maar slechts 3GB per applicatie.
Nee, per proces.
In Docker is dat behoorlijk vergelijkbaar. Omdat Docker geen goede support heeft voor init-processen per container heb je dus standaard maar één proces.

Geen groot probleem, overigens. Systemd is precies het soort lightweight init-proces wat je in een container wil hebben. Ik snap Docker wel dat ze geen 500 processen willen starten voordat de container draait, maar Systemd mist die overhead. (De klassieke SystemV init hang van scriptjes aan elkaar, die allemaal een eigen bash proces nodig hebben). Dus ik verwacht dat we in 2021 wel native Docker support in systemd gaan krijgen.
Het idee van docker is natuurlijk om je processen te verspreiden over meerdere dockers. Daarnaast is het draaien van meerdere processen niet zo lastig: https://docs.docker.com/c.../multi-service_container/
Dus eigenlijk is uw vraag geen vraag ... ;)
Min of meer, zocht meer bevestiging. :)
Meer Ram biedt voordelen voor:
  • Het werken met grote databases.
  • Multitasking
  • containers zoals Docker
  • Grote samenstellingen van C++ code
  • Browsen met vele tabbladen
  • Foto/video editing?
En het geeft nog meer nut aan 64bits systemen.
Maar dat geldt alleen als de CPU het ook aankan of mee groeit en daar zit de bottleneck bij de raspberry pi. Ik vermoed dat je heel weinig aan die 8 GB versie gaat hebben of het moet voor een specifiek doeleind zijn.
Maar dat geldt alleen als de CPU het ook aankan of mee groeit en daar zit de bottleneck bij de raspberry pi.
De CPU van de Pi 4 (Cortex A72-quadcore) is best wel netjes. Je moet hem alleen goed koelen. De standaard kastjes zonder extra koeling zijn verschrikkelijk. Je kan daarmee throttling verwachten. Neem je zoiets (met goede heatpads of koelpasta) dan wordt het al een stuk beter, en dat is passief gekoeld. Daar kan je nog wat fans bij doen voor verdere koeling.

Wat de Pi in het verleden beperkte was niet de CPU. Die van een 3 B(+) was al pittig. De 1 GB geheugen was lastiger om mee te werken. Met de Pi 4 was dat opgelost, en 8 GB is eindelijk op het niveau wat vandaag de dag een beetje minimaal is voor een moderne desktop (met bijvoorbeeld een browser met veel tabs open).

[Reactie gewijzigd door The Zep Man op 22 juli 2024 18:13]

Goed lezen aub, ik zeg dat die CPU te traag is om echt goed gebruik te kunnen maken icm die 8GB en je dus uitgezonderd bepaalde situaties eigenlijk niks aan die 8 GB gaat hebben. Jij begint een heel verhaal over koeling van de CPU en ik geloof best dat je daarmee de performance wat kan opkrikken maar dat is niet relevant voor dit verhaal.

En veel tabs open zetten in chrome, dat is meer relevant voor je werkstation en niet voor je pi die je toch meestal voor andere dingen inzet.
Maar de RPi 4 (zeker die met meer geheugen) wordt ook als desktopvervangers aangeprezen.
Plus meer geheugen is altijd handig als je grote projecten een beetje vlot wil compileren
Zal best dat ze 'm aanprijzen maar wie gebruikt dat ding daadwerkelijk als desktop vervanger? Ze prijzen ze ook aan dat die video en beeld bewerking kan maar kijk is naar wat voor pc's creators hebben staan, dat ga je toch niet op een Pi doen.
Zal best dat ze 'm aanprijzen maar wie gebruikt dat ding daadwerkelijk als desktop vervanger?
Ik.
Alles valt of staat met softwareondersteuning. Deze SoC's hebben buiten de standaard ARM cores ook VPU's, GPU's en NPU's aan boord die door middel van de juiste software veel taken kunnen offloaden van de ARM cores. Dat werkt helaas vaak met de eerste images van de fabrikant niet juist, maar volgens mij is dat bij Raspberry Pi OS wat beter geregeld.

En natuurlijk kan een Raspberry Pi op dit moment niet op tegen een wat zwaardere machine voor zaken als video- en beeldbewerking, maar dat wil niet zeggen dat dat bij toekomstige generaties nog steeds het geval zal zijn. Je gaat voor diezelfde toepassingen ook geen machines met een Intel Celeron of een Pentium Silver gebruiken, maar die zijn wel een stuk duurder dan zo'n Raspberry Pi.
Er zijn genoeg mensen die niet al te hoge eisen hebben en hun Raspberry Pi 4 als hun (enige) desktop inzetten. En daar is ook niets mis mee. Veel laptops komen tegenwoordig standaard nog steeds met 8 GB geheugen en dat is voor veel mensen meer dan genoeg.

De Raspberry Pi 5 zal heus wel weer een betere SoC krijgen, wanneer die uitkomt.
Een laptop heeft een x86 CPU en die heeft aanzienlijk meer power dan deze SoC. Dan nog ga je niet bijv. een absolute instap intel CPU combineren met ik zeg maar 64 GB geheugen, zelfs met VM's heeft dat op den duur weinig zin want dan zit je CPU continue tegen z'n platfond aan.

Ik zeg zeker niet dat die Rpi's slecht zijn alleen de 8 GB versie zou ik niet kopen want heeft geen meerwaarde. Wil je echt iets met zoveel geheugen koop dan wat anders of wacht op de Pi5 als die ooit komt.

[Reactie gewijzigd door Terrestrial op 22 juli 2024 18:13]

Gezien het aantal containers wat ik met 8 Gb kan draaien op één Pi i.p.v. twee heeft het voor mij wel nut. Iedereen heeft zijn eigen use case.
Anoniem: 332561 @The Zep Man28 mei 2020 12:54
Klopt! Ik heb hem ivm geluid zonder fans, wel met die heatsink case (kun je nog in verschillende kleuren kiezen ook), e.g. https://elektronicavoorjo...i/behuizing-raspberry-pi/. Bij gebruik voor mijn magic mirror project valt het reuze mee hoe heet hij wordt, die case werkt echt goed.
Daarbij hoor ik echter wel van een aantal mensen dat de default case toch echt te warm wordt.

[Reactie gewijzigd door Anoniem: 332561 op 22 juli 2024 18:13]

Dat was mijn eerste gedachte toen ik las dat de Pi nu ook een 8 GB versie kent. De processors zijn een stuk beter geworden, maar ze zijn nog echt, heel, heel traag.

Je loopt veel sneller uit je CPU dan uit RAM. Dus ik ben erg benieuwd naar een serieuze relevante toepassing van de 8 GB versie.
Zegt u nu dat een computer met meer geheugen meer taken aankan? :Y)
Iemand met meer geld op de bank sprak dat ooit tegen met de befaamde woorden: "640 kB should be enough for every machine".
Werkelijk? https://www.computerworld...gates-really-say-it-.html

edit: typo

[Reactie gewijzigd door Geim op 22 juli 2024 18:13]

Al *zou* hij dat gezegd hebben, het klopte destijds wel.
It probably was .....at that time.
But even so, Bill never said those words. :X
Allemaal zaken waar ik een Pi niet voor zou inzetten omdat toegang tot de data via USB of ethernet zou moeten ipv. local storage. Een willekeurige atom cpu met een sata SSD rent rondjes om je pi voor die use-cases.
Waarvoor zou u zo'n PI met 8GB dan net wél voor gebruiken?
Eenvoudige desktop PC voor kinderen? Minecraft erop en gaan. Dan kan 8gb wel handig zijn: kunnen ze ook chrome open hebben ;-)
Het model van raspberry gaat steeds verder verwateren...straks krijg je de 16gb voor 100 euro en de 32gb voor 125 euro bewijs van...
Laten ze eens proberen tot 50 euro dingen te blijven ontwikkelen.
Laten ze eens proberen tot 50 euro dingen te blijven ontwikkelen.
Dat doen ze ook. De 2 GB versie zit nu op de prijs waarvoor je vroeger de 1 GB versie kon kopen, wat onder de 50 EUR is. De 1 GB versie is daarmee uitgefaseerd/minder verkrijgbaar. Ook voor het lagere segment blijft men dus ontwikkelen.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 18:13]

Sterker nog, de focus ligt nog steeds bij de sub-50 EUR versies van de RPi; de versies met meer geheugen zijn gemaakt om de power-users tegemoet te komen. Het gros van de RPi gebruikers (de educatieve sector) kan volledig toe met 1/2GB
Dat is het mooie van vraag en aanbod; indien er meer vraag is naar devices onder de 50 euro zal de koers van Raspberry weer wijzigen.. :9
Verdomme, nog maar net een nieuwe gekocht met 4GB...
Ja en dat was blijkbaar genoeg voor jouw use-case, anders had je hem niet gehaald. Oftewel: die is toch nog steeds prima bruikbaar.

Use cases waarbij je echt 8GB nodig hebt, zijn vrij schaars.
Klopt, maar heb de 4GB gekocht om zo lang mogelijk "future proof" te zijn en dan is het toch lullig als er paar weken later een 8GB model uitkomt. En natuurlijk komen er steeds nieuwe en betere versies uit van zowat alles in technologieland, en als dat dan zes maanden, of meer, later is, ok, maar een paar weken is echt wel lullig ;-)
Maar de 4GB RPi4 is er dan ook al bijna een jaar en het was dus wachten op nieuwe ontwikkelingen. Nu kun je die $20 in een toekomstige RPi5 steken :)
En zodra je de 8 GB koopt, komt net de 16 GB versie uit....
Rumors waren er al sinds de introductie, dus ik heb 5x 4GB hier liggen omdat ik het wachten zat was.
vakantiegeld komt eraan en dan geef je die dikke 85 euro extra uit
Grappig dat de prijs van een Pi steeds meer omhoog gaat.
Ik snap dat het een keuze is om deze variant te kopen en dat keuze alleen maar fijn en positief is, maar afgezet tegen de initiële filosofie van de Pi vind ik het wel opvallend :).
Niet alleen dat de prijs omhoog gaat. Maar er moet nu ook voor goede koeling gezorgd worden, aangezien de chip richting de 90 C graden gaat als er stevig gebruik van wordt gemaakt . Met de oude versies waren een paar goedkope opplakbare koel elementjes voldoende. Mijn pi1 draait al sinds het begin als server 24/7. Ik denk eerlijk gezegd niet dat een pi4 dat zo veel jaren zou volhouden, aangezien hitte zeer slecht is voor electronische borden.

Een entry level nuc is voor mij nu interessanter dan een pi4. Omdat de prijs min of meer hetzelfde is.
Er zijn genoeg niet-NUC alternatieven, zoals de Odroid C2/C4/H2.
Nu dus een plakkoeler, en een fan. Gezien het verschil in performance tussen een RPi1b en een RPi4 niet zo gek (of het bordje op zijn kant zetten, en op convectie vertrouwen (Deden die oude DEC Alpha machines ook))
De basis versie is nog steeds goedkoop, en zal voor de meesten voldoen. Ik heb zelf ook de 4GB versie, gewoon omdat het kan. Maar met de 3 tools die ik draai, gebruik ik maar 16% van mijn memory. Had dus ook met een 1GB versie de boel kunnen draaien.
Yep. Precies mijn gedachte. Het hele idee achter de Pi verwatert zo wel heel erg. Niks meer "computing for all".

Ook vraag ik me echt af hoeveel use cases er nou zijn voor 8 GB geheugen? De verhouding geheugen / processing-power loopt volgens mij beetje scheef.

Ik draai hier Domoticz en PiHole nog op een eerste generatie Pi met 512MB aan boord. Video mem op 16MB gezet (want terminal only) en dan gata het prima. Zelfs nog ruimte voor 2 ramdisks voor tijdelijke logging.
Anoniem: 718943 @sys6473828 mei 2020 12:56
Zo lang ze het onderste segment nog steeds voor dezelfde prijs aan blijven bieden gaat dat zeker nog wel op. Alleen heb je nu als consument nu ook de mogelijkheid meer geld uit te geven voor hogere specs.
Niets mis mee.

Voor mijn embedded projecten kan ik nog steeds de onderste laag gebruiken, en mensen die een fullblown desktop met chique browser willen draaien kunnen kiezen voor dikkere CPU met een bak geheugen.
Meer RAM biedt ook meer mogelijkheden voor een RAMDisk. Heb er weinig kennis van maar lijkt me dat je daarmee eea flink kunt versnellen.
Ramdisks zijn in het algemeen onzin. Die vertragen meer dan dan ze versnellen. Een goed geheugenbeheer zorgt er wel voor dat de benodigde data etc gewoon in het geheugen zit.
Het is wel handig voor temp logs die anders je SD kaart om zeep helpen

edit; denk ook aan on the fly video encoding naar bijvoorbeeld HLS, die files moeten ook ergens tijdelijk worden opgeslagen

[Reactie gewijzigd door jeroenk13 op 22 juli 2024 18:13]

Waarom zou je dan niet de logs gewoon in het geheugen houden als je ze bij een reboot toch weggooit? Beetje overbodige complexiteit om daar helemaal een filesystem en een ramdisk voor te maken. Gewoon niet op disk schrijven maar in geheugen houden.
omdat je daar geen controle over hebt bij alle softwarepakketten ? En als je ze in het geheugen houdt dan blijft de stelling van @glatuin nog steeds staan, want Meer RAM biedt ook meer mogelijkheden op die manier.
Heeft linux niet een volatile iets in `/dev` wat hiervoor geschikt is?
Ja, en als het programma stopt (crashed), zijn de logs ook weg. Lekker zinvol...
Dan moet het maar niet crashen. Een crashlog is voor een gebruiker sowieso niet zinvol, alleen voor een developer. Als gebruiker heb je alleen wat vaan usage-achtige logs.
Gebruiker naar ontwikkelaar: Het programma crashed.
Ontwikkelaar naar gebruiker: Kan je me de logs sturen?

Maar goed, in jouw optiek is een ramdisk niet zinnig, en ik voel niet de behoefte om je mening te veranderen, dus ik laat het hier maar bij
Mijn AdGuard Home logs gaan bij mij inderdaad in een ram-disk.
remote syslog...
In het algemeen heb je wel gelijk maar als ik een RPi kan inrichten op een 1GB geheugen en een 4 GB sdkaart dan kan ik dat omwerken op een RPi met 8 GB waarbij alles in het geheugen zit.

Opstarten is dan de sd-kaart opslurpen en draaien. Alleen de schrijf acties zouden dan eventueel ergens heen geschreven moeten worden als je ze op prijs stelt.

Detail: nu moet je niet de pagefile/swapspace in de ramdisk zetten. Ik heb ontwerpen gezien....
Zou je met 8 gig prima Windows arm kunnen draaien?
Ze zijn al bezig om Windows 10 op de rpi 4 te laten draaien. Grootste probleem is dat men niet alle cores aan degang krijgt onder Windows en maar 1gb geheugen kan adresseren.
Dus eigenlijk onbruikbaar.

https://www.windowslatest...-on-raspberry-pi-4-and-3/

[Reactie gewijzigd door DutchBee op 22 juli 2024 18:13]

Dat project zijn ze al zo lang mee bezig en nut en noodzaak lijken zo laag dat de kans dat dit ooit iets gaat worden echt heel klein zijn.
Ik denk niet dat de 4GB geheugen de grootste bottleneck is bij Windows ;) 8GB gaat dan weinig helpen ben ik bang.
"Omdat de nieuwe geheugenpackage een iets hogere piekspanning heeft"

De piekstroom is hoger, staat in het gelinkte artikel.

Op dit item kan niet meer gereageerd worden.