Festplatten Frage!

Dieses Problem tritt in der Regel nicht auf. Die Bits eines Bytes sind auf die Platten verteilt, jedes liegt auf einer eigenen Plattenoberfläche. Das beschleunigt übrigens das Leseverhalten erheblich.

Wenn du an das Ende der Platte kommst, is halt Schluss :-)

Robert

"Andreas Auer" schrieb im Newsbeitrag news:41697f98$0$31502$ snipped-for-privacy@aconews.univie.ac.at...

Leute, schreibt einfach vernuenftige Software (die die FAT verwendet), die Platte hat genug cache um den einen FAT-Sektor zu puffern, so das beim abwechselnden Lesen FAT/Sektor/FAT/Sektor/FAT/Sektor die FAT nicht jedesmal wieder geholt wird. Du musst nur die Bytes skippen, die dich nicht interessieren.

Ja, wenn der uC immer nur das naechste Byte in den A/D-Wandler schiebt und immer pro Byte den MP3-Decoder so wiet laufen laesst und mit Daten versorgt, das er dieses Byte lesen kann, dann muesste in der Zeit zwischen 2 Samples der ganze FAT-Sektor (bis auf das interessierende Byte) gekippt werden. Dazu reicht die Zeit nicht.

Wenn man aber ein FIFO mit den Bytes aus dem MP3-Dekoder bestueckt, und immer wenn der FIFO wieder Platz hat die naechsten Plattenbytes holt, und dabei eventuell die interessierenden Bytes aus der FAT zurueckgreifen muss, dann klappt das schon bei wenigen Bytes im FIFO.

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Hmmm, ist der Code, der die Kommunikation mit der Platte abwickelt, verfügbar??

Falls möglich, hätte ich gerne eine Kopie davon.

Robert

So, hätte ich die Software auch geschrieben. Aber mit 1kByte Buffer, war da leider nicht viel mit FAT lesen. Bei mir handelt es sich übrigens um WAV Files und nicht um MP3's. Bei MP3's reicht die Zeit leicht für den Zugriff auf die FAT (hab ich auch schon gemacht). Bei WAV-Files reicht sie leider nicht, da 192kByte/s an den DAC (nicht ADC) gesendet werden muss. Da hat man dann bei 1kByte großem Buffer nur etwa 5ms Zeit und da kann der FAT Zugriff leicht ins Auge gehen (tut er auch meistens). Vorallem, da ja der Lesekopf dann auf den neuen Sektor positioniert werden muss, und da kommt es dann zu Zeiten, die über 10ms liegen.

mfg Andreas

--
Andreas Auer                     aauer1 (at) sbox.tugraz.at
Student of Telematics            http://www.mikrocontroller.at.tt
Graz University of Technology

Also, den Teil zur Ansteuerung der Platte kannst du gerne haben. Der Code wurde für einen ATMega32 geschrieben. Deshalb ist die Platte auch _nicht_ in einer Art "Memory Mapped Mode" angesteuert. Die Ports werden manuell auf Ein- bzw. wieder auf Ausgang geschaltet (wodurch natürlich etwas an Geschwindigkeit eingebüßt wird) - war leider nicht mein Platinenlayout. Für den Code, schreib mir einfach mal ne Mail, dann schick ich dir den Code mal.

mfg Andreas

--
Andreas Auer                     aauer1 (at) sbox.tugraz.at
Student of Telematics            http://www.mikrocontroller.at.tt
Graz University of Technology

"Andreas Auer" schrieb im Newsbeitrag news:4169b7d4$0$11614$ snipped-for-privacy@aconews.univie.ac.at...

Du hast nicht nur 1k Puffer, sondern das ganze cache der Festplatte als Lese-Puffer. Und du hast nicht nur 5msec Zeit, sondern alle Zeit der Welt weil sich ja die Daten auf der Festplatte nicht aendern. Du kannst gleich nach dem PLAY-Druecken Lesekommandos an die Platte absetzen, um alle Sektoren so in deren cache einzulesen, wie du sie abholen willst. Du musst die FAT auf dem uC auch gar nicht zwischenspeichern, sondern du fordest sie per Lesekommando von der Platte an wie beschreiben, und skippst beim Transfer des FAT-Sektors zum uC alle Bytes die dich gerade eben nicht interessieren. Dafuer kannst du fuer die anderen Bytes ja den FAT-Sektor noch mal anfordern. Wie gesagt: Stundenlang vor dem Zeitpunkt, wo du die Daten wirklich auslesen und zum D/A transporieren musst. Einfach mal vernuenftige Software schreiben, kann ja nicht angeben, das man hier bloeder ist als in Asien.

