Hi, also, das folgende Problem lässt mir keine Ruhe :-) Situation: Kleinrechner mit 1GHz Dualcore-CPU im SoC (Allwinner A20) mit integriertem SATA-II-Controller (d.h. 300 MB/s max. möglich). Test-Hardware hier: Banana Pi M1 und Banana P1 R1 (aka Lamobo R1). Ist-Zustand: Die SATA-Lesegeschwindigkeit von SSD beträgt etwas über 200 MB/s und die Schreibgeschwindigkeit ca. 132 MB/s (bei beiden gemessen mittels dd mit Blockgrössen 8K, 12K, 16K). Problem: Die volle SATA-II-Geschwindigkeit von 300 MB/s wird nicht erreicht. Frage: Meint ihr nicht auch, dass die Leistung dieser Dualcore CPU mehr als ausreichend für SATA-II ist? Woran könnte es denn dann liegen, dass die volle Geschwindigkeit von 300 MB/s, insb. beim Lesen, nicht erreicht wird? Bin für alle konstruktiven Ideen und Vorschläge dankbar, die helfen dieses Problem bei diesen o.g. Geräten (bzw. allen ähnlichen Geräten die den selben Linux-SATA-Treiber ahci_sunxi benutzen) zu beheben. Thx
:
Bearbeitet durch User
Martin schrieb: > Da gab es doch erst hier vor kurzem einen beitrag zu. Der Treiber ist es > wohl. Ja, genau diese Geschichte geht eben noch weiter. Im Treiber wurde eine Verbesserung eingebaut, die die Schreibgeschwindkeit von ca. 40 MB/s auf jetzt um die 132 MB/s gesteigert hat. Aber das ist mMn immer noch nicht das Ende der Fahnenstange. Da sollte mMn mehr drin sein.
Meine Vermutung geht in Richtung DMA. Aber es heisst dass das SATA-Modul in dieser SoC einen eigenen integrierten DMA benutzen würde. Vlt. ist der nicht richtig initialisiert im Treiber. Ich kenne mich mit Initialisierung von DMA leider nicht aus, muss mich auch erst einlesen. Aber vlt. hat jemand eine Vermutung oder Idee diesbezüglich, was alles passieren kann wenn DMA nicht richtig initialisiert wurde, also ob die beobachteten Symptome tatsächlich auf DMA hindeuten. Hier kann man die Handbücher zu dieser SoC finden: https://github.com/allwinner-zh/documents/tree/master/A20
:
Bearbeitet durch User
Mutluit M. schrieb: > Frage: > Meint ihr nicht auch, dass die Leistung dieser Dualcore CPU mehr als > ausreichend für SATA-II ist? wenn der nix anderes Tut :D
ACDC schrieb: > Mutluit M. schrieb: >> Frage: >> Meint ihr nicht auch, dass die Leistung dieser Dualcore CPU mehr als >> ausreichend für SATA-II ist? > > wenn der nix anderes Tut :D Also, am HDMI und USB hängen keine Geräte dran, eine Desktop-GUI hat das System nicht (ist nicht installiert), und WLAN und BT sind nicht aktiviert. Nur Ethernet ist aktiv, da auch nur ein ssh-login wo nichts grossartiges passiert. Ich habe den Interrupts von Ethernet und SATA jeweils verschiedene CPU-cores zugeordnet: es bringt zwar etwas Verbesserung ein, aber der grosse Durchbruch fehlt noch. Die Temperatur ist nur etwa 26C beim R1. Und die CPU-cores sind im Leerlauf fast 100% Idle, also da ist praktisch nichts am Laufen was die CPU-cores bremsen würde. Langsam kommt bei mir Zweifel auf, ob das Problem nicht am Linux selbst liegt :-)
:
Bearbeitet durch User
Der kleine ARM-SoC ist nunmal kein IO-Monster (insbesondere kann man ihn nicht mit x86-CPUs mit gleichem Takt vergleichen), und man sollte auch mal schauen, ob der SATA-Controller nicht, wie bei einigen anderen Boards, über den USB-Controller dranhängt. Auch wäre zu prüfen, ob das SSD überhaupt mehr hergeben kann – mal an einen richtigen Rechner klemmen und gucken, was da für Zahlen rausfallen?
Mutluit M. schrieb: > Kleinrechner mit 1GHz Dualcore-CPU im SoC (Allwinner A20) mit > integriertem SATA-II-Controller (d.h. 300 MB/s max. möglich). Dieses Forum ist, was dein Problem betrifft, der falsche Ansprechpartner. Auf den Mailinglisten von linux-sunxi (bzw. dessen IRC) wirst du wahrscheinlich auf mehr Leute treffen, die diese SoCs im Detail kennen. Die einzigen Allwinner-Geräte, die ich hier habe, haben kein SATA. Mutluit M. schrieb: > Woran könnte es denn dann liegen, dass die volle Geschwindigkeit > von 300 MB/s, insb. beim Lesen, nicht erreicht wird? Bist du dir sicher, dass die internen Busse (zwischen CPU/DMA und SATA, also AHB) überhaupt schnell genug sind? Liegt da sonstiger Traffic drauf, und wenn ja, welcher? Besitzt der SATA-Block selbst genug Bandbreite, um die 300 MB/s zu verarbeiten? Allgemeiner gefragt: Gibt es überhaupt Software (z.B. BSP-Kernel von Allwinner), die mehr aus dem SoC rausholt? Mutluit M. schrieb: > Langsam kommt bei mir Zweifel auf, ob das Problem > nicht am Linux selbst liegt :-) Das ist ebenfalls möglich, schließlich liegen zwischen "dd" und "Gerät" mehrere Softwaresschichten. Du kannst ja testweise den AHCI-Treiber aus Linux ausbauen und einen minimalen Treiber (bare metal) als Maßstab benutzen. Aber wie gesagt, in diesem Forum bist du mit deinem Problem eher falsch. Obwohl ich es gut finde, wenn jemand den Allwinner-Chipsätzen zu besserem Support verhilft.
Jack V. schrieb: > Der kleine ARM-SoC ist nunmal kein IO-Monster (insbesondere kann man ihn > nicht mit x86-CPUs mit gleichem Takt vergleichen), Aber in der SSD/HDD selbst werkelt doch eine noch kleinere CPU drin, sogar so ein oller 8051-CPU aus dem letzten Jahrtausend: der schafft es doch auch, sogar SATA-III mit seinen 600 MB/s. > und man sollte auch > mal schauen, ob der SATA-Controller nicht, wie bei einigen anderen > Boards, über den USB-Controller dranhängt. Ist schon geklärt: das ist hier nicht der Fall; USB und SATA sind definitiv getrennt voneinander. > Auch wäre zu prüfen, ob das > SSD überhaupt mehr hergeben kann – mal an einen richtigen Rechner > klemmen und gucken, was da für Zahlen rausfallen? Also, das ist schon gegeben: die SSD hat sowieso vorher am Laptop gehangen, da bringt sie um die 500 MB/s (die SSD ist SATA-III). Und auch verschiedene SSDs wurden getestet.
:
Bearbeitet durch User
Mutluit M. schrieb: > Aber in der SSD/HDD selbst werkelt doch eine noch > kleinere CPU drin, sogar so ein oller 8051-CPU > aus dem letzten Jahrtausend: der schafft es > doch auch, sogar SATA-III mit seinen 600 MB/s. Nö, der schafft das nicht. Der spricht ein bisschen Protokoll und steuert ein bisschen Logik an. Der eigentliche Datentransfer läuft an dem Controller komplett vorbei.
S. R. schrieb: > Mutluit M. schrieb: >> Aber in der SSD/HDD selbst werkelt doch eine noch >> kleinere CPU drin, sogar so ein oller 8051-CPU >> aus dem letzten Jahrtausend: der schafft es >> doch auch, sogar SATA-III mit seinen 600 MB/s. > > Nö, der schafft das nicht. Der spricht ein bisschen Protokoll und > steuert ein bisschen Logik an. > > Der eigentliche Datentransfer läuft an dem Controller komplett vorbei. Komm, erzähl weiter! :-)
c.m. schrieb: > was sagt "hdparm -tT /dev/sdX"? > besonders die cache reads? root@r1-3:~# hdparm -tT /dev/sda /dev/sda: Timing cached reads: 912 MB in 2.00 seconds = 455.44 MB/sec Timing buffered disk reads: 574 MB in 3.00 seconds = 191.08 MB/sec root@r1-3:~# hdparm -tT /dev/sdb /dev/sdb: Timing cached reads: 854 MB in 2.00 seconds = 426.47 MB/sec Timing buffered disk reads: 570 MB in 3.01 seconds = 189.39 MB/sec
Da ist gerade ein interessanter Patch zu libata reingekommen, obwohl es für ein anderes Problem gedacht ist, aber wenn man die Beschreibung durchliesst, dann könnte es evtl. auch für dieses Problem nützlich sein: https://marc.info/?t=155815645100001&r=1&w=2 libata sitzt ja auf dem SATA-Treiber drauf.
Mutluit M. schrieb: > Aber in der SSD/HDD selbst werkelt doch eine noch kleinere CPU drin, Naja, aber das Dings muss seine Daten irgendwo abliefern, bzw. von irgendwoher bekommen.
Mutluit M. schrieb: > c.m. schrieb: >> was sagt "hdparm -tT /dev/sdX"? >> besonders die cache reads? > > root@r1-3:~# hdparm -tT /dev/sda > /dev/sda: > Timing cached reads: 912 MB in 2.00 seconds = 455.44 MB/sec > Timing buffered disk reads: 574 MB in 3.00 seconds = 191.08 MB/sec > > root@r1-3:~# hdparm -tT /dev/sdb > /dev/sdb: > Timing cached reads: 854 MB in 2.00 seconds = 426.47 MB/sec > Timing buffered disk reads: 570 MB in 3.01 seconds = 189.39 MB/sec Hi c.m., du wolltest diese Werte ja sehen. Was sagen sie dir?
Mutluit M. schrieb: > Da ist gerade ein interessanter Patch zu libata reingekommen, > obwohl es für ein anderes Problem gedacht ist, aber wenn man > die Beschreibung durchliesst, dann könnte es evtl. auch für dieses > Problem nützlich sein: > https://marc.info/?t=155815645100001&r=1&w=2 > libata sitzt ja auf dem SATA-Treiber drauf. Hmm. evtl. habe ich da etwas verwechselt, scheint doch nicht für dieses Problem relevant zu sein. Sorry.
S. R. schrieb: > Mutluit M. schrieb: >> Kleinrechner mit 1GHz Dualcore-CPU im SoC (Allwinner A20) mit >> integriertem SATA-II-Controller (d.h. 300 MB/s max. möglich). > > Dieses Forum ist, was dein Problem betrifft, der falsche > Ansprechpartner. Auf den Mailinglisten von linux-sunxi (bzw. dessen IRC) > wirst du wahrscheinlich auf mehr Leute treffen, die diese SoCs im Detail > kennen. Also, ich habe den Eindruck dass in den Mailinglisten gar nicht mehr gross diskutiert wird, sondern nur Patches gepostet und kurz besprochen werden. Aber so eine Fehlersuche werden die wohl nicht machen. Ok, IRC sollte ich mir vlt. wieder mal nach einer Dekade oder so nochmal zulegen; dabei habe ich das Ding immer gehasst, weil nicht effektiv... :-) > Die einzigen Allwinner-Geräte, die ich hier habe, haben kein SATA. > > Mutluit M. schrieb: >> Woran könnte es denn dann liegen, dass die volle Geschwindigkeit >> von 300 MB/s, insb. beim Lesen, nicht erreicht wird? > > Bist du dir sicher, dass die internen Busse (zwischen CPU/DMA und SATA, > also AHB) überhaupt schnell genug sind? Liegt da sonstiger Traffic > drauf, und wenn ja, welcher? Besitzt der SATA-Block selbst genug > Bandbreite, um die 300 MB/s zu verarbeiten? Tja, gute Fragen. Ich gebe sie mal weiter... :-) > Allgemeiner gefragt: Gibt es überhaupt Software (z.B. BSP-Kernel von > Allwinner), die mehr aus dem SoC rausholt? Wenn ich das wüsste... Ich habe erst seit wenigen Monaten mit dieser SoC von Allwinner zu tun, kenne mich folglich noch nicht besonders gut aus in dessen Features und Limits. > Mutluit M. schrieb: >> Langsam kommt bei mir Zweifel auf, ob das Problem >> nicht am Linux selbst liegt :-) > > Das ist ebenfalls möglich, schließlich liegen zwischen "dd" und "Gerät" > mehrere Softwaresschichten. Du kannst ja testweise den AHCI-Treiber aus > Linux ausbauen und einen minimalen Treiber (bare metal) als Maßstab > benutzen. Ja, würde ich gerne machen. Aber geht das denn so einfach? Ich müsste ja praktisch die ganze Funktionalität von libata neuschreiben, oder wie, oder was? Gibt's dazu vlt. ein Bsp-Code/Skelleton irgendwo? Es würde aber am fehlenden SATA-Handbuch von Allwinner scheitern :-( > Aber wie gesagt, in diesem Forum bist du mit deinem Problem eher falsch. > Obwohl ich es gut finde, wenn jemand den Allwinner-Chipsätzen zu > besserem Support verhilft. Wieso, in A20 ist doch auch eine MCU drin, und dieses Forum ist doch über MCUs, oder habe ich da was falsch verstanden?
:
Bearbeitet durch User
Mutluit M. schrieb: > Kleinrechner mit 1GHz Dualcore-CPU im SoC (Allwinner A20) mit > integriertem SATA-II-Controller (d.h. 300 MB/s max. möglich). Hat der überhaupt den RAM schnell genug angebunden um die 300MB/s theoretisch ausnutzen zu können? Die kleinen Chips haben doch oft auch einen relativ schmal eingebundenen RAM. Mutluit M. schrieb: > Timing cached reads: 854 MB in 2.00 seconds = 426.47 MB/sec Hui, da ist der RAM wohl wirklich zu lahm, isbesondere wenn da noch Grafik o.ä. mit dran hängt. Zum Vergleich:
1 | # PC mit DDR2-800, 128 Bit |
2 | Timing cached reads: 2200 MB in 2.00 seconds = 1100.59 MB/sec |
3 | |
4 | # PC mit DDR-3 (Takt habe ich vergessen) 128 Bit |
5 | Timing cached reads: 5056 MB in 2.00 seconds = 2529.15 MB/sec |
Die 300 MB/s würden die RAM Anbindung beim OP zu mehr als 50% auslasten...
Mutluit M. schrieb: >> Der eigentliche Datentransfer läuft >> an dem [8051] Controller komplett vorbei. > Komm, erzähl weiter! :-) Bei SD-Karten gibt es einen Controller, der das SD-Protokoll zum Host spricht (ist auch oft ein 8051). Der muss nicht schnell sein, denn er verarbeitet nur die Requests vom Host. Neben dem Controller gibt es dann noch einen separaten DMA-Controller, der vom 8051 gesteuert wird und mit den Datenpins gemultiplext wird. Das heißt, die Daten fließen vom NAND-Baustein direkt zu den Pins und nicht durch den 8051 durch. Ich gehe mal schlicht davon aus, dass eine SSD nicht anders aufgebaut ist. Die Steuerlogik interessieren die Daten ohnehin nicht, also kann man die auch einfach vorbeileiten. Mutluit M. schrieb: > Also, ich habe den Eindruck dass in den Mailinglisten gar nicht > mehr gross diskutiert wird, sondern nur Patches gepostet und kurz > besprochen werden. Richtig, weil die eigentliche Diskussion oft im IRC stattfindet. Niemand will die gesamte Mailingliste mit Informationen zuspammen, die vielleicht nur 2-3 Leute interessieren. Mutluit M. schrieb: > Ok, IRC sollte ich mir vlt. wieder mal nach einer Dekade > oder so nochmal zulegen; dabei habe ich das Ding immer gehasst, > weil nicht effektiv... :-) Bei sämtlichen (halbwegs aktiven) Opensource-Projekten bin ich im IRC immer zügig auf kompetente Personen getroffen. Natürlich muss man ein Auge auf die Zeitzonen haben, ansonsten ist das übliche Vorgehen, dass man seine Frage stellt und dann wartet, bis jemand reagiert. Mutluit M. schrieb: >> Gibt es überhaupt Software (z.B. BSP-Kernel von >> Allwinner), die mehr aus dem SoC rausholt? > Wenn ich das wüsste... Die Grundannahme ist, dass Allwinner die Chips genauer kennt als die Opensource-Community, die ausschließlich mit (reduzierten) Datenblättern und Reverse Engineering arbeiten muss. Meine Erfahrung ist, dass BSP-Kernel die Hardware besser unterstützen (dafür sind sie alt und mit schlechtem Code mies zusammengehackt). Mutluit M. schrieb: > Aber geht das [Treiber schreiben] denn so einfach? Nein. Aber du musst ja keinen vollständigen Linux-Treiber schreiben. Wieviel Aufwand das ist, kann ich nicht einschätzen, mit SATA kenne ich mich nicht aus; ich habe vor langer Zeit mal mit dem UIO-Framework gearbeitet - aber keine Ahnung, ob man damit 300 MB/s hinbekommen kann. Mutluit M. schrieb: >> Aber wie gesagt, in diesem Forum >> bist du mit deinem Problem eher falsch. > Wieso, in A20 ist doch auch eine MCU drin, und dieses Forum > ist doch über MCUs, oder habe ich da was falsch verstanden? Naja, die meisten Themen handeln von Elektronik, Programmieren, kleine Mikrocontroller (hauptsächlich 8-Bit AVR oder Cortex-M3/M4), Analog- oder Hardwaredesign. Dein A20 ist eine andere Hausnummer. Als Vergleich: Du kommst mit deinem halbwegs aktuellen Elektro-Hybridauto in ein Forum, was sich hauptsächlich mit Fahrrädern, Mopeds, Rasenmähern, Gabelstaplern und Traktoren befasst. Du bist also nicht komplett falsch, aber so richtig on-topic ist das auch nicht. :-)
:
Bearbeitet durch User
In der Theorie sind es 300 MB/s und in der Praxis sind 250 MB/s ein guter Wert. 300 MB/s ist die maximale Übertragungsgeschwindigkeit der Schnittstelle unter optimalen Bedingungen und damit kein Wert den du je messen können wirst. Selbst High End Systeme erreichen nur ca. 280 MB/s. Wenn aus sportlichem Ehrgeiz das Maximum rausgeholt werden soll ok. Wenn es aus Bedenken ist, dass die Performance darunter leidet: - Für Hochauflösende Inhalte ist die CPU/GPU zu lahm - Als NAS/Fileserver sind alle anderen Schnittstellen bedeutend langsamer - Für flüssiges Arbeiten ist die reine Übertragungsgeschwindigkeit völlig unwichtig. Selbst eine SSD an USB 2.0 (<60 MB/s) erzeugt einen Wow Effekt gegenüber einer HDD an Sata2 mit gemessenen 115 MB/s. Gleiche SSD an Sata2 mit ca. 250 MB/s gemessen ist nur ein minimaler Unterschied spürbar zu USB 2.0. Hier ist Lesestoff mit Tests warum das so ist (Seite 4 bis 7): https://www.tomshw.de/2013/04/22/ssd-upgrade-sata3_gbs-sata6_gbs/all/1/
MMn gehst du ziemlich blauäugig an die Sache ran. Nur, weil ein Standard eine bestimmte Datenrate spezifiziert, heißt das nicht, dass alle Nutzer diese auch voll ausreizen können - häufig ist genau das Gegenteil der Fall: man nimmt einen neueren, schnelleren Standard, bis die Geräte nicht mehr mithalten können. So ist sichergestellt, dass der Standard selbst nicht zum Flaschenhals wird und man das Gerät selbst voll ausreizen kann. So ein SoC ist kein trivialer Chip, es ist ein kompletter, ziemlich moderner Computer mit diversen, transaktionsgesteuerten Bussen (alle einzeln getaktet), ein oder mehre Busmatrixen, die die Busse verbinden (ggf mit Synchronisation, mit Zugriffsprioritäten, Buffern, etc) und ne riesige Zahl von angeschlossenen Geräten (inkl CPU, RAM, Flash, [3d-]Grafik). Das so zu konfigurieren, dass unter allen Betriebsbedingungen alle Geräte zuverlässig arbeiten, ist nicht trivial und braucht insb genaue Kenntnisse über die Verschaltung an sich, der zur Verfügung stehenden Bandbreiten und Transaktionsraten, sowie die benötigte Bandbreite und Latenz der einzelnen Geräte. Allwinner wird ordentlich gerechnet und experimentiert haben, bis sie ein zufriedenstellendes Setup gefunden haben - evtl mit dem Kompromiss, dass z.B. SATA oder Gb-Ethernet nicht die maximal mögliche Datenrate erreichen. Dafür läuft es dann aber auch mit einem einzelnen RAM-Chip sicher. Ich fand deinen SATA-Patch schon ziemlich bedenklich: du erhöhst mal einfach die Burstlänge des SATA-Kontrollers. Das bedeutet gleichzeitig, dass die Latenz für andere erhöht wird. Wenn man Pech hat, laufen jetzt FIFOs über und man hat Datenverlust (Sorry, das Ethernetpaket konnte ich nicht rechtzeitig ins RAM schreiben, hab's weggeschmissen; oder der Videokontroller erzeugt ein paar Blitzer, weil er nicht genügend schnell ans Video-RAM kommt). Im schlimmsten Fall gibt's Lock-ups und das ganze System steht. Sowas zu testen ist nicht trivial und benötigt einiges an Wissen und Erfahrung - ich bezweifel, dass du irgendwas in der Richtung getestet hast ...
Jim M. schrieb: > Mutluit M. schrieb: >> Kleinrechner mit 1GHz Dualcore-CPU im SoC (Allwinner A20) mit >> integriertem SATA-II-Controller (d.h. 300 MB/s max. möglich). > > Hat der überhaupt den RAM schnell genug angebunden um die 300MB/s > theoretisch ausnutzen zu können? Die kleinen Chips haben doch oft auch > einen relativ schmal eingebundenen RAM. > > Mutluit M. schrieb: >> Timing cached reads: 854 MB in 2.00 seconds = 426.47 MB/sec > > Hui, da ist der RAM wohl wirklich zu lahm, isbesondere wenn da noch > Grafik o.ä. mit dran hängt. > > Zum Vergleich: >
1 | > |
2 | > # PC mit DDR2-800, 128 Bit |
3 | > Timing cached reads: 2200 MB in 2.00 seconds = 1100.59 MB/sec |
4 | > |
5 | > # PC mit DDR-3 (Takt habe ich vergessen) 128 Bit |
6 | > Timing cached reads: 5056 MB in 2.00 seconds = 2529.15 MB/sec |
7 | > |
> > Die 300 MB/s würden die RAM Anbindung beim OP zu mehr als 50% > auslasten... Interessante Analyse, Jim. Danke. Ich möchte nicht overclocken. RAM bei diesen A20-Geräten ist mit 432 MHz getaktet (480 MHz sei auch möglich, habe ich irgendwo gelesen), CPU bis 960 MHz (oder bis 1008 MHz oder bis 1200 MHz in verschiedenen Aussagen). Für SATA werden 3 Takte benutzt (glaube ich): 100 MHz, und die von PLL6 und PLL62, s.u.). Ich weiss leider nicht an welchem der Busse das SATA-Modul angeschlossen ist bzw. betrieben wird (ARM hat ja einige solcher Busse). Kannst du mit den anderen Angaben unten etwas anfangen?
1 | # ./a.out |
2 | PLL1CTL : a1005410 |
3 | CPU : 960.00 MHz |
4 | SYSCLKDIV : 00020192 |
5 | ATB : 960.00 MHz |
6 | AXI : 320.00 MHz |
7 | AHB : 300.00 MHz |
8 | APB0 : 150.00 MHz |
9 | APB1CLKDIV: 00000000 |
10 | APB1 : 24.00 MHz |
11 | DRAM : 432.00 MHz |
12 | PLL5CTL : b1049291 |
13 | PLL5 : 864.00 MHz |
14 | SATA : 100.00 MHz |
15 | PLL6 : 600.00 MHz |
16 | PLL62 : 1200.00 MHz |
17 | MBUSCLK : 81000003 |
18 | MBUS : 300.00 MHz |
Heinz M. schrieb: > In der Theorie sind es 300 MB/s und in der Praxis sind 250 MB/s ein > guter Wert. 300 MB/s ist die maximale Übertragungsgeschwindigkeit der > Schnittstelle unter optimalen Bedingungen und damit kein Wert den du je > messen können wirst. Selbst High End Systeme erreichen nur ca. 280 MB/s. Also, ich habe gelesen dass bei SATA-2 das Maxiumum incl. des Protokolloverheads 375 MB/s sei, abzüglich des Overheads verbleiben 300 MB/s. Und beim SATA-3.0 750 MB/s Brutto, 600 MB/s Netto. Der Overhead kommt durch die 8b/10b Codierung bzw. Modulation. > Wenn aus sportlichem Ehrgeiz das Maximum rausgeholt werden soll ok. ja, auch :-) Ich denke dass die Performance dieser Boards für SATA-FullSpeed ausreichend ist, nur wundere ich mich, wieso es in der Praxis nicht erreicht wird, und möchte gerne den wahren Grund wissen bzw. lokalisieren woran es letzendlich liegt. > Wenn es aus Bedenken ist, dass die Performance darunter leidet: > - Für Hochauflösende Inhalte ist die CPU/GPU zu lahm > - Als NAS/Fileserver sind alle anderen Schnittstellen bedeutend > langsamer > - Für flüssiges Arbeiten ist die reine Übertragungsgeschwindigkeit > völlig unwichtig. Selbst eine SSD an USB 2.0 (<60 MB/s) erzeugt einen > Wow Effekt gegenüber einer HDD an Sata2 mit gemessenen 115 MB/s. Gleiche > SSD an Sata2 mit ca. 250 MB/s gemessen ist nur ein minimaler Unterschied > spürbar zu USB 2.0. > > Hier ist Lesestoff mit Tests warum das so ist (Seite 4 bis 7): > https://www.tomshw.de/2013/04/22/ssd-upgrade-sata3_gbs-sata6_gbs/all/1/ Interessant. Aber ich wundere mich, warum die Tester sich nicht gewundert haben darüber dass bei einigen/vielen der Tests die Lesegeschwindigkeit signifikant kleiner ausfällt als die Schreibgeschwindigkeit. Oder interpretiere vlt. nur ich das falsch?
foobar schrieb: > MMn gehst du ziemlich blauäugig an die Sache ran. Nur, weil ein > Standard eine bestimmte Datenrate spezifiziert, heißt das nicht, dass > alle Nutzer diese auch voll ausreizen können - häufig ist genau das > Gegenteil der Fall: man nimmt einen neueren, schnelleren Standard, bis > die Geräte nicht mehr mithalten können. So ist sichergestellt, dass der > Standard selbst nicht zum Flaschenhals wird und man das Gerät selbst > voll ausreizen kann. Wie ich schon sagte, ich denke die Leistung der SoC sollte ausreichend sein für SATA FullSpeed, zumindest für das (uncached) Lesen. > Ich fand deinen SATA-Patch schon ziemlich bedenklich: du erhöhst mal > einfach die Burstlänge des SATA-Kontrollers. Das bedeutet gleichzeitig, > dass die Latenz für andere erhöht wird. Wenn man Pech hat, laufen jetzt > FIFOs über und man hat Datenverlust (Sorry, das Ethernetpaket konnte ich > nicht rechtzeitig ins RAM schreiben, hab's weggeschmissen; oder der > Videokontroller erzeugt ein paar Blitzer, weil er nicht genügend schnell > ans Video-RAM kommt). Im schlimmsten Fall gibt's Lock-ups und das ganze > System steht. Sowas zu testen ist nicht trivial und benötigt einiges an > Wissen und Erfahrung - ich bezweifel, dass du irgendwas in der Richtung > getestet hast ... Das war zunächst praktisch nur eine Machbarkeitsstudie. Da ich nicht ein Fuhrpark voll mit all den betroffenen Boards habe, habe ich das Testen den Leuten überlassen (RFC - Request for Comments). Meine eigenen Tests an meinen beiden Banana Pi SBCs zeigen soweit keine Nachteile. Auch andere (z.B. Armbian und CNX, s.u.) die den Patch getestet haben, sagen dass es funktioniert und keine Nachteile ersichtlich sind. Der Thomas Kaiser hatte geschrieben dass er gerade Tage-/Wochenlange Stresstests durchführt mit einem anderen Dateisystem als ext4 (ich glaube Btrfs). https://www.cnx-software.com/2019/05/13/how-one-line-of-code-tripled-allwinner-a20-sata-write-performance/ https://forum.armbian.com/topic/10352-a20-sata-write-speed-improvement/?tab=comments#comment-78963
In diesem Zusammenhang suche ich noch ein weiteres SBC-Modell zum Testen: ich glaube der Banana Pi M2 Berry benutzt den selben Linux SATA Treiber ahci_sunxi (kann das jemand bestätigen?): Hier meine Suchanzeige hier: Beitrag "[S] Gebrauchten Banana Pi M2 Berry"
:
Bearbeitet durch User
Du merkst in der Praxis genausowenig Nachteile, wie Vorteile. Wenn du zum Beispiel die Blöcke sehr stark vergrößerst, mag das beim Test einiges bringen und schöne große Zahlen stehen auf dem Bildschirm. Was jedoch beim praktischen Betrieb zum Nachteil wird, weil mehr Speicherplatz belegt wird und immer große Blöcke geschrieben/gelesen werden müssen, obwohl keine großen Daten anfallen. Die 8b/10b Codierung ist der statische Teil des Overheads. Es gibt jedoch auch dynamische Teile, die zum Beispiel von der Sektorgröße, der Datenfragmentierung(ja das gibt es auch bei SSD) etc. abhängen. Aber auch Latenzzeiten der einzelnen Komponenten (z.B. Controller im PC, Controller in der SSD). Dann noch Zusatzfeatures die nicht jede SSD unterstützt und und und. Weil es bei so vielen Abhängigkeiten unmöglich ist zu sagen, dass die Schnittstelle ganz exakt 287,35846849 MB/s übertragen kann, sagt man einfach, dass bei gegebener Codierung und gegebenem Takt absolut maximal 300 MB/s theoretisch möglich wären. Also in der Praxis auf keinen Fall drüber, aber viel drunter. Schau zum Beispiel mal bei SSDs. SATA3 (600MB/s) SSDs sind immer angegeben als max. 550 MB/s lesen an SATA3 und max. 285 MB/s lesen an SATA2 (Werte können je nach Hersteller abweichen). Die SSD wäre schnell genug, aber die Schnittstelle schafft es nicht. Und wie gesagt bis auf ganz wenige Ausnahmen ist die maximale Übertragungsgeschwindigkeit völlig zu vernachlässigen und viel wichtiger ist die Latenz. Deswegen NVMe besser als SATA/IDE/USB/... SSD, besser als HDD. Und dann erst Erbsenzählerei der Übertragungsgeschwindigkeit. Schau mal ob du ein Tool wie Ksysguard drauf bekommst. Dort kannst du dir den Festplattendurchsatz anzeigen lassen und ihn unter realen Bedingungen beobachten. Edit: Wegen der ganzen Treiberproblematik suche ich gerade nach x86 SBCs.
:
Bearbeitet durch User
SATAn der 3. schrieb: > Mutluit M. schrieb: > >> root@r1-3:~# hdparm -tT /dev/sdb > > sdb? Hast du einen PMP an dem A20 hängen? Ja, zufällig :-) Hat aber nix mit dem Problem zu tun.
Heinz M. schrieb: > Du merkst in der Praxis genausowenig Nachteile, wie Vorteile. Wenn du > zum Beispiel die Blöcke sehr stark vergrößerst, mag das beim Test > einiges bringen und schöne große Zahlen stehen auf dem Bildschirm. Was > jedoch beim praktischen Betrieb zum Nachteil wird, weil mehr > Speicherplatz belegt wird und immer große Blöcke geschrieben/gelesen > werden müssen, obwohl keine großen Daten anfallen. > > Die 8b/10b Codierung ist der statische Teil des Overheads. Es gibt > jedoch auch dynamische Teile, die zum Beispiel von der Sektorgröße, der > Datenfragmentierung(ja das gibt es auch bei SSD) etc. abhängen. Aber > auch Latenzzeiten der einzelnen Komponenten (z.B. Controller im PC, > Controller in der SSD). Dann noch Zusatzfeatures die nicht jede SSD > unterstützt und und und. Weil es bei so vielen Abhängigkeiten unmöglich > ist zu sagen, dass die Schnittstelle ganz exakt 287,35846849 MB/s > übertragen kann, sagt man einfach, dass bei gegebener Codierung und > gegebenem Takt absolut maximal 300 MB/s theoretisch möglich wären. Also > in der Praxis auf keinen Fall drüber, aber viel drunter. > > Schau zum Beispiel mal bei SSDs. SATA3 (600MB/s) SSDs sind immer > angegeben als max. 550 MB/s lesen an SATA3 und max. 285 MB/s lesen an > SATA2 (Werte können je nach Hersteller abweichen). Die SSD wäre schnell > genug, aber die Schnittstelle schafft es nicht. Und wie gesagt bis auf > ganz wenige Ausnahmen ist die maximale Übertragungsgeschwindigkeit > völlig zu vernachlässigen und viel wichtiger ist die Latenz. Deswegen > NVMe besser als SATA/IDE/USB/... SSD, besser als HDD. Und dann erst > Erbsenzählerei der Übertragungsgeschwindigkeit. Ich orientiere mich einzig daran was dd ausspuckt. > Schau mal ob du ein Tool wie Ksysguard drauf bekommst. Dort kannst du > dir den Festplattendurchsatz anzeigen lassen und ihn unter realen > Bedingungen beobachten. Was KDE??? Nö, man, sowas kommt mir auf keinen Rechner, nichtmal auf den PC! :-) KDE ist sowas von Resourcenhungrig (3D-Zeugs) und IMO was für verspielte Gamer, also nix für mich :-) > Edit: Wegen der ganzen Treiberproblematik suche ich gerade nach x86 > SBCs. Also, ehrlich gesagt, ich habe die Schnauze voll von x86; die Zukunft gehört ARM und RISC-V :-) Es geht bei mir mehr um den Lerneffekt und Ausreizen der HW als um den produktiven Einsatz dessen.
:
Bearbeitet durch User
ksysguard läuft auch auf allen anderen Desktopumgebungen. Verwende es selbst auf LXDE, weil es viel umfangreicher ist als die Alternativen. Es gehen natürlich auch Alternativen. In der Regel heißt Zukunft bei ARM 2-4 Jahre. Dann endet der Softwaresupport des Herstellers und das Gefrickel beginnt. Bei x86 10-20 Jahre. Ein aktuelles Linux (mit abgespecktem Desktop) kann man meist ohne Probleme auf 10-20 Jahre alter Standard Hardware installieren. Klar sind ARMs viel günstiger und bei SBC gibt es viel kleinere und viel mehr Auswahl. Aber wenn ich bedenke, dass ich dann alle 2 Jahre viel Zeit für das Aufsetzen des neuen Systems benötige und in Summe das gleiche zahle, weil ich häufiger wechseln muss, dann nehme ich lieber den x86 wo die Chancen sehr gut stehen, dass jede x-beliebige Software läuft. ARM ist nur ein weiterer Schritt in der konsumgeilen Wegwerfgesellschaft.
Heinz M. schrieb: > ARM ist nur ein weiterer Schritt in der konsumgeilen > Wegwerfgesellschaft. Stimmt, da hast du recht. ABER: im kapitalistischen System bringt diese Vorgehensweise so eine Dynamik mit sich, dass der Fortschritt rasant ist, wie wir gerade jetzt erleben, also seit einigen Jahren schon. Ich meine, das muss kein Nachteil sein, wenn es auf der anderen Seite solch enorme Fortschritte mit sich bringt. Schon jetzt kann man 10 Gigabit Ethernet für ZuHause kaufen für um die €70 für 2 NICs mit Kabel. Ich finde die Entwicklungen der letzten Jahre so spannend, als da wären insb. die SSD-Revolution, NVMe, und jetzt kommen auch erschwingliche 10Gb Ethernet und natürlich auch CPUs mit mehr als 8 Kernen usw. usw. ARM trägt seinen Anteil an diesen erschwinglichen Entwicklungen. Vieles davon benutzt ARM-CPUs. Anders gesagt: ARM macht es möglich :-)
:
Bearbeitet durch User
x86 ... im Griff ? Aha. Kannst du selbst ein BIOS schreiben - natuerlich nicht. Kannst du einen Treiber schreiben, was Einfaches, zB Disk ? Ethernet ? USB ? SD Karte ? Was anderes ? - Natuerlich auch nicht. Du bist drauf angewiesen, dass jemand schon einen Treiber geschrieben hat.
99% der Leute Zuhause benutzen den PC um damit ins Internet zu gehen. 99% haben zwischen 6 und 50 Mbit/s Internet. Was bringt einem da eine 1 Gbit/s Netzwerkkarte, geschweige denn ein 10 Gbit/s für satte 70 €? Eine 20 Jahre alte 100 Mbit/s Netzwerkkarte würde es genauso tun. 99% lasten von den 8 Kernen nicht mal einen aus. 99% sind der Meinung, dass es mindestens SATA3 für eine SSD sein muss, dabei wird nicht mal annähernd die Grenze von SATA1 erreicht. Du kannst es dir zwar kaufen, aber du wirst es ohne es je ausgereizt zu haben wegwerfen. Und dennoch 99% der Leute wechseln ihr Smartphone spätestens alle 3 Jahre. Nicht falsch verstehen, ich bin selbst Hardwarefetischist, aber das ist kein Grund für mich alle 2 Jahre einen neuen PC zu kaufen, weil es einfach nichts bringt. Und das was du zu kaufen bekommst hat nichts mit der Entwicklung zu tun. Die Entwicklung ist immer einige Jahre voraus und es wird in kleinen Häppchen auf den Markt geworfen um ja viel Gewinn rausschlagen zu können. Wirklich bedeutende Entwicklungen (PCIe, SSD, Mehrkernprozessoren) die einen echten Mehrwert bringen und es sich dadurch lohnt den PC mal zu erneuern spielen sich über 10 bis 20 Jahre ab. Der schnellere Tausch von Elektronik ist nur der Produktlebenszyklus und ist nicht für die Entwicklung notwendig. Um beim Thema zu bleiben: Man schaue sich allein die Anzahl der Möglicheiten an, mit denen man eine SSD am PC anbinden kann, was runtergebrochen eigentlich nur 3 Entwicklungen sind: USB, SATA, PCIe. Alle modernen SSD Schnittstellen bauen darauf auf. In der Praxis merkt man kaum einen Unterschied zwischen den dreien (außer Spezialanwendungen), wohl aber zwischen HDD, SSD und verschiedenen SSD Generationen. Was einem zu der Frage bringt, wozu es so viele Schnittstellen für SSD gibt, wenn alle auf 3 Technologie basieren und innerhalb der Technologie der Mehrwert gegen 0 geht. Mit anderen Worten: So viele SSD Schnittstellen braucht kein Mensch. Edit: @ Dampfheuler: Ja klar ist man darauf angewiesen. Aber bei x86 sind die Treiber kompatibler. Das heißt wenn irgendwann mal jemand einen Treiber dafür geschrieben hat, dann ist die Wahrscheinlichkeit groß, dass es auf verwandten Systemen läuft. Bei ARM nicht.
:
Bearbeitet durch User
@Heinz M., es nennt sich Wettbewerb der Systeme oder Der Lauf der Geschichte. Z.B. Kampf USB vs. SATA: der andere muss mitziehen mit einem neuem, schnelleren Standard wenn er sein Marktanteil nicht an den anderen verlieren will... Kann man auch "Technische Evolution" bezeichnen :-) Ich finde es gut, schliesslichlich müssen wir so schnell wie möglich den Warp-Drive entwickeln und den Weltraum besiedeln, da es hier auf der Erde langsam zu eng wird und die Ressourcen zu neige gehen. Ich empfehle Star Trek Enterprise (insb. die Serie mit Captain Jonathan Archer :-) Gibt's auf netflix.de. Aber, wir kommen etwas vom Thema ab... :-)
:
Bearbeitet durch User
Heinz M. schrieb: > Ein aktuelles Linux (mit abgespecktem Desktop) kann man meist > ohne Probleme auf 10-20 Jahre alter Standard Hardware installieren. Dank der "Software-as-a-Service"-Idioten wird ein reiner Desktop aber zunehmend unhandlicher, weil die Software nicht nur veraltet, sondern total ausfällt, und die "Web-Development"-Idioten sorgen dafür, dass ein 15 Jahre alter PC nur noch eingeschränkt fürs Web taugt. Leider. Dampfheuler schrieb: > Kannst du selbst ein BIOS schreiben - natuerlich nicht. Kannst du ein BIOS für einen Qualcomm Snapdragon schreiben? Natürlich nicht. Obwohl da ein UEFI drauf läuft. > Kannst du einen Treiber schreiben, was Einfaches, > zB Disk ? Ethernet ? USB ? SD Karte ? > Was anderes ? - Natuerlich auch nicht. IDE, USB-MSC und viele SATA-Chipsätze sind frei dokumentiert. Ebenso viele Netzwerkchipsätze (vor allem Intel). Dokumente zu OHCI, UHCI und EHCI sind ebenso verfügbar. Bei SD-Karten ist die SPI-Ansteuerung offengelegt, wie man hier im Forum ständig sieht. Es hängt von der Hardware und ihrer Komplexität ab, ob ich das kann (und mit welcher Qualität). Aber glücklicherweise reicht es ja schon, wenn einer es kann (und die Quellen veröffentlicht). Nur geschlossene Systeme bedürfen einer ständigen Neuentwicklung unterschiedlicher Räder. Mutluit M. schrieb: > ABER: im kapitalistischen System bringt diese Vorgehensweise > so eine Dynamik mit sich, dass der Fortschritt rasant ist, > wie wir gerade jetzt erleben, also seit einigen Jahren schon. Ich finde es interessant, dass du auf der einen Seite die massive Verschwendung von Resourcen im Namen des "Fortschritts" gutheißt, während du auf der anderen Seite den Resourcenmangel auf der Erde als Begründung für "wir müssen den Weltraum erobern" nimmst. Das ist selbstverschuldet.
S. R. schrieb: > Mutluit M. schrieb: >> ABER: im kapitalistischen System bringt diese Vorgehensweise >> so eine Dynamik mit sich, dass der Fortschritt rasant ist, >> wie wir gerade jetzt erleben, also seit einigen Jahren schon. > > Ich finde es interessant, dass du auf der einen Seite die massive > Verschwendung von Resourcen im Namen des "Fortschritts" gutheißt, > während du auf der anderen Seite den Resourcenmangel auf der Erde als > Begründung für "wir müssen den Weltraum erobern" nimmst. Das ist > selbstverschuldet. Ist mMn alles nur Pipifax. Wenn wir erstmal den Weltraum erobern, dann kann jeder einzelne Erdenbürger sich seinen eigenen Planeten/Mond/Sonne etc.in Besitz nehmen, gibt ja Billionen von denen da draussen im Weltraum. Was fehlt ist der Warp-Drive. Und dafür lohnt es sich wenn die Entwicklung auch chaotisch, unkoordiniert, vermeintlich auch verschwenderisch abläuft. Man muss nur etwas Fantasie haben. IMHO. Und: Einen wichtigen Aspekt vergessen die Nostalgiker: mit jeder neuen Chip-Generation sinkt auch der Stromverbrauch. Wieso dann noch an altem hängen?
:
Bearbeitet durch User
Mutluit M. schrieb: > Wenn wir erstmal den Weltraum erobern, dann haben wir andere Probleme, die wir bisher noch nichtmal abschätzen können. Das hatten wir schonmal, Geschichte wiederholt sich. Mutluit M. schrieb: > mit jeder neuen Chip-Generation sinkt auch der Stromverbrauch. > Wieso dann noch an altem hängen? Sowohl Entwicklung als auch Herstellung eines Chips verbraucht viel Zeit und Energie. Verglichen mit dem alten, schon produzierten und im Einsatz befindlichen Chips sogar unendlich viel. Wieviel effizienter muss der neue Chip also sein, damit sich das lohnt? Ich bin mir ziemlich sicher, dass ein zweijährlicher "bitte alles neukaufen"-Zyklus da nicht drunter fällt. Davon abgesehen: Retro-Technologie ist ähnlich wie Geschichte etwas, was zu Lernzwecken extrem nützlich ist. Das heißt nicht, dass man alte Technik aus Prinzip überall produktiv einsetzen muss - aber sie einsetzen kann, wenn neue Technik keine Vorteile bringt. Was erstaunlich oft der Fall ist. Ein P3/800 (oder meinetwegen ein Raspberry Pi) reicht für so ziemlich alle Office-Aufgaben aus. Warum brauchen wir jetzt nochmal Quadcore-Systeme?
S. R. schrieb: > Mutluit M. schrieb: >> Wenn wir erstmal den Weltraum erobern, > dann haben wir andere Probleme, die wir bisher noch nichtmal abschätzen > können. Ja und? Hast du Angst vor dem Unbekannten? Vor Neuem? Der Mensch ist ein Entdecker, liegt in seiner Natur. Lass dich insb. von linken Ideologien nicht vereinnahmen, den Schwarzmalern und Bremsern. > Mutluit M. schrieb: >> mit jeder neuen Chip-Generation sinkt auch der Stromverbrauch. >> Wieso dann noch an altem hängen? > > Sowohl Entwicklung als auch Herstellung eines Chips verbraucht viel Zeit > und Energie. Verglichen mit dem alten, schon produzierten und im Einsatz > befindlichen Chips sogar unendlich viel. Wieviel effizienter muss der > neue Chip also sein, damit sich das lohnt? > > Ich bin mir ziemlich sicher, dass ein zweijährlicher "bitte alles > neukaufen"-Zyklus da nicht drunter fällt. > > Davon abgesehen: Retro-Technologie ist ähnlich wie Geschichte etwas, was > zu Lernzwecken extrem nützlich ist. Das heißt nicht, dass man alte > Technik aus Prinzip überall produktiv einsetzen muss - aber sie > einsetzen kann, wenn neue Technik keine Vorteile bringt. Was erstaunlich > oft der Fall ist. > > Ein P3/800 (oder meinetwegen ein Raspberry Pi) reicht für so ziemlich > alle Office-Aufgaben aus. Warum brauchen wir jetzt nochmal > Quadcore-Systeme? Für neue Technologien wie selbstfahrende Autos, FlugTaxis, KI usw. Rechenpower kann nie genug da sein, weil man eben dann grössere Probleme angehen wird... Nach deiner Meinung dürfte es ja gar keinen Forschritt geben: einmal entwickeln und gut is. Das ist aber falsche Denke. Ständige Verbesserung --> Evolution --> Perfektion --> Der Lauf der Geschichte Und niemand wird gezwungen etwas neues zu kaufen. Der Markt regelt alles, sowohl für Anbieter als auch Konsumenten: Angebot und Nachfrage. Jeder macht schon seine Kalkulation...
:
Bearbeitet durch User
Mutluit M. schrieb: >>> Wenn wir erstmal den Weltraum erobern, >> dann haben wir andere Probleme, die wir >> bisher noch nichtmal abschätzen können. > Ja und? Ich wollte das Thema wegdrücken, weil definitiv Off-Topic. :-) Mutluit M. schrieb: > Rechenpower kann nie genug da sein, > weil man eben dann grössere Probleme angehen wird... Im Augenblick wird das vor allem gegen die Endkunden eingesetzt, aber das ist ebenfalls ein anderes Thema.
S. R. schrieb: > Mutluit M. schrieb: >> Rechenpower kann nie genug da sein, >> weil man eben dann grössere Probleme angehen wird... > > Im Augenblick wird das vor allem gegen die Endkunden eingesetzt, Noe, Endkunden haben auch viel Macht: denn, wer kauft denn heute noch Intel-Chips, nach all den Skandalen/Bugs etc... :-)
Mutluit M. schrieb: > Und: > Einen wichtigen Aspekt vergessen die Nostalgiker: mit jeder neuen > Chip-Generation sinkt auch der Stromverbrauch. Wieso dann noch an altem > hängen? Wegen der Erzeugungsenergie wurde ja bereits geschrieben. Bei klassischen Geräten wo es immer wieder um Effizienz geht (Kühlschrank, Waschmaschine, LED Beleuchtung) sind es je nach Nutzung und Energieeffizienz des alten Gerätes 4 bis 15 Jahre, bis sich das finanziell amortisiert hat. Energetisch sollte es beim PC ungefähr gleich sein. Das heißt je häufiger man wechselt, desto mehr Energie wird verschwendet. Übrigens nicht nur Energie. Wie viele Stunden muss sich der Administrator mit dem neuen PC beschäftigen und wie viel Zeit spart der Mitarbeiter dadurch pro Tag. Beim Wechsel von HDD auf SSD lohnt sich das je nach Branche oft. Aber für einen 08/15 Arbeits PC lohnt sich der Aufwand der neuen Hardware nicht, nur weil das alte Board kein aktuelles SATA bietet. Mutluit M. schrieb: > Ja und? Hast du Angst vor dem Unbekannten? Vor Neuem? > Der Mensch ist ein Entdecker, liegt in seiner Natur. Lass dich insb. von > linken Ideologien nicht vereinnahmen, den Schwarzmalern und Bremsern. ... > Für neue Technologien wie selbstfahrende Autos, FlugTaxis, KI usw. > Rechenpower kann nie genug da sein, weil man eben dann grössere Probleme > angehen wird... > > Nach deiner Meinung dürfte es ja gar keinen Forschritt geben: einmal > entwickeln und gut is. Das ist aber falsche Denke. > > Ständige Verbesserung --> Evolution --> Perfektion --> Der Lauf der > Geschichte > > Und niemand wird gezwungen etwas neues zu kaufen. Der Markt regelt > alles, sowohl für Anbieter als auch Konsumenten: Angebot und Nachfrage. > Jeder macht schon seine Kalkulation... Ich habe eher Angst davor, was der Mensch im Weltraum macht, als vor dem Weltraum. Nichts gegen moderne Technik und auch nichts dagegen große Probleme zu lösen. Aber schau dir mal an wie die technischen Probleme gelöst werden. Hauptsache man kann es irgendwie verticken. Entwicklung/Evolution ist nur ein notwendiges Übel um mit der Konkurenz mithalten zu können. Und auch dann werden durch Inkompatibilitäten künstliche Entwicklungsbremsen eingebaut. Die Menschheit ist momentan gar nicht in der Lage große Probleme zu lösen. Deswegen lass sie lieber auf der Erde.
Mutluit M. schrieb: > Und: > Einen wichtigen Aspekt vergessen die Nostalgiker: mit jeder neuen > Chip-Generation sinkt auch der Stromverbrauch. Wieso dann noch an altem > hängen? Gilt nicht bei GPUs und INtel CPUs ;) Wenn ich bedenke was meine alte voodoo3000 an Strom wollte und jetzt meine R9 270. Aber du fällst seit deiner Anmeldung hier eh nur durch Dummlaberei auf, siehe dein ADC Fred.
Mutluit M. schrieb: > Noe, Endkunden haben auch viel Macht: denn, wer kauft denn heute noch > Intel-Chips, nach all den Skandalen/Bugs etc... :-) Glaubst du ernsthaft, dass moderne ARM-Chips die gleichen Probleme nicht haben? Um die hohen Ausführungsgeschwindigkeiten zu erreichen, nutzen alle Hersteller die gleichen Ansätze - und wenn es konkurrenzfähige, performante RISC-V-Implementationen gibt, dann werden auch die anfällig sein.
Dampfheuler schrieb: > x86 ... im Griff ? Aha. > Kannst du selbst ein BIOS schreiben - natuerlich nicht. > Kannst du einen Treiber schreiben, was Einfaches, > zB Disk ? Ethernet ? USB ? SD Karte ? Was anderes ? - Natuerlich auch > nicht. > > Du bist drauf angewiesen, dass jemand schon einen Treiber geschrieben > hat. Wer noch nie einen eigenen Compiler programmiert hat ist eh kein richtiger Programmierer. (sagte Terry Davis) https://youtu.be/gBE6glZNJuU
Mw E. schrieb: > Mutluit M. schrieb: >> Und: >> Einen wichtigen Aspekt vergessen die Nostalgiker: mit jeder neuen >> Chip-Generation sinkt auch der Stromverbrauch. Wieso dann noch an altem >> hängen? > > Gilt nicht bei GPUs und INtel CPUs ;) > Wenn ich bedenke was meine alte voodoo3000 an Strom wollte und jetzt > meine R9 270. Ja, ein sehr gutes Beispiel :-) > Aber du fällst seit deiner Anmeldung hier eh nur durch Dummlaberei auf, > siehe dein ADC Fred. Komm, du hast das Wesentliche an dem ADC-Thema wohl missverstanden. Lass mich versuchen den Sachverhalt wie folgt zu erklären bzw. aufzuklären:
1 | Vieles in der Natur ist bekanntlich Normalverteilt (Gaussche Glockenkurve). |
2 | Demnach nimmt der 3-Sigma-Vertrauensbereich (d.h. -3sigma bis +3sigma) |
3 | um den Mittelwert genau 99.74% der Gesamtfläche ein, d.h. der Rest |
4 | an den beiden Seiten beträgt dann insg. 100 - 99.74 = 0.26% bzw. je 0.13% an jeder Seite. |
5 | |
6 | Aber in diesem Fall muss man die einseitige Normalverteilung (1-sided significance level) anwenden: |
7 | SL1 = (SL2 + 1) / 2 |
8 | = (0.9974 + 1) / 2 |
9 | = 0.9987 |
10 | D.h. 1 - 0.9987 = 0.0013 = 0.13% liegen ausserhalb des 3sigma Bereichs (d.h. drunter), sind also sog. Outlier. |
11 | S.a. https://de.wikipedia.org/wiki/Normalverteilung#Standardabweichung_der_Normalverteilung |
12 | (dort bei 3sigma genauer gerechnet: 99.73% statt 99.74% hier oben) |
13 | |
14 | Demnach beträgt die Anzahl der Leser die das Thema gänzlich missverstehenden haben ca.0.13%. |
15 | Ach, das ist eine verschwindend geringe Anzahl, also in diesem Fall vernachlässigbare Outlier die man einfach ignorieren kann... :-) |
:
Bearbeitet durch User
S. R. schrieb: > Ein P3/800 (oder meinetwegen ein Raspberry Pi) reicht für so ziemlich > alle Office-Aufgaben aus. > Warum brauchen wir jetzt nochmal Quadcore-Systeme? Du hast noch nie einen abgestürzten IE auf einem P3/800 erlebt, sonst würdest Du nicht fragen. Und moderne Systeme brauchen deutlich weniger Strom im IDLE. Originales Win98SE hatte die CPU noch nicht mal schlafen gelegt wenn nix zu zun war.
Jim M. schrieb: > S. R. schrieb: >> Ein P3/800 (oder meinetwegen ein Raspberry Pi) reicht für so ziemlich >> alle Office-Aufgaben aus. >> Warum brauchen wir jetzt nochmal Quadcore-Systeme? > > Du hast noch nie einen abgestürzten IE auf einem P3/800 erlebt, sonst > würdest Du nicht fragen. > > Und moderne Systeme brauchen deutlich weniger Strom im IDLE. Originales > Win98SE hatte die CPU noch nicht mal schlafen gelegt wenn nix zu zun > war. Das kann ich voll bestätigen! Ich habe mich auch gefragt, was MS da für ein Murks programmiert hat, wo die CPU ständig mit 100% ausgelastet ist, auch im Leerlauf! Sieht man leider sogar heute noch wenn man ins BIOS reingeht: 100% CPU-Auslastung bei einigen BIOSsen!
:
Bearbeitet durch User
Korrektur wg. Typo: Demnach beträgt die Anzahl der Leser die das Thema gänzlich missverstanden haben ca. 0.13%. Ach, das ist eine verschwindend geringe Anzahl, also in diesem Fall vernachlässigbare Outlier die man einfach ignorieren kann... :-)
:
Bearbeitet durch User
Weiss jemand in diesem Zusammenhang (SATA) um was für ein Gerät es sich bei einem "SATA Port Selector" handelt? Wofür wird das in der Praxis denn eingesetzt? Ich hab zwar den folgenden Text gefunden, aber werde daraus nicht besonders schlau: " Port Selectors SATA can only have one path active at a time, which is a single point of failure. A port selector is basically a failover switch that will switch in a fail-over path to storage devices if the primary path fails. A Port selector is a 2-input-to-1-output failover switch that will switch a storage device to a fail-over path to if the primary path fails. Port selectors are small and inexpensive and are manufactured within the SATA hard disk caddy or actually on the disk. It is possible to buy external port selectors too. "
Klingt wie Dual Porting bei SAS. Bei SAS können 2 PCs auf eine Festplatte zugreifen, bzw 2 Kabel an einen Controller geführt werden für mehr Durchsatz und Redundanz des Kabels. Mit dem Adapter würde das dann auch bei billigen SATA Festplatten funktionieren. Lohnt sich meiner Meinung nach nicht wirklich. RAID bzw. Backupserver sind bessere Alternativen.
Heinz M. schrieb: > Klingt wie Dual Porting bei SAS. Bei SAS können 2 PCs auf eine > Festplatte zugreifen, bzw 2 Kabel an einen Controller geführt werden für > mehr Durchsatz und Redundanz des Kabels. Mit dem Adapter würde das dann > auch bei billigen SATA Festplatten funktionieren. Lohnt sich meiner > Meinung nach nicht wirklich. RAID bzw. Backupserver sind bessere > Alternativen. Falls du oder jemand anderes sich mit SAS & Co auskennt: ist SAS und eSATA eigentlich dasselbe? Was ist der Vorteil und Unterschied von SAS ggü SATA? Und: kann man am normalen SATA auch eSATA anschliessen? Oder sind die Kabel doch anders? Handelt es sich bei eSATA-Kabel um nur Datenkabel oder ist da Strom auch drin? Also, ich habe über SATA schon viel gelesen, aber blicke immer noch nicht ganz durch in diesem endlosen SATA-Dschungel :-) Wird echt Zeit dass NVMe breitflächig kommt und dadurch SATA in Rente geschickt wird :-)
:
Bearbeitet durch User
Jim M. schrieb: > Du hast noch nie einen abgestürzten IE auf einem P3/800 erlebt, > sonst würdest Du nicht fragen. Was hat denn bitte ein bestimmtes (veraltetes) Programm mit der benötigten Rechenleistung für Office-Aufgaben zu tun? Mutluit M. schrieb: >> Und moderne Systeme brauchen deutlich weniger Strom im IDLE. >> Originales Win98SE hatte die CPU noch nicht mal schlafen gelegt >> wenn nix zu zun war. > > Das kann ich voll bestätigen! Ich habe mich auch gefragt, > was MS da für ein Murks programmiert hat, wo die CPU ständig > mit 100% ausgelastet ist, auch im Leerlauf! Ein relevanter Hersteller von Computersystemen hatte ein verbreitetes System mit einem BIOS-Bug verkauft, welches bei der Verwendung von HLT in der Idle-Loop schlicht abstürzte. Daher wurde entschieden, bei Windows 95 kein HLT in die Idle-Loop zu tun. Aus Kompatiblitätsgründen - die Microsoft wichtig sind - wurde das für die Win9x-Reihe beibehalten. Es gibt Tools wie "Rain", die Abhilfe schaffen. > Sieht man leider sogar heute noch wenn man ins BIOS reingeht: > 100% CPU-Auslastung bei einigen BIOSsen! Das nennt man "Polling" und ist eine übliche Technik, um mit minimalem Softwareaufwand eine funktionierende Umgebung bereitzustellen. Deine Auslassung zur Normalverteilung (im Sinne von "du bist ein Idiot"), zeigt, dass du relativ wenig Grundlagenwissen hast. Hättest mal meine Vorlesung besuchen sollen. :-)
Ist ganz einfach: IDE -> Desktop SCSI -> Server SATA -> Nachfolger von IDE -> Desktop SAS -> Nachfolger von SCSI -> Server SAS vs. SATA ist 1:1 wie SCSI vs. IDE. Sprich das eine ist die High End Schnittstelle für Server und das andere billig für den Desktop. Einziger Unterschied: SATA Geräte lassen sich an SAS Controllern betreiben. eSATA -> SATA für externe Festplatten. Im Grunde nur anderer Stecker. Gibt spezielle eSATA Ports die noch irgendwas machen, damit Hotplug besser läuft und längere Kabellängen möglich sind. In der Praxis vernachlässigbar. eSATAp (auch eSATA+Power oder eSATA+USB) -> USB und eSATA in einem Kombiport, damit auch Strom für 2,5" Festplatten mit übertragen wird. eSATApd -> zusätzlich 12 V damit auch 3,5" HDDs versorgt werden. SATAe -> SATA und PCIe in einem Stecker umschaltbar um die höhere Geschwindigkeit von PCIe nutzen zu können mSATA -> SATA im Ministeckkartenformat mPCIe -> PCIe im Ministeckkartenformat und Nachfolger von mini PCI M.2 -> Nachfolger von mPCIe und mSATA NVMe -> PCIe Protokoll wird zur Übertragung genutzt Und viele weitere Steckverbinder und Schnittstellen im Serverbereich. Siehst du, ist doch gaaanz einfach. Diesen Dschungel haben wir der extrem schnellen Entwicklung zu verdanken. Weiteres musst du selbst googlen. Wegen der Frage was woran läuft ist die Anwort wie immer: Stecker muss passen, Pinbelegung muss passen, Protokoll muss passen. Und Protokolle gibt es aktuell nur USB, SATA und PCIe im Desktopbereich für Massenspeicher. Den Rest kann man passend machen.
Mutluit M. schrieb: > Einen wichtigen Aspekt vergessen die Nostalgiker: mit jeder neuen > Chip-Generation sinkt auch der Stromverbrauch. und verlangt ein neues OS und das wieder neue Treiber die es nicht für alte HW gibt. Man kommt heute mit neuer Hardware aber nicht mit 640KB aus, man kann keine PS/2 Maus und Tastatur mehr anstecken, also rüstet man weiter auf, neues RAM, neue Tastatur, neue Maus, neuen Scanner, neuen Drucker, ja das spart! Mit der CGA Monitor geht ja auch nicht mehr und die ISA IEEE488 Karte findet auch kein Steckplatz mehr, obwohl eigentlich noch in Ordnung. Das spart noch viel mehr......
Heinz M. schrieb: > Siehst du, ist doch gaaanz einfach. Na, da habe ich schon meine Zweifel dran... :-) > Diesen Dschungel haben wir der extrem schnellen Entwicklung zu verdanken. Einen grossen Lob und Dank an dich; diese Zusammenfassung/Übersicht ist mMn sehr hilfreich in dem Dschungel. > Weiteres musst du selbst googlen. Ja, thx. Der Rest ist einfach für mich: da ich primär an SATA interessiert bin, kann ich die anderen jetzt getrost und wissentlich abhacken, weil für mein Projekt doch nicht relevant. Aber das konnte ich bis zu deiner genialen Übersicht nicht wissen. Hab wider viel dazu gelernt. Nochmals Danke!
Joachim B. schrieb: > Mutluit M. schrieb: >> Einen wichtigen Aspekt vergessen die Nostalgiker: mit jeder neuen >> Chip-Generation sinkt auch der Stromverbrauch. > > und verlangt ein neues OS und das wieder neue Treiber die es nicht für > alte HW gibt. > > Man kommt heute mit neuer Hardware aber nicht mit 640KB aus, man kann > keine PS/2 Maus und Tastatur mehr anstecken, also rüstet man weiter auf, > neues RAM, neue Tastatur, neue Maus, neuen Scanner, neuen Drucker, ja > das spart! > > Mit der CGA Monitor geht ja auch nicht mehr und die ISA IEEE488 Karte > findet auch kein Steckplatz mehr, obwohl eigentlich noch in Ordnung. > > Das spart noch viel mehr...... Also, wenn du eine Energiebilanz aufstellst, bin ich mir sicher, rentieren sich die neuen energie-sparsamen Varianten bestimmt irgendwann, nach x Jahren... Ah Leute, macht es doch wie die Firmen: einfach nach x Jahren abschreiben, am besten dann bei ebay verhökern so dass man dann auch etwas zurückbekommt und das beruhigende Gefühl dass man einem armen Schlucker (z.B. Student/Schüler oder Hartz4) damit helfen konnte, weil sein Budget für Neuware nicht ausreicht... Modern Times eben :-)
:
Bearbeitet durch User
S. R. schrieb: > Mutluit M. schrieb: >> Sieht man leider sogar heute noch wenn man ins BIOS reingeht: >> 100% CPU-Auslastung bei einigen BIOSsen! > > Das nennt man "Polling" und ist eine übliche Technik, um mit minimalem > Softwareaufwand eine funktionierende Umgebung bereitzustellen. Hmm. das kann man auch besser machen. Die CPU so zu quälen sollte wie Tierquälerei bestraft werden! :-) > Deine Auslassung zur Normalverteilung (im Sinne von "du bist ein > Idiot"), zeigt, dass du relativ wenig Grundlagenwissen hast. Hättest mal > meine Vorlesung besuchen sollen. :-) Was hat denn da deiner Meinung nach nicht gestimmt? (Ok, statt "einseitige Normalverteilung" hätte ich wohl besser Kumulative Normalverteilungsfunktion (CDF) schreiben sollen, meinst du das vlt.?) Bist du bzw. warst du vlt. ein Mathelehrer/Ausbilder/Prof mit Statistik/Stochastik/Wahrscheinlichkeitsrechnung? Cool! Ich hab schon immer Respekt vor Mathelehrern gehabt. Bestes Fach das es gibt bzw. gab in meiner Schul-/Ausbildungs-/Studienzeit vor sehr sehr Langem... :-)
:
Bearbeitet durch User
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.