ungebuffert schreiben auf cf

[NeuKasselER]

Schönen guten Abend zusammen.
Leider weis ich kein Rat mehr, daher möchte ich doch hier anfragen ob jemand eine Idee
hat zum Thema ungebuffertes schreiben auf eine CompactFlash.

Ich habe eine Debian Etch das mit einem PythonSkript Daten sammelt, ohne schreiben
braucht es keine 3ms für einen Datenblock zu messen und verarbeiten. Mit schreiben
brauch ich nicht mal 5ms, wobei die Daten verloren gehen sobald ein Stromausfall
vorliegt. Wenn ich nun alles so einstelle um ungebuffert zu schreiben,
dann werden die Daten zwar gespeichert, aber der Vorgang zur Speicherung braucht
von 0.001 bis hin zu 3.0 Sekunden. Was die Messungen beeinflusst. Ich hab es rein
mit Python versucht, dann cTypes und nun swig mit c und c++, in Schleife und/oder
einfach nur open,wirte,flush,close. Immer wieder der selbe Effekt, die Zeit die
vergeht ist zu lang bzw. jittert stark. Das Problem ist wohl der Buffer des OS,
wie kann ich diesen in C/++ umgehen um auf geschwidigkeit zu komme.
Die CF macht 15MB/s lesen, 8MB/s schreiben, was bedeutet das die geschwindigkeit
ausreichend ist, da jeder Datenblock excakt 512Bytes gross ist und es keine 20 Blöcke
in der Sekunde sind. Als Filesystem nutze ich derzeit ex2, vorab XFS, ReiserFS.
XFS war sehr schön, da ich dort die Blocksize auf 512Bytes setzen konnte.
Es wird in eine File geschrieben, dass erst bei Neustart gewechselt wird.

Hat jemand ev. eine Idee was ich noch ausprobieren könnte, da ich nun schon 2 Tage
dran sitze und einfach keine Lösung finde. Google hab ich auch schon befragt und
bin die meisten Sache nach gegangen die mir sinnvoll erschienen. Es ging von hdparm
über tune2fs bis hin ctypes und swig python extension. Wen weitere Infos gebraucht
werden, bitte kurz anschreiben. Danke schon mal im Vorraus und schönen Abend noch.

Gruß der NeuKasselER

[LessWire]

Hallo,

nur so eine Idee auf die Schnelle::

- Messdaten in verkettete Liste eintragen
- gesamten Schreibvorgang in Thread auslagern, dort dann die Liste abarbeiten

Das Messintervall ist dann recht genau einstellbar und der "Jitter"-Effekt beim Schreibvorgang stört nicht mehr.

Vielleicht gibt's aber auch eine einfachere Lösung

Gruß, LW.

[cosmac]

hi,

vermutlich ist die CF-Karte wirklich so langsam, wie sollte das Betriebssystem so große Verzögerungen verursachen? (Ich nehme mal an, der Rechner hat sonst nicht viel zu tun). Nachdem ich im Forum von pcengines gelesen hab' und sonst keine konkreten Zahlen finden kann, verwende ich zur Datenaufzeichnung eine etwas radikale Lösung:

Es gibt eine extra CF-Karte nur für die Daten. Die wird per Security Erase einmal komplett gelöscht, normal partitioniert, aber nicht formatiert. Die Daten werden dann ohne Dateisystem direkt auf eine Partition geschrieben. Dadurch muss kein Sektor mehr als einmal beschrieben werden, also muss im Betrieb auch nicht gelöscht werden. In einem Versuch mit ca. 10 Millionen Blöcken zu 512 Byte waren die Schreibzeiten dann ziemlich konstant, es gab ca. 20 Ausreisser mit mehr als 30ms, aber keinen über 120ms. Da das auf einem normalen Desktop lief, muss nicht einmal die Karte schuld haben.

Man muss nicht sequentiell schreiben und kann so auch ohne Dateisystem mehrere "Dateien" anlegen. Wichtig ist nur, dass kein Sektor mehrmals geschrieben wird.

Genau genommen darf man nur 2K-Sektoren (oder noch größere bei großen Karten) schreiben, weil das die interne Sektorgröße der Flashspeicher ist. Laut einem Datenblatt kann so ein Sektor aber 4 Mal beschrieben werden, ohne dass er gelöscht werden muss. Das deckt sich mit meinem Versuch, es war egal, ob ich jeden 512-Byte-Sektor oder nur jeden vierten (= 2K) beschrieben hab. Aber auch darauf kann man sich nicht verlassen

[NeuKasselER]

Schönen guten Morgen und danke erst mal für die Antworten.

