Timeshift bei IDE

[DBoxBaer]

Moin!

Nur damit mal meine ganze Ideen, was man beim IDE Interface noch
verbessern bzw. damit anstellen könnte, nicht verloren gehen:

Zum Thema Timeshift:
An sich sollte es möglich sein, die ganzen Filesystem-Layer des Kernels
zu umgehen und relativ direkt auf die Platte zu schreiben:
Variante 1:
Direkt in eine eigene Partition, d.h. direkt in das device-File der Partition.
Variante 2:
In eine grosse Datei in einem normalen Filesystem. In der Wirkung ist das evtl. identisch zu Variante 1.

Die Frage wäre, ob das einen (kleinen) Performance Schub geben kann.
Wenn das so wäre, konstruiert man sich eine eigene Verwaltung für die Partition, also quasi ein eigenes Filesystem, nur eben nicht (unbedingt) im Kernel. Grosse Datenbanksysteme verwenden ja auch gerne mal ihr eigenes System, und der Grund ist der gleiche wie bei uns: Keines der normalen Filesysteme bringt uns wirklich etwas. Der Inhalt sieht bei uns ja in etwas so aus: Einige wenige, dafür aber riesengrosse Dateien...

Ausprobieren kann man das im Prinzip, wenn man zum Beispiel mal ZDF direkt in das device File für eine Partition "recorded". Wenn das die CPU Load senkt ist man auf dem richtigen Weg.
Ach ja: Eine Kombination mit den Avia Treibern wird dann wahrscheinlich auch einfacher.

Ciao,

DboxBaer

[saruman]

Rawdevices? Dafür brauchst Du dann aber doch in der Applikation eine interne Verwaltung. Ansonsten findest Du ja Deine Files nicht mehr wieder.

Oder hatte ich Dich jetzt missverstanden?

[DBoxBaer]

Rawdevices? Dafür brauchst Du dann aber doch in der Applikation eine interne Verwaltung. Ansonsten findest Du ja Deine Files nicht mehr wieder.

Oder hatte ich Dich jetzt missverstanden?

Nee, das ist genau richtig.
Die Verwaltung ist aber evtl. ganz einfach.

Nur bevor man sich die überlegt, wäre die Frage, ob man da viel gewinnt.
Und da insbesondere, ob man so Timeshift besser hinbekommt.
Für Timeshift muss der Player ja sowieso mit dem Recording sich
irgendwie absprechen, z.B. für den Wechsel von Live auf Delayed.
Die Verwaltung der "Filme" ist dann ein anderes Thema.

Das stelle ich mir ungefähr so vor, ich nehme mal die Variante mit
grossen Dateien im Filesystem: Davon legt man einen Haufen an,
z.B. 1GB grosse Files: FILE001.RAW, FiLE002.RAW etc.

In diese wird gestreamt. Am Ende einer solchen Datei wird dann
in die nächste gewechselt. Da die Datei weder ihre Position auf der
Platte ändert noch ihre Größe noch sonstwas, muss das Filesystem
eigentlich nichts gross anstellen.
Und wenn doch, mit nem raw-Device geht das genauso, und da sind
die Blöcke dann auch sicher kontinuierlich auf der Platte.
(Grosse) Dateien bzw. Blöcke, weil man dann die Fragmentierung
besser kontrollieren kann. Und wenn 1G zu gross ist,
dann halt 256MB.

Zur Verwaltung, wo denn nun ein Film auf der Platte überhaupt zu
finden ist, kann man ja immer noch im normalen Filesystem eine
Datei (wie die XML Datei für EPG Daten, bzw. sogar genau diese)
verwenden und darin die verwendeten Block-Nummern auflisten.

Ciao,
DboxBaer

[palace]

@saruman
So wie ich das verstehe, geht es ja auch nur um eine definierte Anzahl von definierten Files, die nur für das Timeshift angelegt und benutzt werden.

@dboxbaer
Beim schreiben wird deutlich mehr CPU benötigt als beim lesen; habe ich das so richtig gesehen? Dazu ist mir ein (weiss nicht mehr ganz genau) journal daemon aufgefallen, der edel und selbstlos mit ca 10-15% Last am start war...

Wenn man beim Schreiben / Lesen aufs IF die CPU beobachtet, sieht es meistens danach aus, als müsste das System es Packen können.
Selbst beim Aufnehmen & Abspielen gleichzeitig war die CPU nicht permanet am Anschlag.

