Sorry, aber das ist dann so ein bisschen mein Thema... Nicht das mit dem Zocken, aber das der Anbindung von externen Grafikkarten. Um es kurz zu fassen: Es ist kompletter Müll. Klar kann man eine externe Grafikkarte auch mit Lautsprecherkabeln über ein Breadboard mit Jumper-Kabeln an einen Arduino, ESP32 oder Raspi verdrahten, und das wird in der Regel auch funktionieren. Wer aber einmal ein kleines 240x240 Display angesteuert hat und weiß, wie langsam das alles ist, weiß deshalb auch, dass eine Grafikkarte mit solch einer Leistung "von außen" ansteuern zu wollen, Rotze ist. Darum sind auch die Jetson Orin Module von nVidia Schrott, wenn man es etwas ernster nimmt mit dem Thema KI: Zum einen sind sie verglichen mit den handelsüblichen Grafikkarten mit besserer Leistung völlig überteuert, und jetzt kommt der Punkt: Kein Raspi kann auch mit noch so viel Trickserei die Datenmenge schaufeln wie ein billiges Motherboard mit einer billigen CPU in einem billigen Gehäuse. Und da reden wir nicht von "nicht einmal die Hälfte", da reden wir von "nicht einmal 1/100". Wer solche Experimente macht mit der Begründung "Weil ich es kann": Cool! Aber mit auch nur irgendeinem brauchbaren Zweck hat das sicher nichts zu tun, besonders nicht bei der Rechnung "TOPS/€".
Welche Datenübertragungsrate braucht z.b. Llama von der CPU zur GPU? Würde es auf dem Pi5 mit GPU und Cuda laufen?
Carsten P. schrieb: > Klar kann man eine externe Grafikkarte auch mit Lautsprecherkabeln über > ein Breadboard mit Jumper-Kabeln an einen Arduino, ESP32 oder Raspi > verdrahten, und das wird in der Regel auch funktionieren. Du weißt, daß neuere Raspberry-Pi-Modelle PCIe sprechen? Zwar nur mit einer Lane, aber immerhin. Aber hey, wenn das "Dein Thema" ist, dann behalt's halt.
Harald K. schrieb: > Du weißt, daß neuere Raspberry-Pi-Modelle PCIe sprechen? Zwar nur mit > einer Lane, aber immerhin. Der OP meint wohl eher, daß mit solchen Sachen, wie generell mit dem Design des Raspberry PI 5, das Grundkonzept des Raspberry PI überdehnt wird. Das sehe ich auch so. Beitrag "Arduino-Sensorplatine, Bode 500, Raspberry Pi mit Grafikkarte uvam"
Wer schreibt vor, was das "Grundkonzept" des Raspberry Pi ist? Das Ding hat 'ne PCIe-Schnittstelle, also kann man da jedes PCIe-Device anschließen und ansteuern, das sich mit einer Lane betreiben lässt und für das man einen Treiber zusammengeklöppelt bekommt. Fändest Du es besser, wenn der keine PCIe-Schnittstelle hätte, und man immer noch darauf angewiesen wäre, von instabilen SD-Karten zu booten? War Dir auch schon die USB3.x-Unterstützung zu viel?
Harald K. schrieb: > Wer schreibt vor, was das "Grundkonzept" des Raspberry Pi ist? Niemand. Aber es ging wohl vor langer Zeit mal darum, einen kleinen, preiswerten, halbwegs leistungsfähigen Einplatinencomputer zu bauen, der den viellfältigen Einstieg in das Thema Computer und Programmieren ermöglicht. Nicht einen aktuellen PC im Westentaschenformat zu ersetzen. > Das Ding hat 'ne PCIe-Schnittstelle, also kann man da jedes PCIe-Device > anschließen und ansteuern, das sich mit einer Lane betreiben lässt und > für das man einen Treiber zusammengeklöppelt bekommt. Aber ist das noch sinnvoll? Wäre sowas an einem AVR oder auch STM32 auch sinnvoll? > Fändest Du es besser, wenn der keine PCIe-Schnittstelle hätte, und man > immer noch darauf angewiesen wäre, von instabilen SD-Karten zu booten? Die sind nicht so instabil wie oft behauptet wird. Wo soll die Reise hingehen? Raspberry Pi 10 auf dem gleichen Niveau wie ein fetter Desktop PC, Raspi 11 dann Mainframe? > War Dir auch schon die USB3.x-Unterstützung zu viel? Nochmal. Jedes Konzept hat einen sinnvollen Rahmen, der nicht beliebig erweiterbar ist. Ein 8 Bit Mikrocontroller mit 1GB RAM ist es auch nicht! Vor allem weil hier wie so oft nur das gemacht wird, was schon seit Langem fast immer gemacht wird. Einfach die Hardware mordsmäßig aufbohren, kostet ja fast nix. Brute Force. Das löst die meisten Probleme eher nicht bzw. kleistert nur die Unfähigkeit und Unwillikeit der Software zu. Ja mei, wenn's scheeeeee macht! Mein Ding isses nicht. Reine Materialschlacht mit wenig Pepp. Das Bloatwareproblem bleibt bestehen, kann und will keiner lösen.
Falk B. schrieb: > Aber es ging wohl vor langer Zeit mal darum, einen kleinen, > preiswerten, halbwegs leistungsfähigen Einplatinencomputer zu bauen Ja, darum ging es mal. Falk B. schrieb: > Aber ist das noch sinnvoll? Wäre sowas an einem AVR oder auch STM32 auch > sinnvoll? Warum sollte es das nicht sein? Falk B. schrieb: > Die sind nicht so instabil wie oft behauptet wird. Die Foren sind voll von Leuten, die damit Probleme haben. Man kann natürlich meinen, daß die sich einfach nur falsch verhalten, aber das machts auch nicht besser. Falk B. schrieb: > Nochmal. Jedes Konzept hat einen sinnvollen Rahmen, der nicht beliebig > erweiterbar ist. Schreibt wer vor? > Ein 8 Bit Mikrocontroller mit 1GB RAM ist es auch > nicht! Schönes Extrembeispiel. Aber mehr als die "natürlichen" 64 kB RAM darf es schon geben, oder? Niemand zwingt Dich, an der PCIe-Schnittstelle eines Raspberry Pi auch nur irgendwas anzuschließen. Beim Rest Deines Rants bist Du irgendwohin abgebogen, keine Ahnung, wohin. Allgemeine Unzufriedenheit? Mich ärgert ja die um sich greifende Verblödung auch, aber die mache ich jetzt nicht daran fest, daß jemand eine PCIe-Graphikkarte an einem PC angeschlossen hat, auf dem mit Linux auch ein Betriebssystem läuft, das mit PCIe-Graphikkarten umgehen kann. Ein Raspberry Pi ist kein Microcontroller* und war auch noch nie einer. Und warum soll man auf einem ARM, der mit ausreichend Arbeitsspeicher und Performance daherkommt, kein Linux laufen lassen? *) mit Ausnahme des idiotisch benannten "Raspberry Pi Pico", dem RP2040 & Co.
Harald K. schrieb: >> Aber ist das noch sinnvoll? Wäre sowas an einem AVR oder auch STM32 auch >> sinnvoll? > > Warum sollte es das nicht sein? Weil man auch keinen 40t Tieflader an ein Auto hängt! > Falk B. schrieb: >> Die sind nicht so instabil wie oft behauptet wird. > > Die Foren sind voll von Leuten, die damit Probleme haben. Die Welt ist voll mit Leuten, die nicht geradeaus laufen können. > Falk B. schrieb: >> Nochmal. Jedes Konzept hat einen sinnvollen Rahmen, der nicht beliebig >> erweiterbar ist. > > Schreibt wer vor? Keiner. Aber man könnte das feststellen. Immer mehr irgendwo draufpacken ist irgendwann mal sinnlos bis kontraproduktiv. Aber jetzt kommt betmmt gleich "Wer schreibt das vor?" ;-) >> Ein 8 Bit Mikrocontroller mit 1GB RAM ist es auch >> nicht! > > Schönes Extrembeispiel. Aber mehr als die "natürlichen" 64 kB RAM darf > es schon geben, oder? Waren das nicht 640kB? > Niemand zwingt Dich, an der PCIe-Schnittstelle eines Raspberry Pi auch > nur irgendwas anzuschließen. > > Beim Rest Deines Rants bist Du irgendwohin abgebogen, keine Ahnung, > wohin. Allgemeine Unzufriedenheit? Mich ärgert ja die um sich greifende > Verblödung auch, aber die mache ich jetzt nicht daran fest, daß jemand > eine PCIe-Graphikkarte an einem PC angeschlossen hat, auf dem mit Linux > auch ein Betriebssystem läuft, das mit PCIe-Graphikkarten umgehen kann. Das ist ein reines "es geht prinzipiell, ich habs geschafft". Der praktische Nutzwert ist gering, außer der sportlichen Herausforderung. > Ein Raspberry Pi ist kein Microcontroller* und war auch noch nie einer. Schon klar, es ist ein Minicomputer. Naja, nein, ein Einplatinencomputer, neudeutsch SoC. > Und warum soll man auf einem ARM, der mit ausreichend Arbeitsspeicher > und Performance daherkommt, kein Linux laufen lassen? Hat das irgendeiner behauptet? Lass es gut sein, diese "Diskussion" ist sinnlos. > *) mit Ausnahme des idiotisch benannten "Raspberry Pi Pico", dem RP2040 > & Co. Was jetzt, dort nicht? Warum nicht? Der hat deutlich mehr als 64kB!
Falk B. schrieb: > Lass es gut sein, diese "Diskussion" ist sinnlos. Die Erfahrungen der letzten Monate zeigen, daß eine "Diskussion" mit Dir ohnehin sinnlos ist. Das Folgende richtet sich daher an unsere Mitleser. > Aber man könnte das feststellen. Immer mehr irgendwo draufpacken > ist irgendwann mal sinnlos bis kontraproduktiv. Insbesondere beim Raspberry Pi ist das in mehrfacher Hinsicht totaler Quatsch. Einerseits eröffnen die höhere Rechenleistung, der größere Arbeitsspeicher und die verbesserten Schnittstellen neue Anwendungsfälle, andererseits sind kleine Modelle des Raspberry Pi wie der Raspberry Pi B+ (700 MHz Single-Core mit 512 MB) auch heute noch für weniger als 30 Euro erhältlich. > Schon klar, es ist ein Minicomputer. Naja, nein, ein > Einplatinencomputer, neudeutsch SoC. SoC ist die Abkürzung für "System on a chip" [1]. Ein Einplatinencomputer wie der Raspberry Pi ist allerdings ein "Single-Board Computer", abgekürzt "SBC" [2]. Das schließt nicht aus, daß auf einem SBC ein SoC verbaut sein kann, im Falle des hier besprochenen Raspberry Pi ist genau das der Fall. [1] https://en.wikipedia.org/wiki/System_on_a_chip<; [2] https://en.wikipedia.org/wiki/Single-board_computer
Falk B. schrieb: > Waren das nicht 640kB? Nicht an einem 8-Bit-Prozessor. Falk B. schrieb: > Schon klar, es ist ein Minicomputer. Naja, nein, ein > Einplatinencomputer, neudeutsch SoC. Die meisten PCs sind heutzutage Einplatinencomputer ... Seitdem die cpu-eigene Graphik für die meisten Anwendungen völlig ausreicht, steckt in den wenigsten PCs überhaupt noch irgendeine PCIe-Karte drin. Und damit sind das --tadaa!-- Einplatinencomputer.
Harald K. schrieb: > Die meisten PCs sind heutzutage Einplatinencomputer ... Seitdem die > cpu-eigene Graphik für die meisten Anwendungen völlig ausreicht, steckt > in den wenigsten PCs überhaupt noch irgendeine PCIe-Karte drin. > > Und damit sind das --tadaa!-- Einplatinencomputer. Nicht ganz: Der Massenspeicher ist i.d.R. nicht mit drauf, sondern als --tadaa!-- steckbare Karte ausgeführt (die letztlich per PCIe an's System angebunden ist).
Ein T. schrieb: > andererseits sind kleine Modelle des Raspberry Pi wie > der Raspberry Pi B+ (700 MHz Single-Core mit 512 MB) auch heute noch für > weniger als 30 Euro erhältlich. Das stimmt. Aber selbst mit den "alten" Linuxdistributionen ist die Kiste schon teilweise arg lahm! Vielleicht sind wir ja alle nur von unseren Boliden verwöhnt und haben die Bootzeiten aus der "guten, alten Zeit" vergessen, aber der kleine Raspi braucht locker 2-3min zum booten. Gibt's da nicht was Schlankeres, vor allem wenn man eine einzelne Anwendung auf dem Ding laufen lassen will? So mit 5-10s Bootzeit? Jaja, es gibt diverse Hacks, aber die scheinen schon einiges an Knoff Hoff zu verlangen. https://www.furkantokac.com/rpi3-fast-boot-less-than-2-seconds/ Ob der Artikel getürkt ist? ;-) https://github.com/IronOxidizer/instant-pi Hmm.
Falk B. schrieb: > Ein T. schrieb: >> andererseits sind kleine Modelle des Raspberry Pi wie >> der Raspberry Pi B+ (700 MHz Single-Core mit 512 MB) auch heute noch für >> weniger als 30 Euro erhältlich. > > Das stimmt. Aber selbst mit den "alten" Linuxdistributionen ist die > Kiste schon teilweise arg lahm! Sie ist auch nicht für High Performance Computing gemacht oder gedacht, und Booten ist sicherlich weder der einzige, noch der wichtigste Anwendungsfall für derartige Computer. Zudem ist es paradox, wenn Du einerseits behauptest, die leistungsfähigere Hardware der neuen Modelle sei ein "immer mehr irgendwo draufpacken", das Du "irgendwann mal sinnlos bis kontraproduktiv" nennst, aber dann beklagst, daß Dir die kleinen Modelle nicht genug Leistung böten. > [...] der kleine Raspi braucht locker 2-3min zum booten. > Gibt's da nicht was Schlankeres, vor allem wenn man eine einzelne > Anwendung auf dem Ding laufen lassen will? So mit 5-10s Bootzeit? Von RiscOS habe ich irgendwo gelesen, daß es auf einem RasPi2 in unter 15 Sekunden bootet. Du könntest es ausprobieren und uns von Deiner Erfahrung berichten, wenn Du Dich konstruktiv einbringen möchtest. > Jaja, es gibt diverse Hacks, aber die scheinen schon einiges an Knoff > Hoff zu verlangen. Jetzt soll ein leistungsschwacher, aber dafür preiswerter Miniaturrechner, der Dir zwar zu langsam ist, den mit mehr Leistung und Fähigkeiten zu erweitern Du jedoch als "sinnlos bis kontraproduktiv" bezeichnest, und der ausdrücklich zum Lernen (also zum Erwerb von Knowhow) erdacht und gemacht wurde, auch noch ohne jedwedes Knowhow verwendet werden können? Pardon, aber diese Erwartung scheint mir doch ein winzig kleines bisschen... unrealistisch. > https://www.furkantokac.com/rpi3-fast-boot-less-than-2-seconds/ > > Ob der Artikel getürkt ist? ;-) > > https://github.com/IronOxidizer/instant-pi Seit dem ersten Modell des Raspberry Pi besteht nicht nur die Möglichkeit, sondern auch eine hervorragende Ressource der Universität Cambridge für die Bare-Metal-Programmierung des Raspberry Pi [1]. Weitere Tutorials für andere Modelle finden sich unter anderem hier [2], hier [3] und hier [4], und ein Framework für C++ gibt es hier [5]. Ohne Knowhow könnte das allerdings noch schwieriger sein als das Abspecken eines Linuxsystems. [1] https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/ [2] https://s-matyukevich.github.io/raspberry-pi-os/docs/lesson01/rpi-os.html [3] https://github.com/bztsrc/raspi3-tutorial [4] https://www.rpi4os.com/ [5] https://circle-rpi.readthedocs.io/en/47.0/
Ein T. schrieb: >> Das stimmt. Aber selbst mit den "alten" Linuxdistributionen ist die >> Kiste schon teilweise arg lahm! > > Sie ist auch nicht für High Performance Computing gemacht oder gedacht, > und Booten ist sicherlich weder der einzige, noch der wichtigste > Anwendungsfall für derartige Computer. Seit wann ist ein normales Linux "High Performance Computing"? Ist es zuviel verlangt, wenn eine Embedded Kiste in 10-30s durchgestartet ist? Auch Linux leidet an Bloatware. > Zudem ist es paradox, wenn Du einerseits behauptest, die > leistungsfähigere Hardware der neuen Modelle sei ein "immer mehr > irgendwo draufpacken", das Du "irgendwann mal sinnlos bis > kontraproduktiv" nennst, aber dann beklagst, daß Dir die kleinen Modelle > nicht genug Leistung böten. Das liegt aber weniger an mangelnder Hardwareleistung als an verfetteter Software. Ein Bare Metal Image "bootet" in weniger als 1s, auch auf dem ältesten RasPi. Klar, das ist keine normale Anwendung, mit der die meisten was anfangen können, dazu braucht es meist viel Wissen, um das zusamenzubauen. >> [...] der kleine Raspi braucht locker 2-3min zum booten. >> Gibt's da nicht was Schlankeres, vor allem wenn man eine einzelne >> Anwendung auf dem Ding laufen lassen will? So mit 5-10s Bootzeit? > Von RiscOS habe ich irgendwo gelesen, daß es auf einem RasPi2 in unter > 15 Sekunden bootet. Du könntest es ausprobieren und uns von Deiner > Erfahrung berichten, wenn Du Dich konstruktiv einbringen möchtest. Kann man machen, aber dann ist man wieder auf der Insel von RISC-OS. Was kann das sonst? Welche Standardsprachen und Anwendungen hat man da? >> Jaja, es gibt diverse Hacks, aber die scheinen schon einiges an Knoff >> Hoff zu verlangen. > > Jetzt soll ein leistungsschwacher, aber dafür preiswerter > Miniaturrechner, der Dir zwar zu langsam ist, den mit mehr Leistung und > Fähigkeiten zu erweitern Du jedoch als "sinnlos bis kontraproduktiv" > bezeichnest, Das Aufbohren der Hardware macht den Rechner zwar äußerlich schneller, kaschiert aber nur allzuoft die fette Software. https://de.wikipedia.org/wiki/Wirthsches_Gesetz "Die Software wird schneller langsamer, als die Hardware schneller wird." > und der ausdrücklich zum Lernen (also zum Erwerb von > Knowhow) erdacht und gemacht wurde, auch noch ohne jedwedes Knowhow > verwendet werden können? Davon Redet keiner. Aber Es ist ja nun keine Ausnahmeanwendung, wenn Leute ihren RasPi schneller booten wollen, vor allem in Produktivanwendungen. Wir nutzen den in der Firma als GUI für Geräte. Funktioniert im Prinzp prima. Aber das Starten der Software dauert ganz schön, 30s und mehr, muss ich mal messen. Der Vorgänger hatte auch ein embedded Linux, aber nur 32MB Flash und 64MB RAM, da dauerte der Start ca. 15s bis zur Applikation. Langsamere Hardware startet (hier) schneller! Ist für das Gerät zwar nicht das Killerkriterium, aber schon irgendwie merkwürdig. > Weitere Tutorials für andere Modelle finden sich unter anderem hier [2], > hier [3] und hier [4], und ein Framework für C++ gibt es hier [5]. Ohne > Knowhow könnte das allerdings noch schwieriger sein als das Abspecken > eines Linuxsystems. Dort liegt das Problem. Man brächte ein Baukastensystem, und sei es nur eins mit einer handvoll statischer Bauklötze, welche auf verschiedene Funktionsumfänge und Bootgeschwindigkeiten abgestimmt sind. Wer schneller starten will, kann eben nicht alle Funktionen nutzen, das ist klar. Sowas muss ein Profi bauen, damit es die Beckenrandschwimmer unter den Linuxern, (solche Leute wie ICH) leicht nutzen können. Selber tu ich mir das nicht an, ich kann und will nicht alles wissen und können. Außerdem habe ich dafür gar nicht den dringenden Bedarf. Es wäre nett. Wenn nicht, kann und muss ich mit 30s Bootzeit leben.
https://www.raspberry-pi-geek.de/ausgaben/rpg/2020/06/die-boot-zeit-von-raspbian-optimieren/2/#artRef-f6 Sieht gut aus, muss man aber mal probieren.
Was ein Unsinn hier geblubbert wird. Nur mal so als Anregung: der BCM2712 liefert mehr Leistung also so mancher (älterer) Core-i, APU oder gar Opteron. Und da wird rumschwadroniert das es keinen Sinn macht da eine externe Graka dranzuhängen. Es gab PCIe GPUs lange vor den vorgenannten CPUs und man stelle sich mal vor, die hat man mit CPUs kombiniert die nicht mal 1/3 der Leistung des RPi5 bringen.
Falk B. schrieb: > Davon Redet keiner. Aber Es ist ja nun keine Ausnahmeanwendung, wenn > Leute ihren RasPi schneller booten wollen, vor allem in > Produktivanwendungen. Wir nutzen den in der Firma als GUI für Geräte. > Funktioniert im Prinzp prima. Aber das Starten der Software dauert ganz > schön, 30s und mehr, muss ich mal messen. Der Vorgänger hatte auch ein > embedded Linux, aber nur 32MB Flash und 64MB RAM, da dauerte der Start > ca. 15s bis zur Applikation. Langsamere Hardware startet (hier) > schneller! Ist für das Gerät zwar nicht das Killerkriterium, aber schon > irgendwie merkwürdig. Njet, towarischtsch. Es ist nur eine Designentscheidung die nicht einmal die Software selbst, sondern nur ihre Konfiguration betrifft. > Dort liegt das Problem. Man brächte ein Baukastensystem, und sei es nur > eins mit einer handvoll statischer Bauklötze, welche auf verschiedene > Funktionsumfänge und Bootgeschwindigkeiten abgestimmt sind. Wer > schneller starten will, kann eben nicht alle Funktionen nutzen, das ist > klar. Dann schauen wir doch einfach in den Link in Deinem Folgebeitrag: Falk B. schrieb: > https://www.raspberry-pi-geek.de/ausgaben/rpg/2020/06/die-boot-zeit-von-raspbian-optimieren/2/#artRef-f6 Du siehst dass das Baukastensystem bereits vorhanden ist. Der Punkt ist nun: das System ist dazu gedacht, dass möglichst viele Features der Hardware ohne weitere Eingriffe funktionieren, damit den Lernenden ein möglichst einfacher Einstieg geboten wird. Darum werden alle Bausteine aktiviert. Wenn Du die für Dich Nutzlosen deaktivierst, bootet das schneller. > Sowas muss ein Profi bauen, damit es die Beckenrandschwimmer unter den > Linuxern, (solche Leute wie ICH) leicht nutzen können. Lern halt wie es funktioniert - und das ist ja der ganze Grundgedanke hinter dem Raspberry Pi. Oder lass es - und leb' mit der Bootzeit. Dich stattdessen darüber zu beklagen dass die Software bloaty sei ist nur eine Entschuldigung für Deine eigene Faulheit.
Falk schrob: >Seit wann ist ein normales Linux "High Performance Computing"? Schon immer: https://ubuntu.com/engage/a-guide-to-high-performance-computing https://sites.google.com/pdx.edu/research-computing/systems/linux-hpc
Falk B. schrieb: > Seit wann ist ein normales Linux "High Performance Computing"? > Ist es zuviel verlangt, wenn eine Embedded Kiste in 10-30s > durchgestartet ist? Auch Linux leidet an Bloatware. Nun, das ist sicher so. Allerdings: die (Linux-)Raspis kann man relativ problemlos auf ca. 10s Bootzeit bekommen. Aber natürlich gibt es dann weder ein GUI und noch diversen anderen Komfort im Linux-System. Nennenswert unter ca. 10s ist allerdings illusorisch. Das ist mit Linux einfach nicht drin. Wer das will, muss die Dinger mit dem "bare-metal"-Ansatz benutzen. Und selbst dann bleiben etwa 1s Bootzeit, da das Booten zwingend über den vom Anwender unbeinflussbaren, nicht dokumentierten Firmware-Blob erfolgen muss, der halt diese Zeit braucht. Warum auch immer... Aber selbst 1s ist eine kleine Ewigkeit im Vergleich zu dem, was auf anderen µC möglich ist. Für alle, wo es auf schnelle Verfügbarkeit nach (PowerOn-) Reset ankommt, ist also ein Raspi die komplett falsche Wahl.
Ob S. schrieb: >> Seit wann ist ein normales Linux "High Performance Computing"? >> Ist es zuviel verlangt, wenn eine Embedded Kiste in 10-30s >> durchgestartet ist? Auch Linux leidet an Bloatware. > > Nun, das ist sicher so. Allerdings: die (Linux-)Raspis kann man relativ > problemlos auf ca. 10s Bootzeit bekommen. Aber natürlich gibt es dann > weder ein GUI und noch diversen anderen Komfort im Linux-System. Na toll, und was ist dann der Sinn der Übung? Es gibt aber diverse Ansätze und Seiten im Netz, die das in eine handvoll Sekunden schaffen. Handgeklöppelter Kernel mit kompilierter Einzelanwendung. Funktioniert, erfordert halt einiges an Arbeit und Know How. Sagte ich bereits. https://www.youtube.com/watch?v=m3rfls00OtY#t=35s https://www.youtube.com/watch?v=hOFZ8LHPgWs https://www.youtube.com/watch?v=PjjET56Ct3w > Nennenswert unter ca. 10s ist allerdings illusorisch. Das ist mit Linux > einfach nicht drin. Wer das will, muss die Dinger mit dem > "bare-metal"-Ansatz benutzen. Und selbst dann bleiben etwa 1s Bootzeit, Was für so eine Kiste schon Lichtgeschwindigkeit wäre. > Aber selbst 1s ist eine kleine Ewigkeit im Vergleich zu dem, was auf > anderen µC möglich ist. Das ist aber kein ernsthafter Vergleich und davon war auch nie die Rede. > Für alle, wo es auf schnelle Verfügbarkeit nach (PowerOn-) Reset > ankommt, ist also ein Raspi die komplett falsche Wahl. Sicher, aber man kann schon ab und an die Frage stellen, was man am Standardansatz verbesser kann.
:
Bearbeitet durch User
Falk B. schrieb: > Es gibt aber diverse Ansätze und Seiten im Netz, die das in eine > handvoll Sekunden schaffen. Handgeklöppelter Kernel mit kompilierter > Einzelanwendung. So weit braucht man nicht zu gehen, um die ca. 10s zu schaffen. Dafür genügt es, einfach mit den üblichen Mitteln alles zu deinstallieren was man nicht braucht. Also: apt purge (garnicht mal so lange Liste von nutzlosen Blähungen) Das meiste erschlägt man über die Abhängigkeiten durch ein nachfolgendes apt autoclean apt autoremove Und zum Schluss dann ein gewagtes apt purge apt Man sollte sich sicher sein, dass noch alles da ist, was man braucht und nichts Überflüssiges mehr. Optimierter Kernel und Single-Application-init bringen demgegenüber dann schon kaum noch etwas. Bezüglich der Bootzeit sind das sehr deutlich unter 1s. Bezüglich der nötigen Image-Größe könnte es allerdings durchaus noch relevant sein. Macht halt schon manchmal einen Unterschied, ob man knapp über oder knapp unter 2GB ist...
Ob S. schrieb: > Und zum Schluss dann ein gewagtes > apt purge apt Und was soll das bringen? Der Paketmanager ist am Bootvorgang gar nicht beteiligt, warum sollte der Ihn also verzögern?
Falk B. schrieb: > Ob S. schrieb: >>> Ist es zuviel verlangt, wenn eine Embedded Kiste in 10-30s >>> durchgestartet ist? Auch Linux leidet an Bloatware. >> >> Allerdings: die (Linux-)Raspis kann man relativ >> problemlos auf ca. 10s Bootzeit bekommen. Aber natürlich gibt es dann >> weder ein GUI und noch diversen anderen Komfort im Linux-System. > > Na toll, und was ist dann der Sinn der Übung? Schnelleres Booten. Also genau das, was Du haben wolltest. > Sicher, aber man kann schon ab und an die Frage stellen, was man am > Standardansatz verbesser kann. Um das zu diskutieren, müßte dieser "man" den "Standardansatz" zumindest verstehen. Das willst Du nicht und tust Du nicht.
Ein T. schrieb: > Falk B. schrieb: >> Ob S. schrieb: >>>> Ist es zuviel verlangt, wenn eine Embedded Kiste in 10-30s >>>> durchgestartet ist? Auch Linux leidet an Bloatware. >>> >>> Allerdings: die (Linux-)Raspis kann man relativ >>> problemlos auf ca. 10s Bootzeit bekommen. Aber natürlich gibt es dann >>> weder ein GUI und noch diversen anderen Komfort im Linux-System. >> >> Na toll, und was ist dann der Sinn der Übung? > > Schnelleres Booten. Also genau das, was Du haben wolltest. Willst du mich verarschen? Was nützt schnelleres Booten, wenn man dann nicht die Applikation starten kann, die man braucht?
Angehängte Dateien:
-
12.jpg
210 KB
Hm.. also der "Hack" an sich ist schon interessant, wenn ich so überlege.. mein rock5b hat ein Problem mit hw-acceleration beim GPU Treiber, da die Grafikeinheit die Android optimierte Version Open GL ES 2.0 unterstützt. (Die Linux Treiber sind re-engineert) Dann Kauf ich doch etwas das meinem teuren Projekt entspricht ;) Anbei mal das Setup des rock5B.
Philipp K. schrieb: > Anbei mal das Setup des rock5B. Ja schön. Aber als HMI/GUI für die allermeisten Geräte und Anwendungen um Größenordnungen überdimensioniert. Wenn man die Software DEUTLICH abspecken kann, reicht der olle Raspberry PI 1A! Dessen CPU-Leistung und RAM war vor vielen Monden mal die Oberklasse von Desktop PCs! Und da ging was!
Falk B. schrieb: > reicht der olle Raspberry PI 1A Jo, das schon.. auf dem bzw. Dem Zero habe ich vor schätzungsweise über 2000 Monden schon mit 25Hz Displays per spi, custom Treiber und custom framebuffer ohne x11 rumgebastelt.. auf eine finalisierte GPU unterstützung wäre ich dabei nicht gekommen. Es war auf jeden Fall mal interessant jedes Pixel selbst vom Code bis hin zum Bildschirm zu verfolgen.
Philipp K. schrieb: > Jo, das schon.. auf dem bzw. Dem Zero habe ich vor schätzungsweise über > 2000 Monden schon mit 25Hz Displays per spi, custom Treiber und custom > framebuffer > ohne x11 rumgebastelt.. auf eine finalisierte GPU unterstützung wäre ich > dabei nicht gekommen. Naja, das ist das andere Extrem, mit dem die Masse der Anwender auch nix anfangen kann. > Es war auf jeden Fall mal interessant jedes Pixel selbst vom Code bis > hin zum Bildschirm zu verfolgen. Als Experiment vielleicht, aber nicht praxistauglich.
Falk B. schrieb: Falk B. schrieb: > Naja, das ist das andere Extrem, mit dem die Masse der Anwender auch nix > anfangen kann. Besser als eine dedizierte Grafikkarte davor zu bauen. Ich habe es dann mit javafx headless gelöst. Ich meine, wenn man ein Hmi bauen will, gibt es 100 andere fertige Lösungen als eine dedizierte Grafikkarte.
Falk B. schrieb: > Ein T. schrieb: >> Falk B. schrieb: >>> Ob S. schrieb: >>>>> Ist es zuviel verlangt, wenn eine Embedded Kiste in 10-30s >>>>> durchgestartet ist? Auch Linux leidet an Bloatware. >>>> >>>> Allerdings: die (Linux-)Raspis kann man relativ >>>> problemlos auf ca. 10s Bootzeit bekommen. Aber natürlich gibt es dann >>>> weder ein GUI und noch diversen anderen Komfort im Linux-System. >>> >>> Na toll, und was ist dann der Sinn der Übung? >> >> Schnelleres Booten. Also genau das, was Du haben wolltest. > > Willst du mich verarschen? Dazu bedarfst Du keiner Unterstützung. > Was nützt schnelleres Booten, wenn man dann > nicht die Applikation starten kann, die man braucht? Meine Applikationen laufen. Meistens ohne GUI und ohne X-Server, mal mit GUI und X-Server, und in seltenen Fällen zwar mit GUI, aber ohne X-Server. Wenn Booten Dein wichtigster Anwendungsfall ist und Du es darum schneller machen willst, gibt viele Möglichkeiten. Du kannst in schnellere Hardware investieren, also in einen RasPi5 mit schneller CPU und schnellem Speicher, und einer NVMe-SSD. Die NVMe-SSD soll laut Benchmarks im Netz etwa 700MB/s lesen und schreiben, die klassische SD kommt bestenfalls auf etwas über 90. Das ist die einfachste Lösung, sie erfordert nur ein bisschen Kleingeld. Du kannst die Standardinstallation optimieren und alles deaktivieren, das Du nicht brauchst: Bluetooth, WLAN, vielleicht auch Ethernet und DHCP, you get the idea. Das ist ein winziges kleines bisschen schwieriger, aber auch kein Hexenwerk. Auch der Austausch oder das Weglassen von Komponenten könnte die Bootzeit deutlich beschleunigen. Oder, zu deutsch: die Teile des Baukastens deaktivieren, die Du nicht benötigst. Anstelle des Desktops könnte allerdings auch der X-Server abgespeckt und ein Mini-Windowmanager wie twm oder matchbox verwendet werden, oder Du kannst auf einen Desktop verzichten und das Programm direkt als X-Client starten. Wenn Deine Software eine Web-GUI hat und darum einen lokalen Browser braucht, sind Midori oder sogar ein eigener Minimalbrowser auf Basis von Qt, WxWidgets oder GTK eine schnelle und sehr leichtgewichtige Alternative zu den großen Desktop-Browsern sein. Das ist alles auch für Linux-Beckenrandschwimmer möglich und erfordert lediglich ein bisschen Lern- und Experimentieraufwand. Du kannst auch richtig ans Eingemachte gehen und das Init-System umgehen, oder auf den X-Server verzichten und mit LVGL, tfblib oder meines Wissens sogar Qt eine GUI für den Framebuffer schreiben. Das erfordert dann ein bisschen mehr Lern-, Entwicklungs- und Experimentieraufwand, aber wenn Du wirklich so klug und überragend gut ausgebildet wärst, wie Du gerne tust, wären das für Dich kein unüberwindlichen Probleme. Bei mir daheim läuft ein RasPi4, der macht eine konfigurierbare, bis hinab auf 1 Pixel genaue Bewegungserkennung und -Aufzeichnung auf 720p-Bildern von einer Logitech C920, mit Python und OpenCV. Hochparallelisiert verarbeitet das Ding 30 Frames pro Sekunde -- also das, was die Kamera liefern kann -- und lastet die CPU des kleinen Rechnerchens dabei voll aus. Natürlich habe ich ein paar Tage an der Optimierung gesessen und das System und die Software optimiert. Aber immerhin: meine Software tut, was sie soll, liefert zuverlässige Bilder vom bekloppten Garfield im Garten, während Zoneminder und Motion vorher auf einem Intel Nuc i5 damit komplett überfordert waren. Es geht also. Man muß es nur tun. Das willst Du aber nicht, und Deine Ausrede für Deinen Geiz, Deine Ignoranz und Deine Faulheit ist die Behauptung, Linux litte angeblich an "Bloatware". Ja nee, is klaa. Und wenn Du nicht schwimmen kannst, ist die Badehose schuld.
Andreas M. schrieb: > Ob S. schrieb: >> Und zum Schluss dann ein gewagtes >> apt purge apt > > Und was soll das bringen? Der Paketmanager ist am Bootvorgang gar nicht > beteiligt, warum sollte der Ihn also verzögern? Das kommt darauf an, wie man "Bootzeit" definiert und was man für Erwartungen an das Laufzeitverhalten des Systems für die erste Zeit nach der Bootzeit hat... Für mich ist die Bootzeit dann zu Ende, wenn "meine" Anwendung die Kontrolle erlangt. Und mein Anspruch an das System ist, dass es nach diesem Zeitpunkt selber möglichst keinen massiven Traffic mehr verursacht, weder bezüglich des Massenspeichers noch bezüglich des Netzwerks noch bezüglich des USB- oder PCIe-Bus.
Ob S. schrieb: > Das kommt darauf an, wie man "Bootzeit" definiert und was man für > Erwartungen an das Laufzeitverhalten des Systems für die erste Zeit nach > der Bootzeit hat... > > Für mich ist die Bootzeit dann zu Ende, wenn "meine" Anwendung die > Kontrolle erlangt. Und was hat das mit dem Paketmanager zu tun? Ist völlig Wurst ob der installiert ist oder nicht, das ändert an der Bootzeit eines Systems genau gar nix.
Harald K. schrieb: > Du weißt, daß neuere Raspberry-Pi-Modelle PCIe sprechen? Zwar nur mit > einer Lane, aber immerhin. Was hab ich denn hier los getreten... ^-^ @Harald: Es kommt halt immer drauf an, was man will und was es kosten darf. Ich denke nicht von "was kann das Ding" her, sondern von "was ist mein Problem, und wie kann ich es lösen?" (ja, ich weiß, Elfmeter ohne Torwart für ne Antwort...) Also, was ich damit meine ist, aus aktuellem Anlass... Meine Anforderung als Kunde an mich selbst als Entwickler ist nicht "Ich will zwei Lautsprecherboxen aus MDF mit Visaton-Chassis bauen", sondern "Ich will in meinem Wohnzimmer Musik mit nem guten Klang hören." Die technische Planung kommt viel später. Und zurück zum eigentlichen Thema: Dass die Raspis PCIe beherrschen, finde ich prima. Ist für viele Dinge praktisch. Sie sind aber eben nicht leistungsfähig genug für aktuelle GraKas der oberen Leistungsklasse. Für mich sind solche Stunts wie die im ursprünglichen Artikel einfach Nerd-Topics, die ich amüsant finde und bestimmt auch mega lehrreich, aber wenn man dann mit ein bisschen Vernunft oder nicht endlosem Budget mal Leistung/Euro ausrechnet, stellt man schnell fest, dass ein 1024er Beowulf-Cluster aus Pi5 akademisch gesehen ein tolles Projekt sein mag, aber das reale Verhältnis von Leistung zu Aufwand und Kosten eine Katastrophe ist. Ich hab z.B. mal zum Spaß theoretisch durchgedudelt, wie ein selbst gebautes Fahrrad-Navi mit allem Schnickschnack aussehen könnte, also aus für Normalsterbliche zusammengestellten Komponenten. Fazit: Ich hätte sehr viel gelernt, aber für die Hardware eine eigene Tasche am Oberrohr gebraucht und auch kaum mehr bekommen als das, was ein Mittelklasse-Smartphone für 250 € mit ein paar fertigen Apps schon seit Jahren kann. Darum auch mein Verweis auf den Orin Jetson Nano im OP. Ist eine süße kleine Kiste und aktuell beim Reichelt mit dem großen Speicher für etwas über 600 € zu haben. Die neuen AI-Hats für den Pi5 schaufeln 16 TOPS, der OJN mit dem großen Speicher 40. 3 Pi5 plus Hat machen ungefähr 450 €, mit theoretischen 48 TOPS. Klingt, als hätte der Pi die Nase vorn. Jetzt geben wir mal das doppelte Geld (900 €) aus für einen mittelprächtigen PC samt einer RTX 4060 mit 8 GB und kriegen dafür 242 AI TOPS, fürs doppelte Geld also die 6-fache Leistung, und der Rest der Hardware ist zwar dann kein Dragster, kommt mit den Datenraten aber doch recht entspannt zurecht, während auch ein fiktiver Pi6 oder Pi7 (im bekannten physischen Format) darunter komplett kollabieren würde. Fazit: Es ist immer spannend zu probieren, was machbar ist. Aber ab und zu kann es nicht schaden, sich selbst auch im Hobbybereich mit einem Blick auf die großen Spieler am Markt zu erden. Wäre es wirtschaftlich sinnvoll, mit Raspberrys große AI-Farmen zu betreiben, würde das schon längst gemacht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.