Wo is'n DboxBaer?

Wenn ich mir die Beiträge von DboxBaer aufliste, bekomm' ich den letzten von Anfang Oktober...?!

Wo is denn der 'Schöpfer der Heiligen Platine' hin?

Melde dich...Du fehlst uns!

Und es gibt Ihn doch, den Schöpfer...es lebe Intelligent Design

Da ich ja nicht so unbedingt zu den Lieblingen der Tuxboxler gehöre, bin ich vielleicht der falsche, aber...

wäre es nicht angemessen, jetzt nachdem das IDE-IF den ersten Härtetest bestens bestanden hat, DBoxBaer einen Ehrenplatz zu geben...

...gibts hier sowas wie eine Ahnengalerie?

Die Entwicklung des IDE-IF ist nämlich wirklich eine einzigartige Leistung

Du meinst so eine Art "Hall of Fame"

Ja genau...mit Foto

Meine letzte Info von ihm ist, daß er im Moment zu viel um die Ohren hat und deshalb selbst zum Forumlesen kaum kommt. Er wollte aber bei Zeiten nochmal an den letzten Details am Treiber arbeiten.
Günther

Günther hat geschrieben:Meine letzte Info von ihm ist, daß er im Moment zu viel um die Ohren hat und deshalb selbst zum Forumlesen kaum kommt. Er wollte aber bei Zeiten nochmal an den letzten Details am Treiber arbeiten.
Günther

Moin!

Es gibt mich noch, ich lebe, und es hat mich niemand vergrault. Einfach nur zuviel um die Ohren. Ich will aber mal sehen, das ich wieder etwas Zeit finde und zum Beispiel die CD-ROM Geschichte soweit zum Laufen bringe.

Komischerweise hat mein DVD Player aufgegeben und meine Frau meinte, da sei doch ein DVD Brenner in der D-Box, warum kann man denn damit nicht Filme schauen... Äh, naja, also das ist mal nur so eingebaut...

Also nicht aufregen. Und den Inhalt des CPLD zu veröffentlichen habe ich auch nicht vergessen, das steht weiter auf meiner Todo-Liste!

Ciao,

DboxBaer

Beitrag von **Gorcon** » Mittwoch 27. Dezember 2006, 16:37

DBoxBaer, hattest Du nicht auch mal versucht den IDE-Treiber auf DMA Modus umzustellen? (oder ist das im "Sande" verlaufen bzw. nicht durchführbar?)

Gruß Gorcon

DBoxBaer hat geschrieben:
Günther hat geschrieben:Meine letzte Info von ihm ist, daß er im Moment zu viel um die Ohren hat und deshalb selbst zum Forumlesen kaum kommt. Er wollte aber bei Zeiten nochmal an den letzten Details am Treiber arbeiten.
Günther
Moin!

Es gibt mich noch, ich lebe, und es hat mich niemand vergrault. Einfach nur zuviel um die Ohren. Ich will aber mal sehen, das ich wieder etwas Zeit finde und zum Beispiel die CD-ROM Geschichte soweit zum Laufen bringe.

Komischerweise hat mein DVD Player aufgegeben und meine Frau meinte, da sei doch ein DVD Brenner in der D-Box, warum kann man denn damit nicht Filme schauen... Äh, naja, also das ist mal nur so eingebaut...

Also nicht aufregen. Und den Inhalt des CPLD zu veröffentlichen habe ich auch nicht vergessen, das steht weiter auf meiner Todo-Liste!

Ciao,

DboxBaer

Ich hoffe das Du dann noch etwas Zeit findest die Treiber / Ansteuerung
des IDE-IF weiter zu optimieren. Damit die kleinen Plobleme mit ARD
und Konsorten auch noch abgestellt werden können.

Ich denke das wäre den meisten Usern wichtiger als eine DVD Funktion...

Gruß
____Paule

...kann mich der obigen Meinung nur anschließen...

...obwohl die intellektuelle Herausforderung beim internen DVD-Laufwerk natürlich größer ist...hab ich vollstes Verständnis

...aber wirklich unsterblich (für die Hall of Fame) wirst du (DboxBaer) erst, wenn ARD auf der Nokia flutscht wie sonst was...

Zusatz:
Außerdem...falls dann ein Firmwareupgrade d. IFs notwendig ist...und das dann die Leut selbermachen...hat Gurgel dann wieder eine Menge an neuen Bestellungen