Meine Frage geht auch dahin, wie man das gleichzeitige lesen&schreiben etwas intelligenter organisieren könnte?

[DBoxBaer]

@dboxbaer
Beim schreiben wird deutlich mehr CPU benötigt als beim lesen; habe ich das so richtig gesehen? Dazu ist mir ein (weiss nicht mehr ganz genau) journal daemon aufgefallen, der edel und selbstlos mit ca 10-15% Last am start war...

Das ist sehr gut möglich, hat mich bisher nicht wirklich interessiert. Tatsächlich hat EXT3 den Vorteil eines schnellen File System Checks, aber für Filme ablegen ist das eigentlich alles nicht so wichtig. Im Prinzip tuts ja eigentlich auch ein FAT32, besonders wenn die Dateien vorher vorhanden sind, dann wird FAT ja nicht mal mehr geändert. Warum im JTG Image nun aber genau diese Partionierung und dieses Filesystem verwendet wird, kann ich nichts zu sagen. Was aber nicht heissen soll, es sei schlecht.

Wenn man beim Schreiben / Lesen aufs IF die CPU beobachtet, sieht es meistens danach aus, als müsste das System es Packen können.
Selbst beim Aufnehmen & Abspielen gleichzeitig war die CPU nicht permanet am Anschlag.

Meine Frage geht auch dahin, wie man das gleichzeitige lesen&schreiben etwas intelligenter organisieren könnte?

Eben das kann man mit einer anderen Strategie sicher besser hinkriegen:
Niemand verlangt vom Linux Kernel und seinen Filesystemen, für Time-Shift Aufgaben in einem Video Rekorder gut zu funktionieren: Die sollen für allgemeine Unix-Anwendungen korrekt arbeiten. Innerhalb der Box sind aber Zugriffsrechte usw. eher kein Thema, jedenfalls bei den Filmen (denke ich mal...)

Und dann ist da noch der Cache (für die Platte, nicht von der von der CPU): Hauptspeicher zum Ausgleichen von Plattenzugriffszeiten zu verwenden _kann_ sinnvoll sein. Muss aber nicht. Immerhin hat die Platte selbst einen Cache, bei einigen Platten in ähnlichen Größenordnungen wie die Box selbst gerade mal RAM (übrig) hat, und die kann das wohl besser für andere Sachen gebrauchen :-) Im Prinzip kann das "Packen" der Daten also auch die Platte selbst machen.

Eigentlich sollte da ein "ganz einfaches" Experiment möglich sein: Im Neutrino direkt in das raw device für eine Partition schreiben und im Player direkt aus diesem raw-device lesen. Von mir aus (oder sogar besser?) ohne Neutrino mit eigenständigen Tools: Wenn das zwei eigene Prozesse sind, kann man die besser vergleichen. Theoretisch sollte es bei den beiden Tools auch gar nicht notwendig sein gross mit Buffern zu spielen etc (was bei der Neutrino-Lösung im Moment definitiv nicht stimmt, da macht es einen Unterschied). Wenn ich mich nicht irre macht der ein paar MB grosse Cache einer Platte doch ungefähr das gleiche...

Hmm: Ich meine das mal gesehen zu haben: Gibt es nicht ein billiges Kommandozeilentool für die Box, das einfach direkt in eine Datei recorded?

Ciao,

DboxBaer

[Liontamer]

apps/dvb/tools/stream soll er sich mal angucken
falls der kram aktuell noch im cvs ist
streamfile file vpid apid [ pid3 pid4 ... ] (HEX-values without leading 0x!)
filename without trailing '.ts'

[palace]

Bevor ich es wieder vergesse, wollte ich diesen Gedanken noch loswerden:
Chaching bringt imho nicht besoders viel, ausser vlt. ein Readahedcache um Verzögerungen beim schreiben oder seitens des OS auszugleichen.
Auf den Cache der HDD und dessen Verwaltung hat man ja keinen Einfluss, ausser dass man ihn evtl. abschalten könnte.

Da ich nicht weiss, inwieweit man das OS entlastet, indem man innerhalb eines Files arbeitet, bzw. auch nicht, wie man RAW in eine Partition hineinpinselt, Beziehe ich mich hier auf das Beispiel eines Files:

Ich stelle mir das bei Timeshift vor, wie einen wachsenden Rinbuffer, der die Daten vom drücken des Timeshiftbuttons bis zum aktuell gesendeten Signal halten muss.
Ausserdem denke ich nicht, dass hier der Plattenplatz limitieren muss, oder ob es nicht reicht, dass man 4 oder 8 gig definiert, wenn es damit einfacher zu händeln wäre(?); das wären imernoch bis zu 2-4 Stunden.

Des weiteren würde es wohl wirklich reichen die daten raw zu schreiben - wenn möglich, ganz ohne FS. Das einzige was gehen müsste wäre auf die Sektoren zum Schreiben und zum Lesen zeigen zu können.

Für Linux gibt es doch bestimmt ein Blockdevicetreiber der auf IDE aufsetzt...
Eigentlich muss man "doch nur" stur reinschreiben und beim lösen der pause von 0 an lesen?

[DBoxBaer]

apps/dvb/tools/stream soll er sich mal angucken
falls der kram aktuell noch im cvs ist
streamfile file vpid apid [ pid3 pid4 ... ] (HEX-values without leading 0x!)
filename without trailing '.ts'

Ich wusste doch irgendwie, dass ich da mal was gesehen habe...
Danke für den Tipp...

Chaching bringt imho nicht besoders viel, ausser vlt. ein Readahedcache um Verzögerungen beim schreiben oder seitens des OS auszugleichen.

Eben dafür sollte der Cache der Platte eigentlich gut reichen können:
Lookahead beim Lesen ist ja eigentlich genau das Gleiche was das Buffering vom Movieplayer macht... Ich hoffe natürlich, das eine IDE Platte sowas wie Lookahead beim Lesen auch macht.

Beim Schreiben will man natürlich auch nicht warten, das die Bytes wirklich in den Magnetpartikeln gelandet sind: Bis das soweit ist, bleiben die Daten gerne im Platten Cache. Im Prinzip können sie aber sobald wie irgend möglich eben dorthin: Im Hauptspeicher bringen sie niemandem was. (Aussnahme: Timeshift von wenigen Sekunden...)

Für Linux gibt es doch bestimmt ein Blockdevicetreiber der auf IDE aufsetzt...

Ist glaube ich ein char-Device, aber egal: Den liefert das IDE System des Kernels: zum Beispiel das Device File für eine Partitition. Da wird noch der Sektor Offset der Partition zur Sektor Position dazugezählt, und die ist quasi die Fileposition.

Eigentlich muss man "doch nur" stur reinschreiben und beim lösen der pause von 0 an lesen?

Ja, genau. Sobald ich allerdings eine Art "Keep" Taste drücke, weil ich diesen Film vielleicht später nochmal anschauen will, muss man sich auch mal von der 0 lösen können: Und zwar für den nächsten Film.

Ach ja: Schön wäre es natürlich, wenn das Ding immer laufen (=aufzeichnen) würde, ohne das ich erst Pause drücken muss.
Wenn mir dann in der Mitte oder am Ende einer Sendung auffällt, das muss ich mir unbedingt nochmal später anschauen, drücke ich "keep" und fertig.

Ciao,

DboxBaer

[Mac23]

Vielleicht wäre es ja auch schonmal interessant, wie sich unterschiedliche Dateisysteme auf die Performance auswirken.

Hier gibts einen Test (für i386-Systeme) wo z.B. JFS die geringste CPU-Auslastung hat.

Falls man hier schon spürbare Performanceauswirkungen erkennt, sollte die "RAW-Idee" noch besser sein...

[palace]

Ist glaube ich ein char-Device, aber egal: Den liefert das IDE System des Kernels: zum Beispiel das Device File für eine Partitition. Da wird noch der Sektor Offset der Partition zur Sektor Position dazugezählt, und die ist quasi die Fileposition.

