Hi,

also fragt nicht nach dem Grund, aber ich muß ein Programm schreiben, daß immer nur ein Byte liest. Dabei soll das System nicht einen Block an Daten lesen und sie mir dann zur verfügung stellen, sondern immer wieder nur ein Byte. Für das nächste Byte soll er wieder auf den Datenträger zugreifen.

Also was mir beim Datenlesen so einfällt, daß sind TFileStream und die etwas ältere Methode über AssignFile & Co. Nur leider fehlt mir da das Hintergrundwissen. Am liebsten würde ich das über den Stream machen, aber da weiß ich nicht ob der einen Puffer benutzt den er zuerst einliest oder ob ich da tatsächlich immer nur auf ein Byte zugreife? Auch bei der anderen Methode bin ich mir da nicht sicher. Weiß einer mehr?

Wenn du über nen Filestream gehst, und ein Byte einliest, dann wird afaik wirklich nur ein Byte gelesen. (Merkt man am Geschwindigkeitsunterschied - lies einmal 10MB am Stück ein, und dann 10.000.000 mal ein Byte. Sollte einen merkbaren Unterschied machen.)
Ob dieses Byte dann tatsächlich direkt vom Datenträger gelesen wird, oder evtl. aus dem einen oder anderen Cache (z.B. der Festplattencache), kann man nicht ohne weiteres sagen, fürchte ich.

(Wozu benötigst du denn den echten Byteweise-Zugriff? )

Moin!

bms hat folgendes geschrieben:

Für das nächste Byte soll er wieder auf den Datenträger zugreifen.

Das kannst du IMHO nicht sicherstellen, ohne das Betriebssystem zu umgehen (oder zumindest den Dateisystemtreiber). Abgesehen davon wäre es mir neu, Bytes von einem Datenträger lesen zu können, das geht AFAIK eh nur sektor/clusterweise...

Vielleicht erklärst du mal besser, WOZU das gut sein soll.

cu
Narses

//EDIT: zu langsam...

Hallo,

echtes byteweises einlesen ist eigentlich unmoeglich, da heutige Festplatten sowieso schon selbst im Voraus lesen.
Das byteweise Einlesen selbst ist so langsam, da jedesmal ein Betriebssystemaufruf erfolgt der selbst ja auch Zeit kostet, da auch hier eine Verwaltung am Werk ist.
So wurden bei mir aus 50 Mb/s winzige 0.2 Mb/s also ein Faktor hundert runter bei dem Einlesen einer Textdatei Zeichen fuer Zeichen.


Um ein echtes Zeichen fuer Zeichen lesen hinzubekommen, kannst Du die Festplatte quaelen in dem einfach die Datei als Filestream ,openReadWrtite oeffnest, und das gerade gelesene Byte wieder zurueckschreibst.


Vielleicht ist Windows schlau genug verzoegert zurueckzuschreiben.

Gruss Horst

Gausi hat folgendes geschrieben:

Ob dieses Byte dann tatsächlich direkt vom Datenträger gelesen wird, oder evtl. aus dem einen oder anderen Cache (z.B. der Festplattencache), kann man nicht ohne weiteres sagen, fürchte ich.

Es nur dann direkt von der Festplatte gelesen, wenn alle Caches leer sind. Und dann erhält man ein Zeichen direkt von der Platte, alle darauffolgenden stammen aus einem Cache.

Festplatten lassen prinzipiell nur Zugriff auf einen Block zu, im Allgemeinen ist dieser 512Byte groß. Höhere "Audlösung" kriegst du nur hin, indem du diesen Block in den Speicher einliest und darin einzelne Byte addressierst.

Horst_H hat folgendes geschrieben:

Um ein echtes Zeichen fuer Zeichen lesen hinzubekommen, kannst Du die Festplatte quaelen in dem einfach die Datei als Filestream ,openReadWrtite oeffnest, und das gerade gelesene Byte wieder zurueckschreibst.