Charles Darwin jun. hat geschrieben:...kann mich der obigen Meinung nur anschließen...

...obwohl die intellektuelle Herausforderung beim internen DVD-Laufwerk natürlich größer ist...hab ich vollstes Verständnis :wink:

...aber wirklich unsterblich (für die Hall of Fame) wirst du (DboxBaer) erst, wenn ARD auf der Nokia flutscht wie sonst was... :wink: :) :D :lol:

Zusatz:
Außerdem...falls dann ein Firmwareupgrade d. IFs notwendig ist...und das dann die Leut selbermachen...hat Gurgel dann wieder eine Menge an neuen Bestellungen :lol:

Zuviele Ideen spuken in meinem Kopf herum... Leider ist der CPLD so voll. Wenn man mehr Speicher im CPLD hätte, wäre das alles kein Problem. Leider hat Gurgels Version ja auch noch weniger Pins, sonst hätte man da vielleicht ein schnelles SRAM dranhängen können.

Eine neue Version des Boards mit On-Chip RAM in einem FPGA/CPLD (so 1KB reicht schon) und das Ding zieht ab:
Zur Platte mit UDMA Transfers, und zur Box mit Bursts. D.h. statt einem 32 Bit Wort gleich 4 Stück -> Datenrate wie memcopy im Hauptspeicher!

Das wird mit "unserem" CPLD aber nix... Eine neue Firmware schliesse ich aber auch nicht aus: Gibt aber eine wichtige Sache, die ich (bzw. besser man) dabei hinbekommen müsste:
Und zwar den Fifo umbauen in dem Ding, so dass wieder einige Flip-Flops übrig bleiben.
Ich hatte mal irgendwann die Idee, das man eine "Copy Loop" des Treibers auch im Blindflug kopieren lassen könnte, also ohne das dauernd gecheckt wird, ob genug Daten da sind: (Hier geht es um Transfers eines kleinen Datenblocks, nicht um TS Daten!):
Wenn der Chip "mitzählt" wieviele Daten korrekt transportiert wurden und das Bearbeiten des Fifos unterbricht, kann der Treiber an dieser Stelle nochmal aufsetzen und weitermachen.
Wenn der Treiber im Schnitt eigentlich mit der richtigen Geschwindigkeit arbeitet, kann man die "Prüf" Zugriffe, ob noch alles stimmt, seltener durchführen und die Transferrate steigt.
Nochmal einfacher: (Schreiben als Beispiel)
Heute prüft der Treiber zuerst ob Daten in den CPLD passen: Bis zu 4x16 Bit, oder 2x32 Bit gehen da im Moment in den Fifo rein. Die werden geschrieben und dann wird wieder geschaut, wieviel Platz jetzt ist. Da die Daten automatisch zur Platte weiter fliessen, ist nun natürlich meistens bereits wieder Platz: Evtl. sogar wieder 4x16 Bit!. In dem Fall bedeutet das aber, das man Zeit verschenkt hat mit eben dieser Prüfung... Und selbst wenn nur 3x16 Bit Platz ist: Nach der Prüfung sind es "wahrscheinlich" doch schon wieder 4x16 Bit, nur weiss der Treiber das nicht sicher.

Die Idee wäre nun, einfach sofort wieder zwei Worte zu schreiben: Das kostet selbst ja auch Zeit, und zur Platte gehen ja auch die Daten weiterhin raus. Wenn man "Pech" hat, ist aber zum Beispiel der vierte Zugriff zu früh, also nicht genug Platz im Chip. Dann würde der Chip nun sozusagen ein "zu schnell" Flag setzen und sich "drei" merken (weil das der letzte war, der geklappt hat). Macht die CPU nun noch vier Zugriffe, also insgesamt acht, werden die weiteren vom Chip erstmal ignoriert, denn zur Platte muss die Reihenfolge ja stimmen, da darf nichts fehlen.
Prüft der Treiber jetzt, sieht er, das er die letzten fünf Zugriffe wiederholen muss.
Wenn das oft passiert, sollte der Treiber einfach zwischen den Zugriffen länger warten, mit der Wirkung dass meistens alle acht Zugriffe glatt durchgehen ohne Pause.
Evtl. kann man dann sogar diese Prüfpunkte noch seltener durchführen...