Mh, d.H. die technischen Mittel wären da?
Man definiert eine Partition bestimmter Grösse,
und sorgt dafür, dass ein daemon permanent reinschreibt, wie in einen Ringbuffer...
Drückt einer auf Pause, merkt man sich die Position
Löst man die Pause, liest man ab der gemerkten stelle (während der daemon brav weiterschreibt (egal, welchen Sender ich schaue...

Eigentlich muss man "doch nur" stur reinschreiben und beim lösen der pause von 0 an lesen?

Ja, genau. Sobald ich allerdings eine Art "Keep" Taste drücke, weil ich diesen Film vielleicht später nochmal anschauen will, muss man sich auch mal von der 0 lösen können: Und zwar für den nächsten Film.
Ach ja: Schön wäre es natürlich, wenn das Ding immer laufen (=aufzeichnen) würde, ohne das ich erst Pause drücken muss.
Wenn mir dann in der Mitte oder am Ende einer Sendung auffällt, das muss ich mir unbedingt nochmal später anschauen, drücke ich "keep" und fertig.

Das mit dem Keep wirft bei mir noch fragen auf:
Irgend was muss mir den beginn des Films definieren...
Mache ich das, z.B. durch auslösen des Timeshifts?
Was, wenn ich Zappe?
Für einen Kompletten Film gibts ja noch das "klassische" Recording.
Wenn der "Buffer" z.B. 2h fasst, sollte mann dann auswählen können:
die letzten 15,30,45,n bis 120 Min? oder aktueller oder vergangener Film laut EPG?

Nach meinem erst mal einfachen Verständnis beginnt TimeShift mit Pause und endet spätestens mit einem Pufferüberlauf (noch nicht gesehene daten werden bereits wieder überschrieben) oder umschalten (ich will z.B. nicht, dass die Platte den ganzen tag läuft und muter schreibt).

Ausser dem würde ich von Keep erwarten, dass ich anschliessend ein xyz.ts in meinem Filme Ordner finde

Also gesucht wird ein Linuxer, der auf eine leere (FS lose?) Partition schreibt und beurteilen kann, ob die Last (deutlich) geringer ist, als auf einem ext3? So mal als erster Schritt?

[PT-1]

Bei meinem Sky+ stellt man fest ein wieviel Zeit man rueckwaerts immer aufnehmen moechte. Ich habe auf eine Std gestellt ...

[DBoxBaer]

Bei meinem Sky+ stellt man fest ein wieviel Zeit man rueckwaerts immer aufnehmen moechte. Ich habe auf eine Std gestellt ...

Eine Kombination mit EPG ist aber auch nicht dumm...

Zappen ist natürlich nochmal was anderes: Neben dem neu Anfangen kann man unter gewissen Umständen ja den anderen Sender auch weiter aufzeichnen... Wenn man auf Pro7 schaut, und in der Werbung kurz auf Sat1 wechselt, und dann zu spät zurück... Ach ja: bei Timeshift spule ich ja die Werbung weg. Ok...
(Und natürlich wäre auf Sat1 ja auch gerade Werbung...)

Ausser dem würde ich von Keep erwarten, dass ich anschliessend ein xyz.ts in meinem Filme Ordner finde

Das ist dann die Kür: Ein xyz Datei für den Player ist da noch einfach, der muss da nicht unbedingt .TS finden, hauptsache er weiss, wie man auf die TS Daten zugreift, und die sind ja "irgendwo" auf der Platte.
Spannend wird es, wenn man den Film aus der Box kopieren will...
Da auf der Platte TS-Daten gespeichert sind, gibt es da viele Möglichkeiten. Bleiben wir mit der Platte in der Box? Oder nehmen wir sie raus und stecken sie an einen PC? Letzteres ist dann fast einfach, da gibt es dann ein kleines PC Programm, das die Daten von dieser Partition eben lesen kann. Halte ich jetzt nicht für so schwierig, sogar unter Windows (was ähnliches habe ich im Prinzip schon mal gemacht).
Naja und in der Box? Einen modifizierten FTP oder einen Web Server vielleicht? Oder ein eigenes Tool-Päärchen (DBox und PC Programm)?

Vorher sollte man aber das Aufzeichnen auf die Platte perfekt in den Griff bekommen.

Ciao,

DboxBaer

[PT-1]

Beim umschalten auf einen anderen sender faengt der Timer dann eben wieder von vorne an..

Ist echt cool wenn man z.B. die Box auf ARD hat und 15 minuten nach Filmanfang nachhause kommt und dann zurueckspielen kann bis zum verpassten Anfang.

Das Spiel geht dann sogar noch weiter das man innerhalb dieser Stunden Record 2x drueckt dann nimmt er den Film von vorne bis zum ende auf

Ich finde es jedenfalls genial was du immer fuer Ideen hast die sich dann wie man ja amd IDE Interface sehen kann in Wirklichkeit umsetzt

DANKE !

[palace]

Hm...
Also im Moment ist doch zumindest alles da, das man für Timshift braucht und bei nicht so hohen bitraten funktioniert es ja beinahe

Am Treiber wird gearbeitet
Am Movieplayer wird gearbeitet
Aufnehmen geht ja auch

IDMA habe ich noch nicht so ganz verstanden.

Frage: Brauch man die Ringbuffer überhaupt oder reicht der Plattencache da nicht aus? Die Ringbuffer sind ja vor allem dazu da, Netzwerk Peaks auszugleichen. Evtl würde durch ein entfallen der Bufferverwaltung wieder etwas CPU Zeit frei?

Frage 2: Ich verstehe nicht, warum das SCHREIBEN auf das IF
a) So deutlich langsamer ist (12-15MBit zu 20-25MBit lesen)
b) So viel mehr CPU benötigt? (80-90% zu 15-30% lesen)
Es kommt mir so vor, als würde der Treiber einige CPU Zeit mit warten verbraten(?)
Kann man hier optimieren, in dem man die daten vlt ATA gerecht häppchen/blockweise ans IF liefert?
Aufgefallen ist mir noch, dass die Box deutlich geschmeidiger arbeitet, wenn man per FTP daten aufs IF schiebt im vgl. zur Aufnahme (cs 60-70 statt 90%)

