Raspberry Pi Compute Module 4 ondersteunt waarschijnlijk nvme-opslag

De Raspberry Pi Compute Module 4 gaat nvme-opslag ondersteunen, als het aan de makers ligt. Ook een potentiële Raspberry Pi 4a van nvme-ondersteuning voorzien, is volgens Eben Upton van de Raspberry Pi Foundation een uitdaging.

De Raspberry Pi Compute Module 4 moet binnen een jaar verschijnen en gaat dan 'waarschijnlijk tot op zekere hoogte' nvme ondersteunen, meldt Eben Upton, mede-oprichter van de Raspberry Pi Foundation tijdens de Pi Cast van Tom's Hardware. De Raspberry 4 heeft een pci-e-interface maar gebruikt deze voor de usb 3.0-controller. Op de Compute Module, die op de Raspberry Pi 4 gebaseerd wordt, komt pci-e via de connector aan de rand beschikbaar en krijgt dan dus waarschijnlijk nvme-ondersteuning.

De Compute Module 4 is een op internet-of-things gerichte module die waarschijnlijk over dezelfde 64bits BCM2711-quadcore van Broadcom als de Raspberry Pi 4 Model B gaat beschikken. Upton hint op de komst van een Raspberry Pi Model A waarbij nvme ook overwogen wordt, maar het laag houden van de prijs zou dan een uitdaging zijn.

"Dat brengt kosten met zich mee, zowel wat silicium als de connector betreft, want de aansluiting is niet gratis. Ook moet je ruimte op het bord voor de connectors hebben. Als je naar de Raspberry Pi kijkt is er duidelijk niet veel ruimte voor een m2-slot." Volgens Upton zou het hoe dan ook een uitdaging zijn om de prijs van een 4A in lijn met die van de 3A+ te houden en zouden bij een iets hogere prijs mensen al voor een 4B kiezen.

Compute Module CM3+
Raspberry Pi Compute Module C3+ 32GB

Door Olaf van Miltenburg

Nieuwscoördinator

16-07-2020 • 19:44

87

Submitter: hiddit

Reacties (87)