Wenn jemand da was probieren will:
Man schreibe eine Loop, die etwa alle 240ns ein 32 Bit Wort ausgibt, und das etwa 128x. Denn wenn es gelingt, diese Zeit sehr genau zu treffen, braucht man eigentlich gar keinen Fifo: Zur Platte haben wir 120ns pro 16Bit.

Allerdings kann man das vielleicht auch mit der aktuellen Firmware hinbekommen: wenn nämlich bei jeder "Prüfung" herauskommt, das genau 1x32 Bit in den Fifo passen, wird abwechselnd geschrieben und geprüft. Dafür müsste man das Timing halt recht exakt treffen. Was aber möglich sein sollte...

Ah, bevor ich das vergesse: Optimiere ich da nicht schon wieder an der falschen Stelle? Theoretisch lassen sich hier 16MByte/s erreichen. Nur hat der Treiber heute evtl. schon 8MByte/s in dieser Loop. Wo bitte verschwindet der Rest?
Und zwar eben in so einem ARD Aufzeichnungsfall. Wo laufen die Daten lang, wo wird kopiert, wo wird gewartet. Und ist es überhaupt die Transferrate oder sind es vielleicht die Interrupts die ein Problem machen?

Leider gibt es hier zu wenige Leute, die sich auf dieser Ebene mit der Hardware und der Software auskennen oder beschäftigen.
Statt dessen wird sich übers Image-bauen gestritten.

Ciao und einen guten Rutsch!

DboxBaer

Jo, aber ich denke auch Seitenlange Postings mit immer 1000 neuen
Ideen bringen uns nicht wirklich weiter.

Die Hardware ist nunmal wie Sie jetzt ist. Wobei ich mich schon Frage
wenn es klar war das ein kleiner Puffer enorme Performance bringt, dies
nicht gleich im Layout vorgesehen wurde...

Ansonsten würde ich sagen mal eine Idee aufzugreifen und zu testen.
Ein erstes Diff wäre ja mal ein Anfang. Es gibt hier genug Leute (mich
eingeschlossen) die gerne bereit sind ausführliche Vergleichtests zu
fahren, um auf die richtige Spur zu kommen.

Also lasst uns doch mal anfangen und nicht immer nur philosophieren...

Guten Rutsch ins neue Jahr!

Gruß
____Paule

Moin!

Naja:
Erstmal ist die Hardware nicht nur wie sie ist, denn auch die kann man anpassen. Offensichtlich, sonst gäbe es das IDE If ja nicht.

Das Layout habe ich nicht zu verantworten, sondern es ist das Ergebnis meine Version in einen möglichst günstigen Chip zu quetschen...

Und: Viele Leute zum Testen brauch ich nicht: Wenn ich dazu komme, daran zu arbeiten, ist es ganz einfach: Entweder es ist besser oder eben nicht. Dieses rumprobieren, wenn ich dies mache oder jenes, dann ist es bei dem einen besser und bei dem anderen nicht, das ist nicht professionell: Da kann ich auch ne Wünschelrute nehmen.

Woran klemmt es wirklich? Optimieren sollte man genau dort.

Ansonsten: Wenn ich schon nicht dazu komme, an der realen Box zu arbeiten, dann kann ich wenigstens meine Ideen bzw. Überlegungen aufschreiben: Das ja auch aus dem Wunsch heraus, das sich vielleicht mal jemand selbst was probiert und dann konkret eine Verbesserung benennt.
(Was im übrigen ja ständig passiert, und das ist auch gut so...). Oder, und das wäre genauso gut, einen Fehler in meinen Überlegungen entdeckt und so mir einen Irrweg erspart.

Ciao,
DboxBaer

@DBoxBaer

Dann würde ich, wie von Dir bereits angesprochen, mal das relativ
breit gestreute ARD Problem angehen. Der Fehler liegt bestimmt
an einer gemeinen Stelle und wird dann allgemeine Verbesserung
bringen.

Auch das es mehr Probleme mit dem 600er als mit dem 500er gibt
könnte man mal untersuchen.

Ansonsten läuft die ganze Sache (zumindestens bei mir) ja sehr stabil
und ist eine riesen Bereicherung für das Projekt.