Write Caching und Read Ahead existiert. Ich weiß nicht, wie intelligent das Read Ahead von Windows ist, wenn es intelligent ist, merkt es aber, daß du beim nächsten Mal auf ein Zeichen zugreifen willst, das niemals verändert wurde und liefert es trotzdem aus dem Cache. Das gleiche gilt für's Schreiben, bei aktiviertem Write Cache kannst du dir auch nicht sicher sein, wann Daten geschrieben werden.
Übrigens wäre so ein Vorgehen mit NCQ sowieso für die Katz', da ist die Reihenfolge der Lese- und Schreibzugriffe schlichtweg nicht vom Programm vorgegeben.

Irgendwelche Verrenkungen um irgendwelche Caches zu umgehen sind böse[tm] und sollten daher verhindert werden. Bei so einem Müll sollte man nicht noch helfen. Es gibt keinen Grund, Caches der Festplatte oder des Betriebssystems zu umgehen. Wenn man ständig erwartet, daß sich Daten auf der Platte ändern, wird das Betriebssystem darüber bescheid wissen. Alles andere sind schlechte Designs.

Ok, wozu brauche ich das? Ich wurde gebeten ein kleines Programm zu schreiben das mehr oder weniger das machen soll: zuerst soll ein Mitarbeiter die Möglichkeit haben bei einem Datenträger wie CD, DVD oder auch Diskette eine oder mehrere Dateien zu lesen und sich ein Bericht anzeigen lassen wie die Lesequalität des Datenträgers oder der Datei ist. Das Problem ist, daß bereits mehrmals gebrante Datenträger verschickt wurden und die dann auf dem anderen Rechner entweder schwer oder garnicht gelesen werden konnten. Bei einigen Untersuchungen fiel dann auf, daß es zwar keine Fehlermeldungen beim Brennen gibt, aber große Unterschiede beim Lesen. So kann zum Beispiel eine DVD mit der 8 fachen geschwindigkeit gelesen werden, die Geschwindigkeit kann aber auch of 0,1 fach abfallen. Das hängt dann wahrscheinlich von der Qualität des Datenträgers ab. Zwar kann man sich den Datenträger nach dem Brennen prüfen lassen, aber es gibt zum Schluß keinen Detailbericht. Und auf den kommt es an. Man kann nicht permanent auf den Monitor gucken ob beim Prüfen des Datenträgers durch z.B. Nero die Lesegeschwindigkeit zeitweise abfällt. Das kann man übersehen. Dafür wurde eine Anweisung rausgegeben, daß keine Datenträger verschickt werden sollen die nicht mindestens 1 fache Lesegeschwindigkeit haben. Und ich soll eben Programm schreiben mit dem man einfach eine CD/DVD testen soll. Das Programm soll einfach die Dateien lesen und an einer Grafik zeigen wie gut der Datenträger lesbar ist und mit welcher Geschwindigkeit. Also dachte ich mir, daß ich dazu einfach Byte für Byte lese. Das wäre am genausten.

bms hat folgendes geschrieben:

Also dachte ich mir, daß ich dazu einfach Byte für Byte lese. Das wäre am genausten.

Hihi. Dafür kriegst du aber wahrscheinlich auch nicht wesentlich mehr als 1x Geschwindigkeit...
Lies in 1MB-Blöcken, für die sollten weniger als eine Sekunde benötigt werden. Braucht ein Leseversuch deutlich länger, ist die Lesegeschwindigkeit langsamer als 1x.