87
87
51
4
0
30
Wijzig sortering
Ik ken niet veel van de raspberry zelf, maar is deze snel genoeg om profijt te hebben van nvme snelheden?
Of mis ik iets hier?
Grootste voordeel is dat je niet meer afhankelijk bent van SDkaarten. Die nog wel eens kapot willen gaan door de schrijfacties die erop worden gedaan.
Of door het abrupt power cyclen, zijn ze ontzettend gevoelig voor.
ik zet de mijne al bijna 2 jaar bijna elke dag gewoon uit door de stekker uit het stopcontact te trekken voordat ik ga slapen. Dus nu al zo’n 700x lomp zonder shutdown commando het ding misbruikt en deze is nog steeds prima... knock on wood. Ik heb wel alle logfiles zoveel mogelijk uitgeschakeld en de nodige schrijven naar ram ipv de sd-kaart. Pi fungeert als pi-hole en ‘s weekends via Kodi filmpje meepikken.
Dat is best bijzonder :+ zelf al vele kaartjes zien sneuvelen. Goedkope én dure kaartjes. (Tegenwoordig staan de pi's bij mij 24/7 aan, de kosten die het mee brengt (of bespaart om uit te zetten) weegt niet op tegen de moeite om ze aan en uit te zetten.
Zo bijzonder is dat niet... Als je de boot sector read only laat en het systeem zoveel als mogelijk read only instelt hoeft dit niet persee voor problemen te zorgen...
Je kunt ook prima het systeem Read only instelllen en dan heb je er bijna geen last van zoals vj_slof al aangeeft!
Het probleem is dat "de" boot sector niet bestaat op een SD kaart met wear leveling. Juist omdat die fysieke sector niet gebruikt wordt is het een aantrekkelijke sector voor het wear leveling algoritme.
Same here. Moet ik he-le-maal naar de kelder lopen.
ssh raspi
Sudo shutdown.
Je kan zelfs een ssh cliënt op je gsm gebruiken
Maar dan moet 'ie weer aan, en naar mijn weten zit de Ethernet-adapter op USB op een RPi 3 dus die ondersteunt geen WOL. Gaat m'n stappenteller alsnog aan 't werk. ;-)

Als iemand weet hoe je dat werkend krijgt hou ik me aanbevolen.
Via SSH sudo reboot
Bij mij valt het nog mee, meterkast, woonkamer en kantoor.
En de speciale Endurance kaartjes dan, bedoeld voor dashcams/beveiligingscameras?

[Reactie gewijzigd door Gamebuster op 23 juli 2024 10:06]

Interessant! Weet je toevallig welk merk/type kaartje je daar in hebt zitten?
Heel bezonder, bij mij is de sd kaart al naar twee keer corrupt atthans het file system
Hier ook een Raspberri Pi als Plex client achter de tv. Zodra de tv uitgaat (meerdere keren per dag) krijgt de Pi ook een harde poweroff. Nog nooit een issue mee gehad.
Ja daar zijn ze ook best allergisch voor :D

Zelfs de kleine kaartjes zouden erg prettig zijn maar ze worden er wel heel warm door.
Of under voltage, sinds ik de bijbehorende adapters gebruik heb ik nergens meer last van (2-3 jaar).
Helaas hebben SSD's ook een grote kans kapot te gaan door stroomuitval, dus dit zal de reden niet zijn.
Na drie of vier defecte kaarten heb ik twee jaar geleden de boel omgezet naar NFS via mijn NAS. Nooit meer defecte kaartjes en backup is eenvoudig te regenen via mijn NAS.
Kan de pi booten vanaf een nfs disk?
Er is in recente firmware de mogelijkheid voor TFTP boot, maar dat heb ik nog nooit gebruikt. Mijn Pi3B+ en Pi4's hebben Ubuntu's /boot/firmware op SD kaart staan (read-only), en via cmdline.txt wordt de root disk over NFS binnen gehaald. Heb een stapel 256MB SD kaartjes daarvoor gekocht, nog geen uitval gehad...

De Pi3B+ hikt in die configuratie nog wel eens onder load, maar doet het puik bij licht gebruik (geen idee of er iets oververhit, of dat de USB bus vol loopt, of nog iets anders). De Pi4 is rock-solid over NFS.
Of een USB SSD aansluiten en dan ben je van dit soort problemen af. EEPROM Firmware die dit ondersteund zit inmiddels al een maandje in de Stable branch voor de Pi 4. Hij heeft zelfs niet eens een SD-kaart meer nodig voor de bootfiles.

Verder kan je een een op een kloon van je SD-Kaart op een SSD zetten en vervolgens de partitie uitbreiden . Dit werkte bij mij probleemloos met de SSD migratie :) . Domoticz draait al een tijd super stabiel.
Grootste voordeel lijkt mij vooral de hogere opslagcapaciteit en de lagere kostprijs ervan. Een microsdkaart van 1TB kost meer dan 300 euro. Voor ongeveer een derde daarvan heb je al nvme-opslag. En je hebt dan ook nog nvme beschikbaar met nog meer capaciteit.

Er zijn toepassingen te bedenken waar dit een meerwaarde kan zijn. Ik denk bv. aan beveiligingscamera's.
Duidelijk dat ik dus iets miste.
Bedankt.
dat is het zelfde als stellen dat het voordeel van auto tegenover fietsen is dat je minder vaak een lekke band hebt...

het zou naar gereden kilometers best waar kunnen zijn - maar betere (gewapende) banden lossen het probleem ook op daar hoef je geen auto voor te kopen.

het zelfde gaat een beetje op met iets als UFS op de Pi, het is geen nvme maar voor zijn taak,
veiligere en snellere opslag dan sdkaartjes, voldoet het natuurlijk prima.