Zur Hardware bleibt ja dann nur zu hoffen, das Gurgel wenn er mal
wieder atmen kann, eine PowerEdition für gutes Geld rausbringen
könnte. Was dann damit möglich wäre könntest Du ja aufzeigen...

Gruß
____Paule

@Dboxbaer
Danke dir für die ausführliche Beschreibung...

...das sind die ersten konkreten Überlegungen, die ich hier im Forum bisher gesehen habe!

Natürlich wäre es den derzeitigen Usern lieber, wenn die Platine, so wie sie ist, ausreicht um alle Kanäle (ausser HDTV) aufzunehmen...

...und ich glaube, dass sobald alles für alle offen zugänglich ist, sicherlich der eine oder andere Fix zustandekommt...

Würde im Moment eher davon abraten, mehrere Versionen d. Platine zu produzieren...

...ohne vorher Treiber- u. Firmwareoptimierungen versucht zu haben...

...die Gefahr ist nämlich, dass dann nix mehr reproduzierbar wird...ein Plug-n-Play Betriebssystem gibt's ja no net für die d-box

Beitrag von **Günther** » Montag 1. Januar 2007, 14:46

DBoxBaer hat geschrieben:Ah, bevor ich das vergesse: Optimiere ich da nicht schon wieder an der falschen Stelle? Theoretisch lassen sich hier 16MByte/s erreichen. Nur hat der Treiber heute evtl. schon 8MByte/s in dieser Loop. Wo bitte verschwindet der Rest?

Vielleicht hier:
http://forum.tuxbox-cvs.sourceforge.net ... hp?t=42962
?
Die Sache ist damals eingeschlafen, aber vielleicht weiß Carjay ja inzwischen mehr?8)

Günther

Beitrag von **DBoxBaer** » Montag 1. Januar 2007, 19:31

Günther hat geschrieben:
DBoxBaer hat geschrieben:Ah, bevor ich das vergesse: Optimiere ich da nicht schon wieder an der falschen Stelle? Theoretisch lassen sich hier 16MByte/s erreichen. Nur hat der Treiber heute evtl. schon 8MByte/s in dieser Loop. Wo bitte verschwindet der Rest?
Vielleicht hier:
http://forum.tuxbox-cvs.sourceforge.net ... hp?t=42962
?
Die Sache ist damals eingeschlafen, aber vielleicht weiß Carjay ja inzwischen mehr?8)

Günther

Das habe ich tatsächlich komplett übersehen...

Tatsächlich müsste man aber mal messen, wo da was und wie lange passiert. Ich habe mal irgendwann die Transfers mit "dd" angeschaut (mit Oszilloskop an der Platte), und dabei bemerkt, das insgesamt mehr Pausen gemacht wurden als Übertragung. Danach war damals ganz schnell meine Lust weg an den Loops so richtig zu optimieren...

Darum mal ein Vorschlag für einen Test, den man auch ohne Assembler hinbekommen könnte, nur irgendwo ne Kleinigkeit anpassen:

Wenn man direkt ins device schreibt, also z.B. in die Partition (/dev/.../disc2 oder wie das auch immer im Moment bei der DBox heisst...). (Mit "schreiben" meine ich natürlich "aufzeichnen"). Vorsicht: Die Formatierung dieser Partition ist dann kaputt, also nur probieren wenn man weiss was man tut :-)

Wenn das klappt (oder auch nicht, also weiter Daten verloren gehen...), kann man mal anfangen, da das eine oder andere zu "instrumentieren". Da habe ich zwei Ideen im Kopf: Einmal direkt an der Platte messen, mit nem Oszilloskop. Ist aber blöd zu machen, und kann auch nicht jeder, und die Auswertung ist auch nicht so einfach. Daher wäre die Idee eine Softwarelösung, und da gibts auch was... Ich glaube in meinem Treiber war/ist da auch schon was drin (allerdings nur für Problemfälle, stammt noch aus meiner "Interrupts funktionieren nicht"- Zeit)
Nämlich dieses Timer-Ding der CPU. Der liefert _sehr_ genaue Zeiten! Kombiniert mit einem schönen Ringbuffer könnte man einen Trace im Kernel aufzeichnen, wann was stattgefunden hat und wie lange etwas gedauert hat.
Muss man noch was zum Auslesen basteln, und was zum Auswerten.
Wird nun was optimiert, kann man die Werte vergleichen. Dann weiss man wenigstens sicher: Ist man wirklich besser geworden?