Dein 1k FIFO reicht locker.

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

nachzusehen, wo

Auch kann er das Problem mit seinem kleinen Puffer vielleicht umgehen, wenn die Platte(n) mit einem anderen Interleaving-Faktor formatiert werden. Das wird aber wohl eher schwierig werden, da dann ein Low-Level Format zum Selberschreiben angesagt sein wird(?), aber das ist nichts, was nicht schon ziemlich sicher tausend andere gemacht haben, also gute Chancen, das im Netz zu finden. Muss man eben ein jbisschen suchen., denn beim Googlen auf den erstne Schuss nur Mist und Geschwafel gefunden, keine Tools. Das liegt wohl daran, dass das eben recht selten gebraucht wird, meist bestimmen die Platten-Kontroller selber ihren Interleaving-Faktor.

Henry

--
----------------------------------------------------------------------
snail mail : Henry Koplien                             \|/
             From the Center of Nowhere              o(O O)o
---- eMail : Henry@NiKo-Internetpraesenz.de ----ooOo---(_)---oOoo-----

uC

Das ist für mich nicht nachvollziehbar. Gängige Platten rotzen MB/s raus! Selbst ein MB/s reicht für eine Bandbreite von +30kHz bei 7+1 -Kanal THX mit 16 bit Wandlern, alles unkomprimiert. Ich habe auch eben mal nachgeschaut, Blockgrößen von 1k-Byte werden bei einer alten Western-Digital mit 2,5MB/s gelesen (ATA66), Das treibt die 7+1 THX-Marke schon auf eine Bandbreite von über 50kHz bei acht 24-Bit Wandlern.

Henry

--
----------------------------------------------------------------------
snail mail : Henry Koplien                             \|/
             From the Center of Nowhere              o(O O)o
---- eMail : Henry@NiKo-Internetpraesenz.de ----ooOo---(_)---oOoo-----

Die "tollen" Durchsatzraten werden eigentlich nur im Zusammenspiel mit Benchmarkprogrammen oder ähnlich gearteten Zugriffsmustern erreicht.

Im realen Leben landet man bei bestenfalls ein paar MB/s - manchmal sogar unter 1MB/s. Maßgeblich dafür verantwortlich sind die immer wieder anstehenden Pausen für die Kopfpositionierung.

Und für den OP ist der Engpaß die Kontinuität. Den ineressiert nämlich nicht die maximale Übertragungsrate (interessiert eigentlich niemand), sondern die *minimale* Übertragungsrate auf einer Zeitgrößenordnung von

5ms. Und die ist 0,0 MB/s - also in jedem Fall zu wenig.

Marcel

Ich würde es anders formulieren: Es gibt *keinerlei* Garantie, wie lange ein Platte für ein Kommando braucht. Die Platte wird natürlich versuchen ihren Cache einzusetzen, aber letztlich ist es der Firmware überlassen, welche Strategie sie dabei anwendet.

Die einzige Abhilfe wurde auch schon skizziert: das Absetzen von Kommandos "auf Vorrat". Das wiederum setzt aber notwendigerweise voraus, daß die Platte mehr als ein Kommando gleichzeitig akzeptiert. Ich weiß nicht wie weit IDE-Platten in dieser Disziplin in der Realität sind. Auf dem Papier steht es schon eine Weile... So richtig rund läuft das aber vermutlich nur bei SCSI. Falls man ein solches Feature nutzt, sollte man aber nicht vergessen das Command-Reordering abzustellen, da das Command Queuing eigentlich dafür vorgesehen ist, der Platte die Chance zu geben, die Ausführungsreihenfolge der Kommandos zugunsten des Durchsatzes zu ändern.

Ich glaube, man kann es drehen und wenden wie man will, mit 1k Puffer wird das *nie* zuverlässig sein. Ich sage nur

- Sektor remapping,

- thermische Rekalibrierung der Platte

- etc.

Wie wäre es mit einem 64k SRAM (Cache-RAM)? Das schafft mit 300ms vermutlich hinreichend Luft.

Marcel

Du musst zwischen den Durchsatzraten des Busses (in diesem Fall ATA) in verschiedenen Ausbaustufen und die der einzellnen Festplatte finden. Und bei den Festplatten gibt es naturgemäß von Modell zu Modell unterschiede so das man das nicht pauschalisierern sollte.

Im realen Leben machen sich aber die Hersteller der Festplatten und die Treiberautoren schon Gedanken wie sie dieses Problem minimieren.