Grüsse

[palace]

Hi,
Nachdem Tests mit ext2 gezeigt haben, dass durchaus höhere Datenraten mit einem leichteren FS möglich sind kam mir noch ein Gedanke:

Lesen+Abspielen (MP) oder Schreiben (Directrecording) benötigen für sich keine 50% CPU Last (ARD & Co). Aber beides zusammen will nicht.
Wird ext3 verwendet, krallt sich zusätzlich der Journal Daemon noch einiges an Zeit...
So drängt sich mir der Verdacht auf, dass die Box sich (derzeit noch) sehr schwer tut, mehrere Dateien gleichzeitig zu bedienen oder die Selbe lesend und schreibend...

Mein Gedanke ist jetzt folgender: Die mit ext2 gemessenen Geschwindigkeiten (r und w) liegen bei >2,5MByte/s; grob überschlagen also dass Doppelte der bisher maximalen Bitrate inkl. aller Audiostreams.

Wäre es denkbar, Timeshift so zu organisieren, dass bei gleichzeitigem Schreiben und Lesen in Wirklichkeit nur abwechselnd gelesen oder geschrieben wird?

- Ich drücke Pause
- Ein (schreib) Puffer wird mit n MByte gefüllt
- Der Puffer wird am Stück geschrieben

- Ich löse die Pause
- Es wird gewartet, bis der Schreibpuffer "weggeschrieben" ist
- Es wird der Wiedergabepuffer mit n MByte gefüllt
- Wiedergabe des Wiedergabepuffers + schreiben des Schreibpuffers
...

Versteht jemand, wie ich das meine?

Also man liest / schreibt alternierend

Vorteile: Man hat nur einen Prozess (vorzugsweise Neutrino), der auf die HD zugreift und das entweder lesend oder schreibend
Man hat weniger Kopfbewegungen

Prinzpiell ist schon da, was benötigt wird:
Wabberqueue des MP
Ringbuffer des Directrecordings.

Vlt. ist es ja möglich aus dem Directrecording und MP die notwendigen Core Komponenten zu extrahieren und zu vereinfachen und z.B. erstmal zu nem Plugin zusammen zu Bauen, zumal eine mittelfristige Integration auch des MPs in neutrino recht cool wäre (BSP. Blättern im EPG oder Starten von Plugins auch während der .ts Wiedergabe)

[DBoxBaer]

Hi,
Nachdem Tests mit ext2 gezeigt haben, dass durchaus höhere Datenraten mit einem leichteren FS möglich sind kam mir noch ein Gedanke:

Lesen+Abspielen (MP) oder Schreiben (Directrecording) benötigen für sich keine 50% CPU Last (ARD & Co). ...

Das ist genau der Grund, warum ich mit dem Gedanken spiele, das ein eigenes Filesystem für die Filme die beste Wahl sein könnte:
Der Grund für Ext3 wäre eigentlich der recht schnelle Filesystem-Check, der aber für die Filme relativ unwichtig ist: Wenn man die Box beim Aufzeichnen eines Films aussteckt ist schlimmstenfalls eben dieser ganze Film weg. Nur die anderen haben ja damit gar nichts zu tun.
Also insgesamt sind die Anforderungen an ein "Film-File-System" eben andere als die, die ext2/3 lösen sollen. Bei einem PC hat man genug Luft, das man sich den Overhead leisten kann, in der DBox evtl. nicht.

