Hallo, ich möchte gerne zum Raspberry-Pi-Einstieg eine Art Tablet für Akkubetrieb bauen. Kurz gesagt soll das OS Linux sein und darauf laufen sollen unter anderem folgende Programme/Utilities: -IPython -Modzilla Firefox -Video-Audio-Player (Media-Center) -PDF-/E-Book-Reader Bin bei der Hardware allerdings noch nicht sicher, was zum Einsatz kommen soll. Ein RasPi 3 Mod. B sollte es wohl mindestens sein. Die Hauptfrage ist aktuell, was für Displays in Frage kommen. Am besten etwas passendes zwischen 7" und 14" mit halbwegs hoher Auflösung und Farbtiefe. Eventuell mit Touchscreen (bin da noch nicht ganz sicher). Die erste Frage von meiner Seite wäre also, wo man in Frage kommende Displays halbwegs günstig finden kann (gebraucht?). Wenn ansonsten jemand Anregungen zu dem Projekt hat, gerne posten!
pollin.de hat u.a. 7" und 10" Displays mit und ohne Touch
Der Vollständigkeit halber: Ein 10er Tablet mit Akku für den RasPi gibts fertig zu kaufen, von SunFounder. Kostet allerdings etwas und die Akku-Lebensdauer kann mit den üblichen Tablets nicht mithalten.
Einen PI willst Du nicht verwenden. Die üblichen Displays in dieser Größenordnung haben entweder LVDS oder Embedded DisplayPort. Der Pi hat nichts davon. Du brauchst eine extra Platine für HDMI. Kleine Displays gibts auch noch mit Parallel RGB. Das kann der Pi zwar prinzipiell, aber Du verlierst dadurch fast zwei Drittel der GPIOs. Such Dir besser ein anderes ARM-Board aus. Gibt ja genug davon. ansonsten schau mal her: https://www.buydisplay.com/default/10-inch-raspberry-pi-touch-screen-with-small-hdmi-driver-board-1024x600 fchk
Frank K. schrieb: > Die üblichen Displays in dieser Größenordnung haben entweder LVDS oder > Embedded DisplayPort. Der Pi hat nichts davon. Du brauchst eine extra > Platine für HDMI. Die Pollin-Displays haben HDMI, laufen hier super
Hallo und Danke für die Antworten! Die Idee mit Pollin ist gut! A. K. schrieb: > Ein 10er Tablet mit Akku für den RasPi gibts > fertig zu kaufen, von SunFounder. Kostet allerdings etwas und die > Akku-Lebensdauer kann mit den üblichen Tablets nicht mithalten. Warum, sind dort zu kleine Akkus verbaut oder verbraucht das Gerät zu viel? Frank K. schrieb: > Die üblichen Displays in dieser Größenordnung haben entweder LVDS oder > Embedded DisplayPort. Der Pi hat nichts davon. Du brauchst eine extra > Platine für HDMI. > Kleine Displays gibts auch noch mit Parallel RGB. Das kann der Pi zwar > prinzipiell, aber Du verlierst dadurch fast zwei Drittel der GPIOs. Die genannte Problematik habe ich schon bei Youtube gesehen. Grundsätzlich werden für das Projekt nicht so viele IO-Pins benötigt. Deshalb könnte man den Verlust von 2/3 der GPIOs wahrscheinlich verschmerzen. Wäre so ein Display denn günstiger und stromsparender als ein Display mit HDMI-Platine (wenn es das überhaupt in Größen ab 7" gibt)? Und muss der ARM dann viele Resourcen extra für das Nicht-HDMI-Display bereitstellen? Frank K. schrieb: > Such Dir besser ein anderes ARM-Board aus. Gibt ja genug davon. Eigentlich wollte ich mal was speziell mit RasPi machen, aber interessehalber gefragt, gibt es ein Board, das man für so ein Projekt besonders empfehlen kann? Und wäre das dann auch so gut supported wie der RasPi? KK schrieb: > Die Pollin-Displays haben HDMI, laufen hier super Danke für die Info! Die benötigen alle so ca. 2A bei 5V, habe ich gesehen. Betreibst du die zufällig mit LiIon-Akkus?
DC schrieb: > Frank K. schrieb: >> Die üblichen Displays in dieser Größenordnung haben entweder LVDS oder >> Embedded DisplayPort. Der Pi hat nichts davon. Du brauchst eine extra >> Platine für HDMI. >> Kleine Displays gibts auch noch mit Parallel RGB. Das kann der Pi zwar >> prinzipiell, aber Du verlierst dadurch fast zwei Drittel der GPIOs. > > Die genannte Problematik habe ich schon bei Youtube gesehen. > Grundsätzlich werden für das Projekt nicht so viele IO-Pins benötigt. > Deshalb könnte man den Verlust von 2/3 der GPIOs wahrscheinlich > verschmerzen. > Wäre so ein Display denn günstiger und stromsparender als ein Display > mit HDMI-Platine (wenn es das überhaupt in Größen ab 7" gibt)? Und muss > der ARM dann viele Resourcen extra für das Nicht-HDMI-Display > bereitstellen? Bei Parallel RGB ist spätenstens bei 1024*768 Schluss. Je höher der Pixeltakt, desto empfindlicher wird die Übertragung. Ich würde eigentlich schon ab 800*480 LVDS bevorzugen. Das ist wesentlich unempfindlicher und braucht weniger Leitungen, und das Kabel darf länger als ein paar cm sein. Die HDMI-Konverter-Platine braucht Strom. Wieviel, das hängt vom Pixeltakt und damit von der Auflösung ab. Und wenn Du weißt, dass der Konverterchip bei 1024*600 Pixeln schon einen kleinen Kühlkörper braucht, dann weißt Du auch, dass da Strom in Wärme verbraten wird. Also genau das, was Du bei Akkubetrieb absolut nicht haben willst. Der PI hat noch eine weitere Display-Schnittstelle, nämlich MIPI DSI. Die geht aber nur mit dem originalen Display von der Pi Foundation. Der Pi hat eine beträchtliche Popularität, aber dennoch etliche ernsthafte Nachteile. Die unvollständige Hardwaredokumentation, die binären Blobs und die mangelnde Schnittstellenausstattung (der Prozessor ist für einfache Tablets und digitale Bilderrahmen entwickelt worden) sind nur einige davon. Der größte Stromverbraucher ist jedoch immer noch die Hintergrundbeleuchtung des Displays. Ein halbes A bei 3.3V bei einem 7" Display ist so ungewöhnlich nicht. Mit steigenden Displaydiagonalen wirds natürlich entsprechend mehr. Wenn Du wirklich stromsparend sein willst, nimm eInk/ePaper. Der ARM-Kern selber hat mit dem Display eigentlich eher wenig zu tun, dafür gibts den Displaycontroller, ggf mit GPU und 2D/3D-Beschleunigung. > Frank K. schrieb: >> Such Dir besser ein anderes ARM-Board aus. Gibt ja genug davon. > > Eigentlich wollte ich mal was speziell mit RasPi machen, aber > interessehalber gefragt, gibt es ein Board, das man für so ein Projekt > besonders empfehlen kann? Und wäre das dann auch so gut supported wie > der RasPi? Keine Plattform ist so verbreitet wie der Pi. Aber seien wir mal ehrlich: Was brauchst Du? Ein Linux-System mit allein Treibern für die zugehörige Hardware. Ich gehe erstmal nicht davon aus, dass Du selber Hardwareentwicklung oder eine Linux-Portierung machen wirst - dafür stellst Du zu "einfache" Fragen. Bei jedem Board, das Du kaufst, gibts eine vorgefertigte Linux-Installation dafür, und dann benutzt Du nur die Linux-Treiber für SPI, I2C, für Grafik entweder Framebuffer oder OpenGL-ES, für Sound ALSA, für die GPIOs die Standard-Linux-APIs. Das wars. Board-Empfehlungen? Hmm. Firefox ist natürlich schon reichlich fett, da willst Du Leistung haben. Media-Center wollen natürlich auch Rechenleistung haben, oder zumindestens Hardware-Decoder und ggf Encoder. Da wäre schon sowas wie ein NVidia TK1 oder Jetson Nano angebracht, wenn es Spaß machen soll. Ist zwar auch nicht so besonders stromsparend (das TK1 geht noch, das Nano zieht aber bis zu 10W), aber irgend einen Tod wirst Du sterben müssen. Wenn Du was sparsames haben willst, hol Dir halt irgendein billiges China-Android-Tablet. Was besseres mit einigermaßen langer Akkulaufzeit und guter Portabilität wirst Du selber definitiv nicht hinbekommen. Wenn Du hingegen basteln willst, wirst Du mit den NVidia-Boards Freude haben. Da darfst Du dann auch die 192 CUDA-Kerne (beim TK1, der Jetson Nano ist ein TX1 und hat deutlich mehr davon) rechnen lassen. fchk
DC schrieb: > Warum, sind dort zu kleine Akkus verbaut 6000 mAh LiIon liegen im üblichen Rahmen. > oder verbraucht das Gerät zu viel? Ebendies. Die Tablets auf dem Markt sind dafür gebaut worden, die meiste Zeit so wenig wie irgend möglich Strom zu verbrauchen. In Hard- wie in Software. Der RasPi ist das nicht.
:
Bearbeitet durch User
Danke Frank für die ausführliche Antwort mit den vielen Erklärungen und Vorschlägen! Das Ganze ist ein Gemeinschaftsprojekt mit jemandem, der sich mit Linux auskennt, aber keine Ahnung von Elektronik hat. Wir haben uns jetzt entschlossen, einen Raspi B+ zu organisieren und erst mal mit einem normalen HDMI-Monitor am Stromnetz zu arbeiten. Dann wird sich zeigen, ob eine Verkleinerung auf ein portables Gerät sinnvoll ist. Gibt es denn einen Browser, der für einen Raspi unter Linux gut geeignet ist? Frank K. schrieb: > Der ARM-Kern selber hat mit dem Display eigentlich eher wenig zu tun, > dafür gibts den Displaycontroller, ggf mit GPU und 2D/3D-Beschleunigung. Meinst du das so, dass man eine Art externe GPU installieren kann/soll??? (oder ist das auf den eingebauten VideoCore bezogen?) Frank K. schrieb: > Wenn Du wirklich stromsparend sein willst, nimm eInk/ePaper. Das könnte man glatt überlegen, wobei das für Videos eher nichts sein dürfte, aber andere Vorteile hätte. Jetson Nano ist notiert, wobei das eine andere Preisklasse ist, aber interessantes Teil!
DC schrieb: > Wir haben uns jetzt entschlossen, einen Raspi B+ zu organisieren Also Version 3 Mod. B+
DC schrieb: > Gibt es denn einen Browser, der für einen Raspi unter Linux gut geeignet > ist? Chromium. > Meinst du das so, dass man eine Art externe GPU installieren > kann/soll??? Die Videocore-GPU ist gemeint. Die macht die Hauptarbeit fürs Display.
:
Bearbeitet durch User
Danke für die Infos zum Browser und Video-Core! Chromium ist notiert, Danke! Wir werden jetzt definitiv den Raspi 3B+ verwenden. D.h., grade steht die Frage im Raum, welche Speicherkarte man verwenden kann (auch im Hinblick auf die Schreibgeschwindigkeit). In dem Buch "Durchstarten mit Raspberry Pi" steht, dass nicht jede Speicherkarte funktioniert und dass es im Netz eine Liste gibt mit getesteten Karten (also schon auf Raspi-Systemen getestet). Weiß jemand, wo man die finden kann (ich habe sie jedenfalls nicht bei google gefunden, dafür jede Menge Werbung).
Nach einigem Rumgegurke habe ich immerhin schon mal diese Liste hier gefunden: https://elinux.org/RPi_SD_cards
DC schrieb: > Wir werden jetzt definitiv den Raspi 3B+ verwenden. > D.h., grade steht die Frage im Raum, welche Speicherkarte man > verwenden kann (auch im Hinblick auf die Schreibgeschwindigkeit). Das ist Glückssache. SD-Karten sind dafür nicht gedacht, weil sie üblicherweise kein gutes Wear-Levelling haben. Außerdem wird sehr oft Ausschussware an Flash-Chips verbaut, bei denen teilweise nur noch 30% der Blöcke funktionieren. Ist auch noch ein Punkt, warum ich für ernsthafte Aufgaben keinen PI empfehle. Für ernsthafte Aufgaben nimmt man EMMC. Das sind auflötbare Module, die das gleiche Protokoll wie SD-Karten (genauer: MMC-Karten) verwenden, minus dem Kopierschutz-Gedöns (das S in SD), aber mit 8 Datenleitungen statt 4 und doppelter Taktrate plus noch ein paar anderen Kleinigkeiten. Außerdem ist der Speicherchip dadrin von hoher Qualität. Die Pi Compute-Modules gibt es mit EMMC, und auch viele andere Plattformen wie BeagleBone arbeiten damit. fchk
:
Bearbeitet durch User
Frank K. schrieb: > > Für ernsthafte Aufgaben nimmt man EMMC. Das sind auflötbare Module, die > das gleiche Protokoll wie SD-Karten (genauer: MMC-Karten) verwenden, > minus dem Kopierschutz-Gedöns (das S in SD), aber mit 8 Datenleitungen > statt 4 und doppelter Taktrate plus noch ein paar anderen Kleinigkeiten. > Außerdem ist der Speicherchip dadrin von hoher Qualität. eMMC läuft problemlos mit 4 Datenleitungen. Ziemlich viele SoCs haben nur so viel.
Danke für die Ausführungen! SoC = System-on-a-Chip (nehme ich an) https://de.wikipedia.org/wiki/SOC Frank K. schrieb: > Die Pi Compute-Modules gibt es mit EMMC, und auch viele andere > Plattformen wie BeagleBone arbeiten damit. Was meinst du in dem Zusammenhang mit 'Pi Compute-Modules'? Kann man so einen EMMC auch als Speicher an das B3+-Board anschließen? (wenn ja wird es wahrscheinlich so etwas wie das hier sein:) https://www.ebay.de/itm/ODROID-C2-eMMC-Modul-8-GB-mit-Linux/132987106298?epid=1166603925&hash=item1ef6a633fa:g:5KIAAOSwjZJaAeSR Wenn ich das richtig verstehe, wird der EMMC-Chip häufig direkt auf das PCB gelötet. https://de.wikipedia.org/wiki/Multimedia_Card#eMMC Sehe grade, die gibt es auch bei Mouser. https://www.mouser.de/ProductDetail/ISSI/IS21ES16G-JCLI?qs=sGAEpiMZZMve4%2FbfQkoj%252BCMezv1v4I4kzQ49NTV34rA%3D Dort finde ich aber nur handverlötungs-unfreundliche BGA-Ball-Modelle.
DC schrieb: > Frank K. schrieb: >> Die Pi Compute-Modules gibt es mit EMMC, und auch viele andere >> Plattformen wie BeagleBone arbeiten damit. > > Was meinst du in dem Zusammenhang mit 'Pi Compute-Modules'? Das hier: https://www.raspberrypi.org/products/compute-module-3-plus-32gb/ Gibts als 'lite' ohne EMMC, dafür mit µSD Slot oder mit EMMC in verschiedenen Größen. > Kann man so einen EMMC auch als Speicher an das B3+-Board anschließen? > (wenn ja wird es wahrscheinlich so etwas wie das hier sein:) > https://www.ebay.de/itm/ODROID-C2-eMMC-Modul-8-GB-mit-Linux/132987106298?epid=1166603925&hash=item1ef6a633fa:g:5KIAAOSwjZJaAeSR ja. Das Protokoll ist kompatibel, und EMMCs laufen mit einer Busbreite von 1, 4 und 8 Bit. Und die von Dir gefundenen Teile kannst Du nehmen. > Wenn ich das richtig verstehe, wird der EMMC-Chip häufig direkt auf das > PCB gelötet. "häufig" ist untertrieben. "immer" ist richtig. > Sehe grade, die gibt es auch bei Mouser. > https://www.mouser.de/ProductDetail/ISSI/IS21ES16G-JCLI?qs=sGAEpiMZZMve4%2FbfQkoj%252BCMezv1v4I4kzQ49NTV34rA%3D > > Dort finde ich aber nur handverlötungs-unfreundliche BGA-Ball-Modelle. Genau. Es gibt sie auch nur in dieser Bauform. fchk
Es gibt SD-Karten die mit hoher Lebensdauer beworben werden. Diese sollten besser für den Anwendungsfall geeignet sein. z.B.: https://www.reichelt.de/microsdhc-speicherkarte-32gb-samsung-pro-endurance-sams-mb-mj32ga-p229370.html?&trstct=pol_6 Man kommt aber auch mit den (guten) normalen SD Karten weiter wenn man bestimmte Dinge beachtet: Möglichst nur eine Partition verwenden. Diese sollte so groß wie möglich sein. Dadurch kann das Dateisystem die Schreibzugriffe besser auf die gesamte SD verteilen. F2FS verwenden. Dieses wurde von Samsung speziell für SD/MMC Speicher entwickelt. In den meisten Fällen kann man ein tmpfs über /tmp und /var/tmp mounten. (Letzteres nicht ganz konform aber normalerweise problemlos) Dadurch vermeidet man schon eine Menge Schreibzugriffe. Syslog/systemd so konfigurieren das nicht unnötig Log-Dateien angelegt/geschrieben werden. Prüfen ob alle Programme so konfiguriert sind, dass nur notwendiges geloggt wird und nicht haufenweise Debug-Ausgaben mit auf der Platte landen.
Diese Module kanne ich noch gar nicht, Danke für die Info! Frank K. schrieb: >> Wenn ich das richtig verstehe, wird der EMMC-Chip häufig direkt auf das >> PCB gelötet. > > "häufig" ist untertrieben. "immer" ist richtig. Da kann man mit der Lupe und Cu-Lack-Draht definitiv was machen löttechnisch, ist aber frickel. Zum Glück müssen nicht alle Punkte angeschlossen werden. @Andreas: Danke für den Tip mit der 'SAMS MB-MJ32GA MicroSDHC-Speicherkarte 32GB - Samsung - PRO Endurance'! Andreas M. schrieb: > Möglichst nur eine Partition verwenden. Diese sollte so groß wie möglich > sein. Dadurch kann das Dateisystem die Schreibzugriffe besser auf die > gesamte SD verteilen. Also in einer einzigen Partition den kompletten Speicher zu 100,000% nutzen (und kein einziges MB frei lassen)? > F2FS verwenden. Dieses wurde von Samsung speziell für SD/MMC Speicher > entwickelt. Interessant, hier findet man mehr dazu: https://de.wikipedia.org/wiki/F2FS https://en.wikipedia.org/wiki/F2FS Andreas M. schrieb: > In den meisten Fällen kann man ein tmpfs über /tmp und /var/tmp mounten. > (Letzteres nicht ganz konform aber normalerweise problemlos) Dadurch > vermeidet man schon eine Menge Schreibzugriffe. > > Syslog/systemd so konfigurieren das nicht unnötig Log-Dateien > angelegt/geschrieben werden. Prüfen ob alle Programme so konfiguriert > sind, dass nur notwendiges geloggt wird und nicht haufenweise > Debug-Ausgaben mit auf der Platte landen. Das sagt mir leider nicht so viel. Sind das Linux- oder Raspi-spezifische Sachen? (Eventuell kann mein linuxerfahrener Mitbastler mehr damit anfangen, wird sich am WE zeigen, wenn der Raspi dann da ist, DHL hat irgendwie grade einen logistischen Hänger)
DC schrieb: > Diese Module kanne ich noch gar nicht, Danke für die Info! > > > Frank K. schrieb: >>> Wenn ich das richtig verstehe, wird der EMMC-Chip häufig direkt auf das >>> PCB gelötet. >> >> "häufig" ist untertrieben. "immer" ist richtig. > > Da kann man mit der Lupe und Cu-Lack-Draht definitiv was machen > löttechnisch, ist aber frickel. Zum Glück müssen nicht alle Punkte > angeschlossen werden. DDR400 ist kein Pappenstiel.
> Andreas M. schrieb: >> Möglichst nur eine Partition verwenden. Diese sollte so groß wie möglich >> sein. Dadurch kann das Dateisystem die Schreibzugriffe besser auf die >> gesamte SD verteilen. > > Also in einer einzigen Partition den kompletten Speicher zu 100,000% > nutzen (und kein einziges MB frei lassen)? Nein, du kannst schon Speicher frei lassen. Der Hintergrund ist ein anderer: Unter Linux ist es üblich, das man mehrere Partitionen anlegt und so eine trennung zwischen Programmen und Daten bekommt. Z.b. legt man normalerweise eine kleinere Partition for das "root" nehmen und eine größere für die Nutzerdaten unter "/home". Dadurch kann man z.B. problemlos das gesamte System neu installieren (inklusive formattieren der "root" partition) ohne die Nutzerdaten zu verlieren. Für SD-Karten ist das nicht unbedingt gut. Denn Schreibvorgänge auf dem "root" würden dann nur innhalb des Addressbereiches der "root" partition passieren, entsprechendes gilt für Schreibvorgänge innerhalb des "home". Um die Lebensdauer zu erhöhen, muss eine SD-Karte die Schreibzugriffe intern jedoch auf den gesamten Flash verteilen. Das funktioniert dann nicht mehr so gut, wenn man die SD-Karte in mehrere Bereiche aufteilt. Wenn man jedoch nur eine große Parition, die die gesamte SD-Karte nutzt verwendet, und am besten noch mit einem für Flash geeignetem Dateisystem, z.B. BTRFS oder F2FS formatiert, dann ist es einfacher für die SD-Karte die Schreibvorgänge über den gesamten Flash Speicher zu verteilen und so die Flash-Zellen gleichmäßig auszulasten. Es gibt inzwischen diverse Mechanismen zwischen Betriebssystem und Flash basierten Speichern um die Lebensdauer zu erhöhen. Man kann oder konnte sich z.B. auch bei einer SSD ins Knie schießen: - Man legt auf einer SSD zunächst eine Partition/Laufwerk mit voller Größe an und schreibt diese sehr voll. (Bei manchen SSDs ist dieser Schritt nicht notwendig) - Dann löscht man die Partition wieder und legt eine viel kleinere an. - Nun wird auschließlich dieser kleine Bereich genutzt. Das führt dazu, das die SSD für Schreibzugriffe nur den kleinen Teil des Flashspeichers nutzen kann, der der kleinen Partition zugeordnet ist. Da in dem restlichen, ungenutzen Bereich ja auch schon mal Daten geschrieben worden sind und die SSD nicht mitbekommt das diese Daten nicht mehr gebraucht werden kann sie diesen großen ungenutzen Flash-Bereich auch nicht für Schreibzugriffe nutzen -> die SSD geht schneller kaputt. > Andreas M. schrieb: >> In den meisten Fällen kann man ein tmpfs über /tmp und /var/tmp mounten. >> (Letzteres nicht ganz konform aber normalerweise problemlos) Dadurch >> vermeidet man schon eine Menge Schreibzugriffe. >> >> Syslog/systemd so konfigurieren das nicht unnötig Log-Dateien >> angelegt/geschrieben werden. Prüfen ob alle Programme so konfiguriert >> sind, dass nur notwendiges geloggt wird und nicht haufenweise >> Debug-Ausgaben mit auf der Platte landen. > > Das sagt mir leider nicht so viel. Sind das Linux- oder > Raspi-spezifische Sachen? Das ist vorallendingen Linux. DDein Mitbastler weis sicher was ich damit meine.
Hallo Andreas M. schrieb: > Unter Linux ist es üblich, das man mehrere Partitionen anlegt und so > eine trennung zwischen Programmen und Daten bekommt. Z.b. legt man > normalerweise eine kleinere Partition for das "root" nehmen und eine > größere für die Nutzerdaten unter "/home". Dadurch kann man z.B. Unter alles unter /bin /sbin usw. sind was? > Für SD-Karten ist das nicht unbedingt gut. Denn Schreibvorgänge auf dem > "root" würden dann nur innhalb des Addressbereiches der "root" partition > passieren, entsprechendes gilt für Schreibvorgänge innerhalb des "home". Das ist Unsinn. Eine SD-Karte hat überhaupt keine Idee, was eine Partition ist. Die kennt primär mal nur Blöcke und ab SDXC sogar ein FS, nämlich exFAT. > Um die Lebensdauer zu erhöhen, muss eine SD-Karte die Schreibzugriffe > intern jedoch auf den gesamten Flash verteilen. Das funktioniert dann Tut sie auch. Blöcke sind Hardware, Partitionen logisches Level. > nicht mehr so gut, wenn man die SD-Karte in mehrere Bereiche aufteilt. Das ist Festplattendenke mit rotierendem Blech, wo Partitionen mit Sektoren verknüpft wurden. Bei Flashspeicher sind die Sektoren, mit denen die Partitionen verbunden sind aber auch nur logisches Level und werden selbst erst auf Hardwareblöcke gemappt. Andreas M. schrieb: > Es gibt inzwischen diverse Mechanismen zwischen Betriebssystem und Flash > basierten Speichern um die Lebensdauer zu erhöhen. Man kann oder konnte > sich z.B. auch bei einer SSD ins Knie schießen: > > - Man legt auf einer SSD zunächst eine Partition/Laufwerk mit voller > Größe an und schreibt diese sehr voll. (Bei manchen SSDs ist dieser > Schritt nicht notwendig) > - Dann löscht man die Partition wieder und legt eine viel kleinere an. > - Nun wird auschließlich dieser kleine Bereich genutzt. Ich mag's nur ungerne schreiben, aber auch das ist leider Unsinn, der allenfalls für SSD aus dem letzten Jahrtausend gelten mag. Was Du beschreibst, ist "Dynamic Wear Leveling". Das mögen heute USB-Sticks und SD-Karten verwenden. Damit wären aber die heute angebenen TBW bei SSD kaum erreichbar. Andreas M. schrieb: > Das führt dazu, das die SSD für Schreibzugriffe nur den kleinen Teil des > Flashspeichers nutzen kann, der der kleinen Partition zugeordnet ist. Da > in dem restlichen, ungenutzen Bereich ja auch schon mal Daten > geschrieben worden sind und die SSD nicht mitbekommt das diese Daten > nicht mehr gebraucht werden kann sie diesen großen ungenutzen > Flash-Bereich auch nicht für Schreibzugriffe nutzen -> die SSD geht > schneller kaputt. Nö, SSD arbeiten mindestens mit "Static Wear Leveling". Micron schreibt dazu in www.micron.com/-/media/client/global/documents/products/technical-note/n and-flash/tn2942_nand_wear_leveling.pdf "Static data is managed by maintaining all blocks within a certain erase count threshold. Blocks that contain static data with erase counts that begin to lag behind other blocks will be included in the wear-leveling block pool, with the static data being moved to blocks with higher erase counts." Statische Blöcke, also Daten, die sich nicht ändern, werden vom Controller bei Bedarf auf dynamische Blöcke (die schon oft beschrieben wurden) umkopiert und umgekehrt. So kann man eine einigermaßen gleichmäßige Nutzung aller Blöcke erreichen. Die Technical Notes von Micron sind übrigens hervorragend geeignet, Wissen in dem Bereich abzurunden. MfG
M.M.M schrieb: > Hallo > > Andreas M. schrieb: >> Unter Linux ist es üblich, das man mehrere Partitionen anlegt und so >> eine trennung zwischen Programmen und Daten bekommt. Z.b. legt man >> normalerweise eine kleinere Partition for das "root" nehmen und eine >> größere für die Nutzerdaten unter "/home". Dadurch kann man z.B. > > Unter alles unter /bin /sbin usw. sind was? Frage bitte nochmal so stellen das ich verstehe was Du meinst. >> Für SD-Karten ist das nicht unbedingt gut. Denn Schreibvorgänge auf dem >> "root" würden dann nur innhalb des Addressbereiches der "root" partition >> passieren, entsprechendes gilt für Schreibvorgänge innerhalb des "home". > > Das ist Unsinn. Eine SD-Karte hat überhaupt keine Idee, was eine > Partition ist. Die kennt primär mal nur Blöcke und ab SDXC sogar ein FS, > nämlich exFAT. Nein ist es nicht, der in SD Karten eingebaute Controller hat sehr wohl eine gewisse Intelligenz. Gerade bei den älteren Karten haben die Controller versucht Partitionen und Dateissteme zu erkennen um mit dem Wissen daraus das Wear-Leveling zu optimieren. Der Hinweis aus vielen Beidenungsanleitungen, die vorformatierten Karten nicht neu zu formatieren kommt nicht von ungefähr. > Das ist Festplattendenke mit rotierendem Blech, wo Partitionen mit > Sektoren verknüpft wurden. Bei Flashspeicher sind die Sektoren, mit > denen die Partitionen verbunden sind aber auch nur logisches Level und > werden selbst erst auf Hardwareblöcke gemappt. Intern in der MMC schon. Das Betriebssystem selbst mappt da gar nichts. Auch bei einer SSD mappt das Betriebssystem nichts. Addressierung einer SSD von außen geschieht exakt identisch zu der einer normalen HDD. Wenn das anders wäre könnte man in alte Rechner ja keine SSDs einbauen. > Andreas M. schrieb: >> Es gibt inzwischen diverse Mechanismen zwischen Betriebssystem und Flash >> basierten Speichern um die Lebensdauer zu erhöhen. Man kann oder konnte >> sich z.B. auch bei einer SSD ins Knie schießen: >> >> - Man legt auf einer SSD zunächst eine Partition/Laufwerk mit voller >> Größe an und schreibt diese sehr voll. (Bei manchen SSDs ist dieser >> Schritt nicht notwendig) >> - Dann löscht man die Partition wieder und legt eine viel kleinere an. >> - Nun wird auschließlich dieser kleine Bereich genutzt. > > Ich mag's nur ungerne schreiben, aber auch das ist leider Unsinn, der > allenfalls für SSD aus dem letzten Jahrtausend gelten mag. Was Du > beschreibst, ist "Dynamic Wear Leveling". Das mögen heute USB-Sticks und > SD-Karten verwenden. Damit wären aber die heute angebenen TBW bei SSD > kaum erreichbar. > > Andreas M. schrieb: >> Das führt dazu, das die SSD für Schreibzugriffe nur den kleinen Teil des >> Flashspeichers nutzen kann, der der kleinen Partition zugeordnet ist. Da >> in dem restlichen, ungenutzen Bereich ja auch schon mal Daten >> geschrieben worden sind und die SSD nicht mitbekommt das diese Daten >> nicht mehr gebraucht werden kann sie diesen großen ungenutzen >> Flash-Bereich auch nicht für Schreibzugriffe nutzen -> die SSD geht >> schneller kaputt. > > Nö, SSD arbeiten mindestens mit "Static Wear Leveling". Micron schreibt > dazu in > www.micron.com/-/media/client/global/documents/products/technical-note/n and-flash/tn2942_nand_wear_leveling.pdf > > "Static data is managed by maintaining all blocks within a certain > erase count threshold. Blocks that contain static data with erase counts > that begin to lag > behind other blocks will be included in the wear-leveling block pool, > with the static data > being moved to blocks with higher erase counts." > > Statische Blöcke, also Daten, die sich nicht ändern, werden vom > Controller bei Bedarf auf dynamische Blöcke (die schon oft beschrieben > wurden) umkopiert und umgekehrt. So kann man eine einigermaßen > gleichmäßige Nutzung aller Blöcke erreichen. Richtig, aber wenn eine SSD "weis", dass ein statischer Block deswegen statisch ist, weil er garn nicht mehr benutzt wird, dem Betriebssystem der Inhalt also komplett egal ist, dann brauch dar gar nichts umkopiert werden. Diese Information bekommt die SSD aber nur dann wenn die betreffenden Blöcke weiterhin zu einem Dateisystem gehören, denn nur dann kann das Betriebssystem diese Information an die SSD senden... Wenn ich aber die Platte komplett zuschreibe und dann nur noch einen kleinen Teil für das Dateisystem nehme, dann bekommt die SSD diese Information nicht, muss also davon ausgehen, das die Daten noch gebraucht werden und wird diese munter auf dem Flash hin und her schieben statt sie einfach zu verwerfen. Gruß Andreas
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.