Die Dateisysteme, Festplattentreiber und Festplattencache arbeiten im realen Leben doch schon sehr gut zusammen. Und genau das testen diese Benchmarkprogramme.

Es ist sicherlich denkbar ein Programm zu schreiben was ohne den Festplattencache und ähnlichen Beschleunigungsmöglichkeiten eine beliebig kleine Datenrate zu erreicht.

Aber wenn es nun mal bei dem vom OP verwendeten Modell länger braucht als er irgendwie cachen kann muss er sich halt mehr Speicher besorgen.

Tschüss Martin L.

Naja also wenn ich mir die Daten von meinem letzten Festplattenbackup anschaue, dann waren das so ca. 40GB Rohdaten (ich rechne mal mit 40000 MB) in 2:20h. Das wären also schonmal 4,8 MB/s.

Aber da glaube ich, dass der Flaschenhals eindeutig woanders liegt: es wird erstmal ein "find" auf alle Dateien gemacht, die Größe ermittelt, dann schone kleine Häppchen per tar über ssh übermittelt. Also Verwaltungsoverhead, Verschlüsselungsoverhead, Netzwerk. Und trotzdem summa summarum noch knapp 5MB/s. Das finde ich schon gut. Ich glaube die Platten schaffen noch deutlich mehr.

Gruß Johannes

--
One can look at the designs of a bridge, realize it's built of tongue
depressers and bubble gum, and from this conclude that it is, indeed,
junk, without once having to take the actual suicidal risk of driving
across it. We do the same with your code.  Your code is crap.  [...]
                    - Kelsey Bjarnason in COLA about Jeff Relf's X.EXE

Jetzt mal kurz eine Erläuterung zu meinem Projekt. Und zwar muss ich WAV-Files von einer Festplatte abspielen - hab ich ja schon erwähnt. Jetzt mal eine Kleinigkeit zu dem ganzen Timing. Und zwar schaut die Sache so aus. Da ist ein DAC und der braucht bei 48kHz Sampling Rate 4 Byte pro

1/48kHz ~ 20us. Und die 4 Byte müssen dann auch noch so geschickt werden, dass 2 Byte in der ersten Hälfte der Periode für den linken Kanal und die anderen 2 Byte in der zweite Hälfte der Periode für den rechten Kanal rausgeschrieben werden. Das bedeutet also, dass ich für den Transfer von 2 Byte etwa 10us zur Verfügung habe. Jetzt kommt noch erschwerend hinzu, dass die 2 Byte nicht parallel sondern seriell per SPI Interface geschickt werden. In meiner Konfiguration mit Double Speed läuft SPI auf 6MHz. Damit liegt die benötigte Zeit für die Übertragung von 1 Byte bei 1,3us. Alles in allem benötigt meine Senderoutine, die übrigens in ASM geschrieben ist, etwa 3-5us. Jetzt bleiben also noch ca. 5us zwischen der Ansteuerung des DACs, um mit der Festplatte zu "quatschen"! Und da ich meinen Buffer im Controller nach 512 gesendeten Bytes wieder auffüllen will, damit er sicher nicht leer läuft, habe ich also in etwa 256 * 5us ~ 1,28ms Zeit um neue Daten von der Festplatte zu holen. Wenn ich das mal hochrechne auf einen Datendurchsatz, dann sind das eh schon fast 512kByte/s (und nebenbei wird auch noch der DAC bedient) und das mit nem Controller der mit 12 MHz läuft.

Also für mich ist die Software, die ich in den letzten Wochen geschrieben habe, doch sehr performant.

So... und jetzt möchte ich mal wissen, ob du WAV-Files von einer Festplatte selbst schonmal über nen DAC abgespielt hast.

mfg Andreas

--
Andreas Auer                     aauer1 (at) sbox.tugraz.at
Student of Telematics            http://www.mikrocontroller.at.tt
Graz University of Technology

Mein Beitrag betrifft hauptsächlich MaWin!

mfg Andreas

--
Andreas Auer                     aauer1 (at) sbox.tugraz.at
Student of Telematics            http://www.mikrocontroller.at.tt
Graz University of Technology

"Andreas Auer" schrieb im Newsbeitrag news:416ad618$0$25116$ snipped-for-privacy@aconews.univie.ac.at...