Zijn punt is dus zekere valide: de pi gaat veel minder 'nut' hebben van het snelstmogelijke nvme opslag dan van zaken als gbit lan of wif of een pci-e hub met meerdere perifirals denk je eens in wat je zou kunnen doen met een rasberry pi waar én gbit lan, én een pci-e sata (hardware) raid controller op zou zitten. een rasberry pi (en al zijn custom software support) met een hardwarematige raid5/6/jbod chip dual gbit lan en een 64gb ufs chip maakt zo'n beetje Dé diy-nas oplossing van dit decenium.

dan maakt het nog niet eens uit als het maar een oud sata300 chipje was. zolang het maar geen fakeraid oid is...
Tot nu toe was raspberry altijd afhankelijk van SD kaarten.

Nvme brengt veel voordelen ten opzichte van SD kaarten. Wat mij betreft met name access times en dat het opslag niet corrupt kan raken. Daarnaast is de doorvoersnelheid een plus maar dat is bij een raspberry over het algemeen minder van belang
Tot nu toe was raspberry altijd afhankelijk van SD kaarten.
Tegenwoordig kan je ook van SSD opstarten via USB.
Heb je dan niet alsnog nog steeds een SD kaart nodig? Dat was iig het geval toen ik ermee voor het laatst heb gewerkt. Maar alsnog zit je met access times met USB.
NOTE: Alleen voor de Pi 4
Nee, ook de Raspberry Pi 3 B+ ondersteunt USB boot, zonder SD kaart.
Mijn RPi3 (kodi's) werken allemaal dmv usb boot, gaat prima.
Ook Raspbian werkt goed, maar sommige imagas zijn hardcodes oid om naar de sdkaart te 'zoeken'
Die starten dan niet op helaas ( o.a. Eyemotion wil persé een sdcard )
Bedoel je MotionEye?
Ja, de Cameraserver.

Werkt verder prima, alleen jammer dat het niet vanaf de USB wil booten
Als ie perse SD wilt, dan zou ik 'm sws niet zo snel gebruiken op een Pi, maar dan in Docker op een normale machine.
Die stap was ik al aan het onderzoeken ook, maar vooralsnog is het een testopstelling met een tweetal cheapo webcams.

Maar nu al indrukwekkend in mogelijkheden
Klopt, de initiele boot gaat via de SD waarna hij de rest boot via USB. Je verwijst dus naar de andere opslag in je bootfile op de SD kaart.
Hopp dat er snel native USB in zit, dus als er geen SD kaart wordt gedetecteerd dat hij USB probeert.


Blijkbaar is de firmware aangepast en kun je rechtstreeks van USB booten.

[Reactie gewijzigd door ViperXL op 23 juli 2024 10:06]

Heb je dan niet alsnog nog steeds een SD kaart nodig? Dat was iig het geval toen ik ermee voor het laatst heb gewerkt. Maar alsnog zit je met access times met USB.
maar zelfs toen dat nog wel nodig was ...

ik heb een pi4 via een bootloader-sdkaartje van USB laten boten Gewoon een kingston usb3 stickje erin en de bootloader (hoe heette dat toch) - nee niet noobs maar iets soortgelijks... en alle problemen die ik met sdkaarten had waren voorbij dat kwam natuurlijk omdat een er op de sdkaart maar 2 dingen stonden.
1 de bootloader 2 de kernel. de eerste hoefde je helemaal niet te updaten en de kernel maar zo weinig dat dat zelfs voor een sdkaart weinig uitmaakte.

uiteindelijk heb ik hem weggedaan omdat er heel veel zaken niet goed werden ondersteunt.

1: massa opslag om er een leuk servertje/nasje van te maken was niet te doen.
2: als je nextcloud erop draait werkt de nextcloud-office-hub niet want die werkt alleen op x86.
3: als je een aan-uitknop wilt EN een CPU-fan moet je gaan solderen.
4: als je een cpu-fan wilt past je schreen-hat niet meer en heb je dus geen status-schermpje.

5: alles op een proxmox/unraid of soortgelijke docker-host laten draaien werkt net wat sneller en verbruikt maar een 'klein' beetje meer stroom. (op een quadcore itx-build)
Dan heb je de stabiliteit van een SSD, en de compactheid van de SD. Elk USB apparaat maakt de formfactor 2x groter. NVMe zit er plat op. Een PI 5 met NVMe zou voor mij dan ook een insta-buy zijn.
Imho is het voordeel van de Raspberry Pi dat het relatief goedkoop is, maar zoals ze ernaar hinten zal NVME redelijk wat extra gaan kosten...
Ik heb geen idee wat een NVMe bus kost, wellicht dat iemand hier een lichtje op kan werpen?
Evenveel als een x2 of x4 PCIe bus? Sorry :)
Kunnen we dan ook een videokaart aansluiten op de PCIe bus? :P
Zou niet weten waarom niet. Er zijn ook USB en Wifi adapters voor m.2 beschikbaar. Uiteindelijk is m.2 alleen de fysieke interface (werkt natuurlijk niet met een m.2 die alleen SATA doet). Of de software ook mee wil werken is vraag 2 natuurlijk.
nvme, 4 of meer cores, 8GB Ram en een goede gpu die in staat is op h265 te transcoden.
dat zou mede door de goede ontwikkeling binnen het het ecosysteem een aankoop voor mij worden. de prijs neem ik dan voor lief.
Anoniem: 718943 @JBVisual16 juli 2020 23:11
En dan een turing pi met 7 van die compute modules.
[...]