Kandidaten zum Messen sind dann zum Beispiel der Zeitpunkt wann die CPU anfängt Daten vom Avia zu holen und wann (eben diese Daten?!) beim IDE Device ankommen. (Um mal ganz aussen anzufangen...). Vielleicht ist es ja ganz einfach, das jeweils zuzuordnen.

Ja, und dann noch ne Idee: Da man im Moment sehr davon abhängig ist, welche Daten man gerade empfängt: Hat irgendjemand eine Idee, wie man da was einspeisen könnte, das so ähnliche Datenmengen generiert wie "Problemsender"? Bei gleicher CPU Belastung?! Muss ja nicht sinnvoll sein, hauptsache reproduzierbar, und natürlich nicht gerade über die Antenne und den Tuner, Prüfsender hat wohl kaum jemand zu Hause, sondern irgendwo weiter hinten im System. Natürlich aber auch nicht zu weit hinten :-) Kann man den Avia selbst dazu veranlassen?

Doch zurück zum ersten Vorschlag:

Den Recording Code mal so zu ändern, das er ins Device File aufnimmt, könnte sich auf die Vorgabe des Dateinamen beschränken, und höchstens noch ein paar Kleinigkeiten. Sämtliche Filesystem Probleme wären dann doch schonmal umgangen. (Habe ich aber schon mal vor langer Zeit vorgeschlagen...).
Darum bitte ich mal um _konkrete_ Vorschläge wie man das schön einfach hinbekommt!

In diesem Zusammenhang fällt mir das Thema Schreibcache ein:
Es ist sicher nicht sinnvoll, das die Box selbst im Hauptspeicher irgendwas cached beim Aufzeichnen (bei Timeshift siehts evtl. anders aus)

Aber die Platte selbst kann dies ja auch, und mir fällt eigentlich kein vernünftiger Grund ein, warum diese das nicht tun sollte: Es sei denn ihre Firmware hat eine (für uns) schlechte Strategie. Das wäre dann natürlich interessant und könnte auf Empfehlungen für bestimmte Platten hinauslaufen?!

Sobald ich wieder zu Hause bin werde ich auch wieder selbst was probieren können. Spätestens bis die Teile für meine Portalfräse endlich gekommen sind: Die wird dann wohl auch Zeit von mir in Anspruch nehmen :-)

Ciao,

DboxBaer

Beitrag von **Carjay** » Dienstag 2. Januar 2007, 23:21

DBoxBaer hat geschrieben:Nämlich dieses Timer-Ding der CPU. Der liefert _sehr_ genaue Zeiten! Kombiniert mit einem schönen Ringbuffer könnte man einen Trace im Kernel aufzeichnen, wann was stattgefunden hat und wie lange etwas gedauert hat.

Ich habe beim 2.6er Kernel mit Hilfe des relayfs mal probiert, so etwas umzusetzen, dabei hatte ich allerdings "seltsame" Effekte. Ich weiß nicht, ob die gemeinsame Buslast von Demux, IDE-Interface und zusätzlich das Schreiben der Logs nicht zuviel wird. Jedenfalls wirkte die Box ausgebremst.

Ich hatte das allerdings nur mal kurz überprüft und danach dann keine Zeit mehr (und auch im Moment nicht so wirklich). Ginge vielleicht besser wenn man die Anzahl und das was geloggt wird noch reduziert.

Ich denke, am sinnvollsten wäre es aber, das über GPIOs mitzuloggen, dafür braucht man allerdings einen Logikanalyzer, den habe ich nicht.

Mit 2 GPIOs könnte man ja bereits 4 Stellen kodieren, ich würde dann ein Bit als Prolog/Epilog-Anzeiger für die Routinen nehmen und den Rest für die jewilige Routine. Oder so etwas in der Art.

@Carjay
Kann es sein, dass du der einzige (noch übriggebliebene) "Fähige" hier im Tuxbox-Forum bist? Ich meine von der alten Garde, weil DboxBaer hat ja eine Sonderstellung

Wenn dich auch noch deine Frau mal ein Wochenende am Problem der d-box (mit IF) arbeiten ließe, bin ich mir sicher, dass du einen Workaround zaubern könntest...