Aber du bist mit dem gesamten Verfahren so sehr hardwareabhängig, daß ich den Sinn für Auslieferungs-CDs anzweifele. Der Kunde braucht nur ein anderes Laufwerk, teilweise sogar das gleiche Laufwerk mit anderer Firmware haben, und schon kann bei ihm eine DVD unlesbar sein, die bei dir durch den Test nicht durchfällt.
Wenn die Auflage reicht, lohnt es sich im Bezug auf Datensicherheit garantiert, die Dinger zu pressen. Ansonsten Markenrohlinge nehmen, die in Verbindung mit dem Brenner gute Testergebnisse (c't veröffentlicht gelegentlich welche (übrigens: die lassen sich ihre Testverfahren für optische Medien ordentlich was kosten, das kriechste nicht mal eben so zuhause hin)) haben und bei moderater Geschwindigkeit (und moderat ist nicht 8x) brennen. Da Unterscheiden sich die Tipps aus den ersten paar Jahren der CD-Brenner nicht im Geringsten mit denen beim DVD-Authoring.

Nein, du verstehst es falsch. Es sind keine CDs/DVDs die im Massen an Kunden ausgeliefert werden, sondern Projekte die an den Kunden geschickt werden. Und wenn, dann soll, zumindest bei bestimmten Kunden, so ein Lesetest gemacht werden. Und glaub mir, es werden qualitativ gute CDs/DVDs benutzt. Dennoch scheint es gelegentlich diese Probleme zu geben. Gerade DVDs scheinen was Daten angeht nicht immer zuverlässig zu sein. Meistens ja, gelegentlich nein. Aber ich will hier nicht über den Sinn oder Unsinn diskutieren. Wenn Chefe sagt, daß er sowas haben will, dann kriegt Chefe sowas.

Der andere Punkt den du genannt hast stimmt auch nicht. Es bringt nichts ein MB zu prüfen wenn die eine Hälfte gut gelesen werden kann und die andere schlecht, dann kriegst du ein Mittelmaß. Und das interessiert keinen. Was interessant ist, daß ist ob irgendwo in Teil schwer lesbar war und das System sich Zeit nehmen mußte.

bms hat folgendes geschrieben:

Und glaub mir, es werden qualitativ gute CDs/DVDs benutzt.

Die Frage ist nicht, ob der Rohling gut ist, sondern ob er zum Brenner passt.

bms hat folgendes geschrieben:

Gerade DVDs scheinen was Daten angeht nicht immer zuverlässig zu sein.

Jupp. Instabile Produktion und dann noch dazu nicht 100%ig kompatibler Brenner und schon hat man eine statistisch verteilte Erfolgsrate

bms hat folgendes geschrieben:

Der andere Punkt den du genannt hast stimmt auch nicht. Es bringt nichts ein MB zu prüfen wenn die eine Hälfte gut gelesen werden kann und die andere schlecht, dann kriegst du ein Mittelmaß. Und das interessiert keinen. Was interessant ist, daß ist ob irgendwo in Teil schwer lesbar war und das System sich Zeit nehmen mußte.

Das kriegst du doch bei einem MEgabyte auch mit. Wenn die Fehlerkorrektur der Laufwerke nur minimalste Zeit benötigt, um einen Sektor der DVD zu lesen, dann fällt das so oder so nicht auf und Laufwerke mit ähnlich guter Fehlerkorrektur werden ähnlich schnell über den Fehler hinweglesen. Ein tatsächlich gravierender Fehler zieht die Fehlerkorrektur schonmal gerne ordentlich runter. 1MB entspricht bei DVDs beim Auslesen bei single-speed in etwa einer Sekunde. Braucht jetzt die Fehlerkorrektur plötzlich unglaublich lange, um einen Sektor zu lesen, dann merkst du das daran, daß die benötigte Zeit, um das Megabyte zu lesen, plötzlich anspringt (Erkennung über deltaT-Werte). Innerhalb einer Sekunde wird es wohl kein Laufwerk schaffen, von 0,001-facher Leserate wieder auf das Maximum von meinetwegen 16x zu kommen. Du wirst also bei so kurzen Lesezyklen einen deutlichen Peak erkennen. Bei CDs musst du entsprechend die Lesemenge verringern, single-speed entspricht da 150kB/s.
Wie du aus deinem Prozess heraus den Lese-Cache umgehst, kann ich dir nicht sagen, vielleicht bringen ASPI-Treiber hier was, was, wenn von einem Brenner gelesen wird. Aber ich denke nicht, daß der LEse-Cache hier großartig eine Rolle spielen wird, da du die Daten ja lediglich liest und die Zeit stoppst. Liest du sequenziell und drehst zwischen den Versuchen nicht erstmal Däumchen, dürftest du weitaus schneller lesen als das Laufwerk, und somit dürfte der Lese-Cache ständig leer sein.