@LessWire:
Ein eigenen Thread für das Schreiben hab ich auch schon gehabt, dadurch das die Messung Resourcen frist und das schreiben denn auch noch, kommt es dazu das noch mehr Daten verloren gehen.
Daher stosse ich erst die nächste Messung an sobald die Daten weck geschrieben sind, so geht wenigstens nur eine Messung verloren.
Der Rechner ist mit einen 600MHz Celeron und 1GB Ram bestückt, die CF ist via IDE angebunden wodurch die Latenz eigentlich recht gut sein sollte.

@cosmac
Das Frage ich mich auch mit dem OS, ob es die verzögerung bewirkt. Auf dem Messrechner läuft im Hintergrund eine MySQL Datenbank für Daten die nicht so zeitkritisch sind und verlohren gehen können mit niedrieger Auslastung, so wie ein komplettes GUI zum oberflächlichen ansehen der Daten. CPU Auslastung des kompletten System liegt unter 30%.
Aber dein Ansatz mit dem ohne Filesystem Daten direkt auf die Blöcke schreiben hört sich sehr interessant an und wäre auch das was ich eigentlich im Sinn hatte. Nur war ich davon ausgegangen,
dass ich unter Linux nicht den Zugriff so habe wie damals unter DOS (INT 21h läst grüssen ) und direkt schreiben kann. Ich werde das Forum von pcengines mal befragen, aber wäre echt super wenn Du mir noch weitere Infos geben könntest da mein Englisch schon etwas in die Tage gekommen ist.

Danke noch mal für die Antwort und Hilfe.
Gruß Holger

[cosmac]

Nur war ich davon ausgegangen, dass ich unter Linux nicht den Zugriff so habe wie damals unter DOS (INT 21h läst grüssen ) und direkt schreiben kann. Ich werde das Forum von pcengines mal befragen

Das Forum hatte ich speziell für CF-Fragen erwähnt, Linux-Fragen sind hier wohl besser aufgehoben.

Also: Nach dem Prinzip "alles ist eine Datei" kann man auch direkt auf die "Festplatte" schreiben, genau wie in eine Datei. Es gelten auch die gleichen Regeln für Schreib- und Leserechte, allerdings darf per Default nur root die Hardware direkt ansprechen. Auf die Art kann man nämlich ganz leicht sein System zerstören.

Als Dateiname verwendet man z.B. "/dev/sde2" für die 2. Partition oder "/dev/sde" für das gesamte Device. Die einzelnen Geräte werden durch den 3. Buchstaben (hier 'e') unterschieden. Leider gibt es keine festen Regeln wie "IDE-0-Master ist /dev/sda" -- das stimmt nur bei einer genau festgelegten Hardware- und Kernel-Kombination. LABEL oder UUID helfen auch nicht direkt, weil die ja im Superblock des Dateisystems untergebracht wären. Deshalb wollte ich zwei Partitionen verwenden, eine kleine mit Dateisystem und Volume Label zur Identifizierung und die zweite für die Daten.

Wenn man einfach sequentiell schreibt, wird die Partition/Festplatte ab dem ersten Sektor überschrieben. Mit lseek(2) kann man gezielt einzelne Bytes (nicht Sektoren) adressieren, wobei bei CF-Karten nur vielfache von 512, 2048 oder 4096 sinnvoll sind. Diese Blockgrößen muss man ja auch fürs ungepufferte Schreiben mit O_DIRECT einhalten.

Mehr fällt mir gerade nicht ein, frag' einfach nochmal

[Liffi]

Diese Blockgrößen muss man ja auch fürs ungepufferte Schreiben mit O_DIRECT einhalten.

Zufaellig habe ich vor 2 Minuten in die manpage von perls open geguckt und folgendes ueber O_DIRECT gelesen:

The thing that has always disturbed me about O_DIRECT is that the whole interface is just stupid, and was probably designed by a deranged monkey on some serious mind-controlling substances.

Scheint also moeglicherweise nicht so richtig schoen zu sein (auch wenn Linus Torvalds oft uebertreibt).

[NeuKasselER]

@cosmac, wow super danke !
Die Aufteilung bzw. unordnung von Laufwerken kenn ich unter Linux, sollte man zumindest wenn man partitionieren möchte.
Aber das man direkt ohne Filesystem drauf zugreiffen kann ist mir neu, habe meine Partitionen immer Formatiert ^^
Werde es Morgen direkt mal ausprobieren, Heute ist leider nicht mehr genug Zeit dazu.
Hatte ehr damit gerechnet das man selber alles noch Positionieren muss wie damals zu DOSzeiten, aber diese Lösung find ich besser.

Zum Thema O_DIRECT, dort hab ich das gleiche Problem mit dem jittern der Schreibzeiten.

Danke noch mal für die Hilfe, werde berichten was sich ergeben hat.
Gruß Holger