...kann sonst NIEMAND auf die Vorschläge und Fragen von DboxBaer antworten??? Is ja echt deprimierend...

Beitrag von **PauleFoul** » Mittwoch 3. Januar 2007, 16:13

Charles Darwin jun. hat geschrieben: ...kann sonst NIEMAND auf die Vorschläge und Fragen von DboxBaer antworten??? Is ja echt deprimierend...

Antworten schon, aber es würde uns nicht wirklich weiter bringen...

Ich denke das ganze Thema ist so tief, dass es wirklich nur die Spezialisten
verstehen und bearbeiten können. Ich meine das komplexe Schaltungen
und Vorgänge, kann man sich nicht mal so eben reindenken...

Mir bleibt nur zu hoffen das einer der beiden mal ein paar ruhige Minuten
findet um das eine oder andere auszuprobieren. Ansonsten wirde es
hier kaum weiter gehen...

Gruß
____Paule

Beitrag von **BigHardy** » Mittwoch 3. Januar 2007, 20:29

@Carjay

Ein paar Fragen:

Wo wohnst du, ausser in oder in der Nähe einer DBox?
Wie müsste der Logikanalyzer ausgestattet sein?
Was müsste er alles können?
Wie lange bräuchtest Du Ihn?

Wenn ich dazu Antworten bekäme, könnte ich mich mal umhören.

Hardy

Beitrag von **DBoxBaer** » Mittwoch 3. Januar 2007, 23:03

Carjay hat geschrieben:
DBoxBaer hat geschrieben:Nämlich dieses Timer-Ding der CPU. Der liefert _sehr_ genaue Zeiten! Kombiniert mit einem schönen Ringbuffer könnte man einen Trace im Kernel aufzeichnen, wann was stattgefunden hat und wie lange etwas gedauert hat.
Ich hatte das allerdings nur mal kurz überprüft und danach dann keine Zeit mehr (und auch im Moment nicht so wirklich). Ginge vielleicht besser wenn man die Anzahl und das was geloggt wird noch reduziert.

Das alte Henne Ei Problem...

Carjay hat geschrieben:
Ich denke, am sinnvollsten wäre es aber, das über GPIOs mitzuloggen, dafür braucht man allerdings einen Logikanalyzer, den habe ich nicht.

Im Prinzip richtig: So hatte ich das mit einem 4 Strahl Oszi auch schon gemacht, aber dann ist die Auswertung wieder schwierig, weil man ja viele Zugriffe anschauen will, und die Trigger Bedingung schwer zu finden ist. Bei meinen Int-Problemen war das noch ganz gut.

Was eigentlich gut gehen müsste wäre aber ein paar 100KB Memory statisch in einem Treiber verbraten und darein dann 32-Bit Worte zu speichern, was nun gerade abging, mit nem 32 Bit Zeitstempel. Und dann einer Userlevel-Applikation Zugriff geben, die diesen Speicher auslesen kann.
Das Eintragen eines Wertes dauert dann auch nicht wesentlich länger als ein GPIO Bit Wackeln...
So oder so könnten wir uns mal eine Trace-Log API ausdenken, die dann auch von verschiedenen Treibern benutzt werden kann: Im Prinzip ein Call in der Art "void Dbox2TraceLog(unsigned int value)" reicht ja (fast?) schon: Wenn der an GPIOs wackelt oder das speichert ist schonmal egal: Hauptsache für verschiedene Teilsysteme gemeinsam nutzbar. Edel wird das wenn die Zugriffe nicht wirklich teuer sind, aber man das ganze auch noch an und abschalten (von User-Land her) kann, wobei das natürlich egal ist, wenn die Zugriffe billig (also schnell) sind.

Um den Ring auszulesen könnte der billigste User-Land-Code einfach per memory-Device File Zugriff auf den Hauptspeicher bekommen und dann eben den Ring auslesen: Die Adresse ist ja leicht zu finden.

Abgesehen vom IDE Interface könnte man so ein "Zeit-Mess-Treiber" natürlich für viele Optimierungen in der Kernel-Welt gebrauchen, und im Prinzip langfristig auch in der einen oder anderen User-Land Applikation.

Bestimmt komme ich in den nächsten Tagen am Abend mal dazu, sowas als Patch für den 2.4er Kernel zusammen zu stellen, den Code habe ich entweder schon oder liegt im Kopf fertig rum...