Das macht eine zeitgeber-gesteuerte Interrupt-Routine, die die Bytes zeitgenau aus dem als FIFO organisierten Speicherbereich holt, dann bist du den zeitkritischen Teil erst mal los. Etwas effektiv programmiert (dedizierte Register, 256-Byte wrap-around nutzen) reichen ca. 6 Befehle (Adressinkrement, indiziert Byte holen, Strobe setzen, Byte ausgeben, Strobe zuruecknehmen, return)

hast du 2.5msec Zeit pro Datensektor, macht 192kByte/sekunde effektive Datenuebertragungsrate, das ist doch nicht zu viel, das schafft ja noch fast eine Floppy.

Fast. Auf Original IBM PC mit 4.77MHz 8088 (also langsamer als dein AVR) die per DOS von der Festplatte geholten Sample-Bytes nicht einfach an einen D/A-Wandler ausgeben, sondern zur Programmierung des internen Zeitgebers verwendet, um per PWM dessen Ausgang als D/A-Wandler nutzen zu koennen um Sprache und Musik wiederzugeben. Zugegeben gab es mehr Speicher, aber weniger Rechenleistung und krudere Hardware.

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

raus!

THX

THX-Marke

Selbst geschriebenes C-Program mit Uraltkompiler, nix besonderes. Die Sourcen sind sograr auf meiner Home-Page veröffentlicht.

wieder

Ach falsch, ich haber hier SCSI-Platten (nicht Deine ATA) die machen eingeschwungen 33MB/s.... (Bei GigaByte Transfers) Auch zu sehen auf meiner Home-Page.

Die Rate liegt noch ganz woanders, da nämlich, was der Bus hergibt, das kön nten bei ATA 133MB/s, oder bei SCSI 320MB/s sein.

Henry

--
----------------------------------------------------------------------
snail mail : Henry Koplien                             \|/
             From the Center of Nowhere              o(O O)o
---- eMail : Henry@NiKo-Internetpraesenz.de ----ooOo---(_)---oOoo-----

Ich zweifle nicht die Zahlen an, sondern ihren Bezug zur Realität.

^^^^

^^^^

Das war vielleicht sogar noch ein RAID-5? Was soll daran bitte typisch für einen 08/15 Endanwender sein?

Und mit der vom OP genannten Anforderung hat es auch nichts gemein.

???

In 5ms Intervallen gemessen gibt es immer Intervalle, bei denen die Rate 0 ist, da keine Daten übertragen werden, obwohl noch eine Anforderung vorliegt. Das ist auch bei meiner 15k Cheetah so, da deren Full-Track Seek Time zzgl. der Latenzen größer 5ms ist.

Marcel

Nein, stinknormales SCSI-UW, sollten eigentlich 40MB/s sein, werden aber mit keinen Blockgrößen erreicht (auch die nicht, die nur den Cache bedienen, tut hier aber nichts zur Sache).

Ganz einfach der adressierte Speicher einer ATA-Festplatte lässt sich leicht an 5MB/s auslesen, mit 8 Jahre alten Laptop Platten, nachweisbar. Wie MaWin schon geschrieben hat, das Problem liegt ganz woanders, es reicht nämlich fast die Floppy-Disk Geschwindigkeit für das bisschen WAV.

Rate

(Auch haben Platten einen Puffer/Cache)

Wie schon mal erwähnt, die Platten, selbst meine langsamste Western Digital, macht 2,5MB/s (das ist schon weniger als 08/15...), über ein Read von einem halben GigaByte hinaus, das reicht, um mal wieder das WAV Beispiel zu stressen, für normale 50min 44.1kHz, 16bit Stereo, ohne einen einzigen Aussetzer. Und ich schrieb auch, dass man das bereits bei einer Puffergröße von einem 1kByte erreicht, da ist die Lösung nun doch nicht wirklich schwer, oder? (Und die 33MB von UW-Platten erreicht man bereits bei Puffergrößen von 16kByte)

Vielleicht soltest Du doch mal unter

schauen. Bei Bedarf, kann ich Dir auch die genauen Typen der Festplatten benennen.

Henry

--
----------------------------------------------------------------------
snail mail : Henry Koplien                             \|/
             From the Center of Nowhere              o(O O)o
---- eMail : Henry@NiKo-Internetpraesenz.de ----ooOo---(_)---oOoo-----

Das ist genau das problem des OP. Die Platte an sich ist leicht in der Lage ein vielfaches der nötigen Daten zu liefern. Nur systembedingt eben nicht eher als ~5 ms nach der anforderung. Natürlich kan OP die Platte raw beschreiben so daß der prefetchmechanismus der Platte sein Problem löst. Die einzig elegante Lösung wird externer Pufferspeicher sein.

--
MFG Gernot