[LessWire]

@LessWire:
Ein eigenen Thread für das Schreiben hab ich auch schon gehabt, dadurch das die Messung Resourcen frist und das schreiben denn auch noch, kommt es dazu das noch mehr Daten verloren gehen.
Daher stosse ich erst die nächste Messung an sobald die Daten weck geschrieben sind, so geht wenigstens nur eine Messung verloren.
Der Rechner ist mit einen 600MHz Celeron und 1GB Ram bestückt, die CF ist via IDE angebunden wodurch die Latenz eigentlich recht gut sein sollte.

@NeuKasselER:
Bei den CFs gibt's aber schon grosse Unterschiede bzgl. Schreibgeschwindigkeit, die direkte Anbindung an IDE hilft dann wohl auch nicht viel. Nachdem gewöhnliche CFs aber immer langsam sind, sollte ein "Schreibthread" eigentlich überwiegend im idle state sein. Ein "raw" write direkt aufs Medium bringt sicher noch Effizienz, aber irgendwie klingt es so, als wäre der CF zu langsam für Deine Meßintervalle - oder sogar das ganze System.

[NeuKasselER]

Moin moin LessWire, danke für deine Antwort. Wenn das System zu langsam wäre würde ja soweit nicht alles laufen. Es werden Animationen dargestellt und die Zeiten ausgegeben.
Als das System unoptimiert war, schwankten diese sehr stark. Also zwar mehr subjektiv als objektiv aber es ist ein gute Methode um zu erkennen ob das System hackt oder nicht.
Anfangs jitterte die Zeiten sehr stark bei den Animationen. Heutzutage nicht mehr, daher gehe ich davon aus das es nicht am Board oder an die verbaute CPU liegt. Habe vieles
Optimieren können um auf die Leistung zu kommen. Angefangen von Grafiken bis hin zum Multithreading mit dem Locks. Jedes überschneiden eines Lock hat mir ein kleinen 10ms
langen Sound gespielt, kannst dir vorstellen wie oft es Toccata gespielt hat am Anfang ^^ Die Sounds sind immer noch drin, aber man hört kein Knacks mehr. Daher gehe ich stark
davon aus, dass es direkt am Bus liegt. Das etwas außer mein Skript auf die Karte schreibt. Was auch das Jittern erklärt. Nur um das zu 99,999% sagen zu können, muss ich die
Daten ungebuffert schreiben. Sollte der Effekt noch auftreten, wird es ein anderes Programm sein.

Linux hatte ich nur immer als Zweitsystem oder halt für mein kleines Projekt, seit kurzem habe ich Linux nun auch auf meinen Laptop. Windows ist geflogen ^^
Damals habe ich irgendwie ein Programm gehabt das bei Etch dabei war um zu sehen welche Programm auf die HDD zugreiffen und wieviel resourcen sie verbrauchen dabei.
Weist Du zufällig welcher Befehl das war ?

zum Thema "oder ganze System." neee nicht wirklich, ich könnte es da drauf schieben wäre einfacher... aber müsste mir neue Hardware kaufen ^^
Ich möchte lieber die Hardware behalten und mehr über mein System lernen und noch wichtiger mehr über Linux. Bücher gibt es wie Sand am Meer,
aber nichts ist so gut wie selber ausprobieren ^^

Danke Dir erst mal für deine Zeit und Geduld mit mir
Schönes Wochenende und Gruß Holger

[LessWire]

Damals habe ich irgendwie ein Programm gehabt das bei Etch dabei war um zu sehen welche Programm auf die HDD zugreiffen und wieviel resourcen sie verbrauchen dabei.
Weist Du zufällig welcher Befehl das war ?

Da fällt mir "lsof" ein, Du meinst aber wahrscheinlich was anderes.

Ich möchte lieber die Hardware behalten und mehr über mein System lernen und noch wichtiger mehr über Linux. Bücher gibt es wie Sand am Meer,
aber nichts ist so gut wie selber ausprobieren ^^

Ok, das hatte ich bisher anders betrachtet - aber so ist es sicher ein gutes Praktikum mit hohem Lerneffekt.

Viel Spaß und Erfolg,
und natürlich ebenso ein schönes Wochenende!

[NeuKasselER]

Praktikum hört sich gut an ^^
Ich optimiere lieber das Programm an die Hardware, als den Geldbeutel.
Daher mein nächste PC : DREAM PC

Der Befehlt lsof ist zwar nicht der den ich suchte, aber ein guter Ansatz für ein
Diskusion mit meine Freund Google, der weiss bestimmte mehr als ich. Nur wen man
absolut nicht weiss wonach man suchen soll, ist es schwer was zu finden.
Danke Dir noch mal für deine Antwort

Gruß Holger