Die eigentliche Frage, wo man dann eigentlich messen will ist damit aber auch nicht beantwortet: Wenn ich wüsste, wo sich das Messen lohnt, könnte ich ja schon optimieren...

Ciao,

DboxBaer

PS:
1. Gibt es eine solche "API" in irgendeiner Art schon im Kernel?
2. Wenn nicht, brauchen wir ein Include File, mit der Deklaration der Funktion(en) sowie evtl. verschiedener Konstanten (für Funktions-Werte-Bereiche, also so für IDE, Avia, Filesystem etc.).
und die Trace-Funktion selbst gehört sinnvoll wohl auch in den Kernel:
Gibt es da irgendwelche Präferenzen?!

3. Und ganz wichtig: Ist es überhaupt noch sinnvoll wenn ich weiter mit newmake arbeite? :-) (Hint: Wenn nicht, wird es länger dauern...)

DBoxBaer hat geschrieben: 3. Und ganz wichtig: Ist es überhaupt noch sinnvoll wenn ich weiter mit newmake arbeite? (Hint: Wenn nicht, wird es länger dauern...)

Jepp, newmake läuft ganz prima, fran und flasher haben sich dem angenommen

. Die Frage umsteigen oder einfach nicht mehr updaten stellt sich demnach noch nicht...

Zu den anderen Fragen kann ich leider nicht weiterhelfen, da fehlt mir auch ein wenig die Zeit - eventuell kann ich aber mal meinen Hinweis weiter oben nachgehen.

Auf Anraten von Charles Darwin jun. verlege ich mich mal in diesen Thread, kommend von hier:
http://forum.tuxbox-cvs.sourceforge.net ... 2&start=75

Ich könnte wohl einen großen LA an das IDE-Interface anschließen, wenn's denn hilft.

Beitrag von **Liontamer** » Sonntag 14. Januar 2007, 12:11

@DboxBaer
Das erinnert mich sehr an alte zeiten *g*

Leider kann ich dir aber mit dem Analyzer nicht helfen, da ich weder ein Interface, noch die Motivation, noch die Zeit habe erneut sowas aufzubauen.

Nur weiter so, sollte irgendwann noch DMA laufen, werd ich meine dbox evtl. auch noch mit dem neuen Interface ausstatten

Beitrag von **DBoxBaer** » Sonntag 14. Januar 2007, 20:37

Liontamer hat geschrieben:@DboxBaer
Das erinnert mich sehr an alte zeiten *g*

Leider kann ich dir aber mit dem Analyzer nicht helfen, da ich weder ein Interface, noch die Motivation, noch die Zeit habe erneut sowas aufzubauen.

Nur weiter so, sollte irgendwann noch DMA laufen, werd ich meine dbox evtl. auch noch mit dem neuen Interface ausstatten ;)

Grins...

So ähnlich sah es bei mir zum Teil auch aus. Wenn es was konkretes zu analysieren gäbe, dann könnte ich das auch. In der Firma hats leider weder Kabel noch Sat, darum ist das Recording schwer zu messen. Notfalls kann ich mir die Geräte ausleihen und zu Hause verwenden.
Nur warum? Meine Vermutung ist ja, das es an anderen/verschiedenen Stellen klemmt.

Im Moment hänge ich nur an einer ganz anderen Stelle: Mein Linux auf dem Laptop will nicht mehr mit der 2. LAN Karte (Xircom PCMCIA) reden und meine Versuche mit einem debian in einer VMWare kamen soweit, das ich zwar alles compiled bekommen habe, nur wenn ich unter Windows Wireshark laufen lasse und gleichzeitig in der VMWare mit debian einen DHCP Server laufen lasse, klappt beides nicht mehr...
Und dann hing auch noch plötzlich mein Windows :-(
"So kann ich nicht arbeiten..." (tm)

Statt Hardware:

bringe jemand das "oprofile" Ding ins newmake CVS/irgendwie zum Compilen/zum Laufen.
Ich wollte mich um genau die letzten beiden Punkte eigentlich dieses Wochenende ein wenig kümmern aber wenn die notwendige Hardware nicht mehr tut... :-((((

So, und nun probiere ich wenigstens meine YADD wieder gebootet zu bekommen.

Ciao,
DboxBaer