Tegenwoordig kan je ook van SSD opstarten via USB.
Klopt, alleen handelt de CPU het verkeer af waardoor je prestaties moet inleveren.
Het werkt, maar is nog steeds vrij traag omdat je niet alle instructies kan aanspreken en maar een queue depth van 1 hebt.

Ik zou graag native nvme support zien want het gaat de boardjes veel sneller maken.
Maar komt het corrupt raken van storage wel hoofdzakelijk door de SD kaart zelf?
En niet door de gebruikers die de USB stroomkabel eruit trekken zonder netjes af te sluiten?
Komt deels door de gelimiteerde hoeveelheid schrijfacties van flash, samen met wat je al noemt het al dan wel of niet netjes afsluiten. Een (micro)SD kaart heeft daar (in mijn ervaring) veel meer moeite mee en gaat daardoor, zeker in combinatie met de RPi, sneller stuk.
Hoezo kan het opslag dan niet corrupt raken? SSD is er misschien iets minder gevoelig voor, maar ik zou een RPi nog steeds niet spanningsloos maken zonder netjes af te sluiten.
Die raakt dan misschien wel corrupt, maar ik heb al vaak genoeg meegemaakt dat een SD kaart fysiek kapot gaat wanneer deze voor een OS gebruikt wordt. Dat zal bij een SSD niet zo makkelijk gebeuren.
Het hoeft niet altijd te gaan over snelheid. Denk aan betrouwbaarheid, beschikbaarheid, prijs, etc. De PI4 is zo snel en het ecosysteem zo gevorderd dat je een PI4 makkelijk kan gebruiken als een desktop vervanger als je allen lichte dingen doet. Een SD kaartje heeft daarbij wel meerdere ongewenste eigenschappen, voornamelijk dat de markt overspoeld is met troep SD kaartjes.

Een M.2 drive als optie is een hele goede oplossing. Als je dan toch bezig bent waarom niet M.2 NvME? M.2 SATA modules zijn sowieso bijna niet te verkrijgen en in veel gevallen even duur als hun NvME neefjes. Het is de ene of de andere connector, dan maar die ene die wel toekomst bestendig is.
voornamelijk dat de markt overspoeld is met troep SD kaartjes.
Kwestie van tijd tot de markt overspoeld wordt door slechte M2 NVME ssd's...
Ik zou zeggen aan de onderkant ruimte zat. Prijs? Ik koop hem toch wel net als alle andere :)
je zult toch wel een aantal sporen over 1 van de lagen van de pcb moeten gaan trekken en het plaatsen icm het leggen van de sporen zal wel de uitdaging zijn denk ik
Dan wordt de module dikker, ik weet niet of dat problemen oplevert?
Kan ik er dan eindelijk een NAS van maken?
Daarvoor is USB3 al snel genoeg. Ik zou liever 10Gbit ethernet hebben on board - om snel genoeg te kunnen zijn. En zo verschuiven onze eissen telkenmale.
elke subset van >gbit is al goed, maar ik vraag me oprecht af hoeveel bandbreedte er nu ECHT haalbaar is.