Wenn die CPU und das IDE Interface ideal verwendet werden, wird auch das Lesen und Schreiben gleichzeitig möglich sein, selbst für hohe Bitraten. Da der Avia-Teil für mich noch eine grosse Unbekannte ist, könnte ich mir eigentlich eher von dort Probleme erwarten: Wenn ARD tatsächlich mit ~9MBit/s sendet, muss man das ja in den Avia rein und rauspumpen.
Kann ja übrigens sich mal jemand hinsetzen und was basteln, das es nur ein MB oder so verzögert wird, also ohne Platte -> 1s "Timeshift" Delay :-)
Wenn das geht, und noch etwas CPU übrig ist, kriegen wir das mit der Platte auch noch hin.

Ansonsten: weil die Frage kam: IDMA ist evtl. eine Möglichkeit, die echten DMA-Modi der Platte zu verwenden. Damit kann man nicht nur die Datenrate steigern (theoretisch wenigstens), sondern insbesondere die CPU Last senken. Beides sollte hilfreich sein :-)

Ciao,

DboxBaer

[palace]

Ich möchte das an dieser Stelle noch mal hoch holen...

Leider kann ich das nur aus meiner LaienSicht darstellen:

Wie wäre es, dem IDE Treiber selbst das lesen und schreiben ais und in den AVIA beizubringen?

Derzeit sind ja jeweils bis zu 4 Caches im Spiel:

HDD Cache -> FS Cache -> Wabber Queue -> Avia Buffer
bzw.
Avia Queue -> Ring Buffer - > FS Cache -> HDD Cache

Zusätzlich noch Übergänge User <-> Kernel Space
Ich weiss nicht, in wie weit da mit Pointern gearbeitet wird / werden kann

Was wäre, wenn man dem IDE Treiber selbst das lesen aus und schreiben in den AVIA beibringt und sich dabei minimalistisch an ext2/3 Konventionen hält?

Da ich nucht weiss, wie genau ext2/3 arbeitet jetzt nur Philosophisch:
Beim lesen schneide ich die Nutzdaten aus den Raw daten aus und übergebe sie dem AVIA

Beim schreiben Flansche ich die extx Daten an die Nutzdaten ran und schreibe sie weg. Dazu müsste man natürlich ermitteln, wo die freien Bereiche auf der HDD sind und am Anfang / Ende erzeuge ich einen Fileeintrag im FS.

So stelle ich mir einen Kompromiss aus Raw lesen/schreiben und eigenen FS vor.

Ist das aus DEV Sicht völlig abwegig?

[sumsum]

zur zugriffsgeschwindigkeit fällt mir nur ein, das man keine filesysteme mit journaling funktionen nehmen sollte.
jounaling filesysteme sind stabiler, wenn man das system plötzlich ausschaltet, da mehr FAT informationen auf die platte geschrieben werden, die das wiederherstellen des filesystem beim starten beschleunigen ohne lange filesystemchecks und fat eintrags reorganisationen duchzuführen.

vielleicht als tip: schaut euch mal die funktion des swapfilesystem an.
möglicherweise kann man ein swapsystem anlegen oder ein neues quasiswap fs erstellen, was man für dieses "raw" schreiben benutzt.

ansonsten sollte man bei ext2 bleiben.

eine andere möglichkeit ist auch eine datei anzulegen, die man als quasi partition mounted.

[DBoxBaer]

vielleicht als tip: schaut euch mal die funktion des swapfilesystem an.
möglicherweise kann man ein swapsystem anlegen oder ein neues quasiswap fs erstellen, was man für dieses "raw" schreiben benutzt.

Grundsaetzlich hatte ich in meinem Posting ja das Gleiche gesagt, ein eigenes Filesystem kann eine Loesung sein, weil man da alles genau unter Kontrolle hat. Auch gegen ein Journal spricht dabei nicht unbedingt was, wenn es nur selten was speichern muss. Waehrend ich einen Film aufzeichne gibt es zwei Arten von Daten, die aufgezeichnet werden: Audio/Video Daten und Metafinformationen. Die Datenmenge der AV-Daten sprengt sowieso alles, aber die Metafinformationen (welcher Film, wann gespeichert, wie lang, wo gespeichert etc.) sind real Kleinkram, allerdings recht wichtig...
Ich sehe da kein riesen Problem, das muss man halt einfach mal anfangen.