stel dat je eer een pci-e hub op prikt met m.2 (liever usf want goekoper). met een paar sata poorten aan een hardware raid5 chip is er dan nog wel ruimte op de bus voor 10gbit of zelfs 1gbit lan. of mag de rest dan weer allemaal over de USB2 bus... want dan schiet je er nog weinig mee op.
Nvme gaat ook corrupt als je op het verkeerde moment de stekker er uit trekt. Voordeel van nvme is vooral de snelheid aangezien die meerdere flashchips tegelijk aan kan spreken via de controller. Het voordeel van nvme is ook nog dat op de controllers de wearleveling beter geregeld is, sd karten doen dat dacht ik niet, als je dan met een ramdrive steeds in de zelfde sectoren gaat krassen is het snel afgelopen
SD kaarten horen ook aan wear leveling te doen, maar het is volgens mij wel veel meer gelimiteerd dan SSD. Ik heb het eens uit proberen te zoeken, maar je komt al snel in een doolhof terecht. Zeer weinig informatie, en de informatie die er is is niet altijd even betrouwbaar. Het zal wel wat minder merk specifiek zijn dan bij een SSD waar elke controller het weer iets anders doet.

[Reactie gewijzigd door uiltje op 23 juli 2024 10:06]

Een SD kaart is flash geheugen met een SD connector; een SSD is flash geheugen met een SATA of NVMe connector. Het is niet de connector die sneuvelt bij een power-off, het is het flash zelf. Dus daar zit het verschil niet.
Zou het echt zou moeilijk zijn om een condensator parallel te plaatsen op de stroompunten waardoor je een kleine energiebuffer hebt van een paar seconden. Dat zou voldoende moeten zijn voor de controller om netjes af te sluiten..
Die is volgens mij ook wel aanwezig bij SSD's.
Sterker nog, flash heeft 250 milliseconden nodig. Dat is echt niet veel. Er zijn ook "industrial grade" SD kaartjes, bijvoorbeeld de Sandisk Industrial, die zo'n condensator al hebben. Wel een andere prijsklasse als de MediaMarkt.
Ja, dit was specifiek voor de wear leveling, niet zo specifiek voor de power off problematiek. Als de flash sneuveld ben je natuurlijk in beide gevallen gaar. Heel vaak is de flash wel nog leesbaar, dus dan kan een controller deze afsluiten voor write acties. Moet ie dat wel kunnen natuurlijk.
de meeste fatsoenlijke ssd's hebben daarentegen een powerlos protectie dvm een capacitor die heel even stroom blijft geven nadat de power wegvalt zo kan de schijf zijn transactie snel nog even afmaken.

met sdkaartjes heb je doorgaans niet eens surge-protection dus zelfs de kleinst mogelijke piek blaast al een gat in je geheugen.
Ik denk dat niet alleen het laag houden van de prijzen een uitdaging zal zijn, maar ook die van de temperaturen, die zijn nu al aan de hoge kant.
Een Pi 4A met NVMe zou ik minder interessant vinden dan een 4B met NVMe... Zoiets heb je juist nodig voor zwaar gebruik en dan komen de ethernet en extra USB's toch zeer goed uit de bus lijkt me.

Misschien kan de display aansluiting weggelaten worden en in plaats daarvan een flatcable connector naar een apart adapterboard voor de NVMe? Een NVMe module is toch al gauw groter dan wat op een pi past. En de meeste mensen die displays gebruiken, doen dit toch vanaf HDMI omdat het officiele display vrij erbarmelijk van kwaliteit is (geen IPS, lage resolutie), en bovendien erg duur voor de specs.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 10:06]