Bleibt die Schnittstelle zum Avia: Bekommt man es hin, die Daten aus dem Chip ins RAM und nach ner kurzen Zeit wieder zurueck zu pumpen? Und zwar bei den hoechsten Datenraten, die real verwendet werden? Wenn ja, dann kriegen wir das bestimmt auch durch die Platte durch.

Ciao,

DboxBaer

[sumsum]

vielleicht als tip: schaut euch mal die funktion des swapfilesystem an.
möglicherweise kann man ein swapsystem anlegen oder ein neues quasiswap fs erstellen, was man für dieses "raw" schreiben benutzt.

Grundsaetzlich hatte ich in meinem Posting ja das Gleiche gesagt, ein eigenes Filesystem kann eine Loesung sein, weil man da alles genau unter Kontrolle hat.

Das hab ich schon verstanden dboxbaer, ich wollte nur darauf hinweisen, das man evt schon was "fertiges" adaptieren könnte, bevor man sich groß Gedanken über eine Filestrukturverwaltung für ein Rawdevice macht
Recht hast du natürlich das der Kernel auf Grund seiner Modularität und verschiedene API Ebenen gerade bei solchen zeitkritischen Sachen für diesen Prozessor einfach oversized ist. Das Problem wird sich verstärken je weiter sich der Kernel fortentwickelt. Abhilfe würde evt ein monolithischer Kernel schaffen, der ohne Module compiliert ist und nur Treiber enthält die er benötigt. Da kann man dann leider zur Laufzeit nichts mehr nachladen.
Ich weis jedoch nicht mehr, ob es bei den neueren Kernel überhaupt noch möglich ist, ohne den gesamten Modulsupport zu kompilieren.

[just_me]

ansonsten sollte man bei ext2 bleiben.

Andere Väter haben auch schöne Töchter!

JFS und XFS werden auch gerne für Streaminganwendungen genutzt.

Der folgende Link untersucht unter anderem die CPU Last beim Schreiben, Zeit für mount und unmount der Dateisysteme, Zeit fürs Löschen grosser Dateien:
"Filesystems (ext3, reiser, xfs, jfs) comparison on Debian Etch"
http://www.debian-administration.org/articles/388
(dort sind auch noch unter "References" zwei weitere Tests angeführt)

JFS oder XFS kommen dabei gut weg. JFS wird in Bezug auf Rechenleistung gelobt. Ob JFS oder XFS überhaupt Frage kämen (Größe im Kernel und Größe der Userspace tools), steht latürnich auf einem anderen Blatt...

[PauleFoul]

Auch interessant:

Vergleich von Linux- Dateisystemen

http://oss.sgi.com/projects/xfs/


Gruß
____Paule

[schaeaef]

in sachen timeshift tut sich ja leider nicht viel ...

[amigaherbie]

in sachen timeshift tut sich ja leider nicht viel ...

Ich denke da muß man realistisch sein: das gibt die Hardware einfach nicht her. Ich weiß nicht, wieviel Optimierungspotential noch in der d-box 2 steckt. Aber ich bin da eher pessimistisch eingestellt. Es ist eh unglaublich, was alles mit so uralter Hardware (auch Computersicht gesehen) möglich ist. Vor allem unter dem Aspekt, daß das niemals in einem Lastenheft aufgetaucht ist. Hätten alle Beteiligten des Tuxbox Projekts vollen Zugriff auf die ganzen Datenblätter und die anderen 'Geheimdokumente', wäre die Box heute sicherlich noch besser. Aber auch mit dem erreichten darf man mehr als zufrieden sein.

Es kommt aber einmal der Punkt, wo einfach mehr Rechenpower gefragt ist. Die Box kann mp3 gerade mit Ach und Krach abspielen mit dem 66 MHz Prozessor. In meinem Handy (xda mini) steckt dagegen ein 416 MHz starker Prozessor, dem mp3 nicht wirklich schwer fällt. Insofern müßte, vielleicht auch im Hinblick auf HDTV, eine neue d-box entwickelt werden mit den heutigen technischen Gegebenheiten. Nur fürchte ich, daß das mit der heutigen Restriktionspolitik (auch aus Hollywood) ein schier unmögliches Unterfangen wird. Ansonsten gäbe es sicherlich bald ein entsprechendes Modell von der dreambox oder Konsorten...

[schnixx]

Ich muss mal dumm fragen: Was ist denn mit Timeshift gemeint?
Eine timerbasierende Aufnahme geht doch ...