Wat waarschijnlijk de problematiek is, is dat de Broadcom-SoC slechts enkele PCI-E-lanes heeft, waarop je een enkel apparaat kunt aansluiten. Door er een USB-controller op aan te sluiten, kun je meerdere aansluitmogelijkheden voor allerhande apparatuur realiseren: Het verwijderen van de USB-controller op model B is waarschijnlijk geen optie.

Op de compute-module gaan ze geen USB-poorten realiseren, hebben ze dus geen USB-controller nodig en blijven de PCI-E-lanes beschikbaar. Ze maken ze dan ook beschikbaar op de aansluiting en met de juiste verloop kun je dan een M.2 voor NVMe realiseren. Dat is echter geheel aan de gebruiker, die zal net zo goed kunnen besluiten er wederom een USB-controller mee te verbinden.

Technisch zou je denken "PCI-E-switch!", maar dat is waarschijnlijk economisch geen haalbare kaart.
er bestaan naast USB3 wel andere pci-e based hubs. maar in zekere zin heb je gelijk pci-e 3.2 is bijna eve goed als native pci-e
Waarom is er eigenlijk nooit een versie van de Rpi geweest met eMMC geheugen? De beaglebone heeft al jaren 4GB eMMC en een SD card interface, het Seeed NP.I i.MX6 bord heeft 8GB eMMC en SD (maar dan tragere SoC) en kost 45€.

Verder vraag ik met af waar men de grens legt met IoT gezien die dingen steeds krachtiger maar niet noodzakelijk energiezuinig zijn.
De compute module heeft wel (optioneel) eMMC... Waarom het op de gewone Pi nooit gezeten heeft, weet ik ook niet. Maar eMMC is over het algemeen niet zoveel betrouwbaarder als een SD kaart (want eigenlijk is het gewoon een SD kaart + controller op een chip), en die kan je tenminste nog vervangen.
voordeel van emmc is toch wel 3 dingen,

1: je kunt van fabriek af: een fatsoenlijk stukje slc op solderen
2: je kunt er een powerloss-cap bijplaatsen zodat je die sd-card problemen niet hebt.
3: het is allemaal niet zo fragiel meer omdat het vastgesoldeerd is en je kunt er voor de leuk zelfs nog een heatsink op plakken. dan is ie NOG beter beschermt.
Leuk, maar van mij hoeft het niet. Ik gebruik zelf nog vaak genoeg mij Pi, maar ben tevreden met de huidige snelheden. Daarnaast moet je die nvme kaarten ook nog eens verticaal erin duwen en wordt je Pi dus meteen een stuk hoger en groter. Daarnaast zijn de nvme kaarten net iets duurder dan de goede kwaliteit SD kaarten en dan wordt de Pi ook nog eens net iets duurder vanwege de nieuwe connector. Misschien leuk voor anderen dus, maar ik zie mezelf hier geen gebruik van maken in de nabije toekomst.
Mischien een beperkte hoeveelheid aan SSD/eMMC/NVMe geheugen (4GB of meer) onboard op een duurdere versie van een RaspBerry Pi 4 ? Zelfs met 1 PCIe lane (2.5 Gbps) zou dit al een stuk sneller en betrouwbaarder moeten zijn dan SD kaarten.
eMMC is relatief eenvoudig. Dat is gewoon een vastgesoldeerde versie van een SD kaartje. Dat hoeft niet duur te zijn.
Heb je dan niet ook dezelfde nadelen van een sd-kaart (corrupt raken)?
Dat corrupt raken is meestal door (ongevraagde) powerloss tijdens activiteit. Kans daarop is kleiner bij eMMC. Of tot op heden toch nog nooit corrupt eMMC gehad op m'n beaglebone's maar een collega wel al meerdere rPi's SD moeten herflashen... (niet dat twee gevallen genoeg is voor conclusies...)
waarom is dit een logische stap? ipv SATA?

Op dit item kan niet meer gereageerd worden.