D945GSEJT diskless budget zu langsam für vdr-sxfe ???

  • Moin, Moin,


    dies ist mein erster Beitrag in diesem Forum. Ich lese allerdings schon lange mit. Also vielen Dank für die vielen Infos von der Community...


    Ich bin dabei, mal meine Hardware auf einen neuen Stand zu bringen. Hatte bisher irgend ein ASUS Mainboard mit Duron und 512MB Speicher mit ner FF-DVB-S Galaxy (mit einem dieser Extensionboards für Scart) in einem nicht so wahnsinnig kleidsamen Gehäuse (mit Styropor schallisoliert und großem Silverado Lüfter). Das Ganze läuft diskless über Giganetz an einem Server auf dem Dachboden (Raid 5 und diverse externe USB Platten zum Speichern und ca 1200 DVDs aufgenommen über die letzten Jahre). Da diese ganze Hardware 24x7 läuft und Strom kostet bin ich jetzt dabei, hiermal ein wenig aufzuräumen und, wo möglich, zu minimalisieren.


    Ich habe mir also jetzt so ein modernes Atom Board gekauft (D945GSEJT) und eine TT S-1401 Budgetcard. Das steckt jetzt in einem JCP M103 Gehäuse. Klein, schnuckelig und ohne Lüfter.


    Als Softwaregrundlage ist Debian sqeeze verbaut (Kernel 2.6.30 mit den notwendigsten Modulen) und VDR 1.6.x mit diversen Plugins. Kernel und xserver-xorg-video-intel-2.9.0 sind mit den Patches von Sparkie versehen um VGA2SCART realisieren zu können. xine-lib ist 1.1.17 (laut changelog) und ist auch mit dem entsprechenden Patch aus vga-sync-fields-0.2.0
    gepatched. xineliboutput habe ich in Version 1.0.4 und die heutige CVS Version getestet.


    Starten tue ich alles noch per Hand (ich bin noch beim einrichten und testen). Also


    Code
    X &
    runvdr (ist über die letzten Jahre gewachsen und passt)
    vdr-sxfe --video=auto xvdr://127.0.0.1 --syslog --tcp --fullscreen --verbose --post tvtime:method=use_vo_driver --aspect 16:9 --reconnect


    und nun fängt mein Problem an:
    Ich bekomme zwar ein relativ gutes Bild, was die skalierung und Qualität angeht aber es ist absolut nicht ruhig. Ich habe das Gefühl, das nur jeder zweite bis dritte frame wirklich bis zum Ferseher (Röhre Panasonic Acuity) durchkommt. Der Ton ist OK und hat keine Aussetzer und auch OSD und LIRC tun es relativ gut. Aber das Bild... Man bekommt Kopfschmerzen davon. Dazu kommt noch, das es alle zwei bis drei Sekunden im oberen Bereich mehr als im unteren, um ca 0.5-1cm nach links oder nach rechts springt und wieder zurückkommt. Ich habe schon alle externen nicht notwendige Geräte abgeschaltet, um nicht auf irgendwelche Störungen von außen reinzufallen.


    Wenn ich mir die CPU Last anschaue kann ich nur zwei Prozesse identifizieren, die wirklich oben hängen, das ist "X" und einer der vdr-sxfe threads, beide mit 30-45%. Damit ist die CPU oft bei 100% dicht (htop). Ich vermute mal, daß diese Prozesse wohl im Zusammenspiel ein Problem haben. Wenn ich vdr-sxfe abschalte (Esc) ist die Last sofort runter. Die VDR Prozesse sind alle ganz unten und zucken nur mal kurzzeitig in Richtung 5% und auch X11 zeigt den Mouscursor ruhig in der Mitte stehend bei wenigen % Last


    Außerdem bekomme ich im verbose Mode von vdr-sxfe relative häufig dropouts um die Ohren geschlagen:


    Als Anhang schicke ich mal meine xorg.conf und eine Xorg.0.log mit. Vieleicht hat ja irgend jemand eine Idee, mit was für Infos man diesen Zustand noch verbessern kann. Als Alternative bleibt natürlich, meine FF-Card weiter zu benutzen mit diesem Board, aber dann ist der Stromspar und Lüfterlos Gedanke schon mal ganz schön verwässert...


    Probiert habe ich schon alles mögliche und habe auch schon hunderte von Forenbeiträge gelesen. Auch Google gibt mir bald keine Antwort mehr (mein Suchbegriffskonto ist wahrscheinlich eh überzogen). Ich habe schon eine ähnliche Frage im easyVDR Board gestellt aber ich glaube, hier ist einfach mehr los (ohne Wertung).


    So, dies ist mal ein Anfang, wenn die Experten noch mehr Infos, Konfigurations beschreibungen, Logfiles oder ähnliches brauchen, um mal mit nachzudenken
    don't hesitate to ask....


    msv

  • Dabei fällt mir noch ein:
    kann es sein, daß in der Kette vdr -> vdr-sxfe -> X11 -> xorg-intel.. -> VGA-Hardware irgendwo filesystem für Pufferung oder Ähnliches benutzt wird und dann natürlich in meinem Fall zu einem Bottelneck werden kann wegen des reinen diskless-Betriebes und der dann notwendigen Netzwerkzugriffe? Kann ich hierfür irgendetwas auf eine Ramdisk auslagern? Ich habe einen 2GByte Riegel verbaut. Also Platz müßte dasein.


    Schönes Wochenende
    msv

  • Hier läuft das gleiche Board unter Squeeze 2.6.30.5, xserver-xorg-video-intel-2.9.0, VDR 1.6, xinelib-1.2 und xineliboutput-1.0.90-cvs. Gepatched mit diesem bzw. jenem Patch. Ausgabe läuft über ein selbstgebasteltes VGA2SCART-Kabel auf eine Röhre. Zum Starten und Beenden von X, VDR und seinen Plugins verwende ich das runvdr-extrem-Script. Der VDR läuft bei normalem TV- oder Filmkonsum mit ca. 40-60% Last. Das Bild ist absolut störungsfrei. Das OSD hab ich per HUD auf einen eigenen Screen verbannt.


    Bei Dir hört es sich an, als ob die FRC-Regelung gar nicht greift. Eventuell hast Du da beim Patchen und Kernelcompilen was vergessen? Übrigens geht nach meiner Erfahrung die FRC-Geschichte nur bis Kernel 2.6.30.5. Alles was danach kam hab ich wegen des KMS-Umbaus nicht mehr zum laufen gebracht.


    Gruß
    iNOB

    Dateien

    Einmal editiert, zuletzt von iNOB ()

  • Hallo iNOB,


    schön zu hören, daß es bei dir geht.
    Ich habe noch mal ein bischen rumgeforscht in meinem System. Also die Patches sind alle richtig drin. Keine rejects oder so. Aber ich habe noch was anderes rausgefunden.


    dear all,


    Wenn ich meinen Rechner neu starte (reboot), dann "X &" starte, VDR starte und dann vdr-sxfe starte habe ich ein fast perfektes Bild (CPUlast vdr-sxfe 30-40%, X fast nix). Wenn ich dann vdr-sxfe beende (Ctrl-C) und dann X kille (SIGTERM od SIGINT) und dann wieder neu starte und daraufhin dann vdr-sxfe wieder starte habe ich den alten effekt, CPUlast für X und vdr-sxfe zusammen fast am Anschlag. Ich hab mal die beiden Xorg.0.logs verglichen. Der einzige Signifikante Unterschied besteht beim Laden irgendwelcher Register. Ab dem zweiten Start werden nur noch diese 2 hier neu geladen. Beim ersten Start sind es ein Haufen mehr:


    Code
    (II) Module fb: vendor="X.Org Foundation"
            compiled for 1.6.5, module version = 1.0.0
            ABI class: X.Org ANSI C Emulation, version 0.4
    (II) intel(0): Comparing regs from server start up to After PreInit
    (WW) intel(0): Register 0x61110 (PORT_HOTPLUG_EN) changed from 0x00000000 to 0x00000020
    (WW) intel(0): Register 0x61114 (PORT_HOTPLUG_STAT) changed from 0x00000300 to 0x00000700
    (==) Depth 24 pixmap format is 32 bpp


    Da ich sonst keine Unterschiede feststellen kann, denke ich mal, daß hier im nur teilweisen Setzen der Register die Ursache der Mißkommunikation liegen könnte. Aber vielleicht liege ich da ja falsch und irgend jemand anderes weiß was dazu...


    Hat hier jemand eine Ahnung wie man noch X resetten kann, sodaß auch wirklich alle Intel register neu gesetzt werden ohne jedesmal einen Reboot zu machen?


    Schönen Wochenstart noch
    msv

  • Hi msv


    sehr merkwuerdige Effekte die du hier beschreibst.


    Zitat

    Wenn ich dann vdr-sxfe beende (Ctrl-C) und dann X kille (SIGTERM od SIGINT) und dann wieder neu starte und daraufhin dann vdr-sxfe wieder starte habe ich den alten effekt, CPUlast für X und vdr-sxfe zusammen fast am Anschlag.


    was passiert mit dem VDR eigentlich in der Zwischenzeit, laesst du den durchlaufen?


    Ich muss sagen ich verwende das separate 'vdr-sxfe' ueberhaupt nicht sondern ausschliesslich das lokale Frontend. Laesst sich das Problem hiermit auch reproduzieren? Relevante Teile meiner zugehoerigen setup.conf und config_xineliboutput im Anhang.


    - sparkie

  • Probier doch mal das runvdr-extrem Script, wie oben von mir empfohlen. Das startet und beendet alle relevanten Komponenten anstandslos.


    Gruß
    iNOB

  • Hallo Sparkie,


    Ich verwende den "remote" Start von vdr-sxfe um den VDR selber nicht zu gefährden durch abschmirende X-Prozesse im Fall von Aufnahmen oder ähnlichem. Er läuft dann eben auch weiter, wenn X mal abbricht oder abgebrochen werden muß. Ich weiß natürlich nicht was exact auf der Schnittstelle xineliboutput <-> X11 passiert wenn X abricht, VDR aber weiterläuft. Nur hier habe ich keinen Unterschied feststellen können. Wenn ich die gesamte Kette neu starte oder VDR laufen lasse kommt trotzdem der "Hänger" ab dem ersten Restart von X.


    Hallo iNOB,


    ich habe mir das extrem script mal angeschaut, aber bis auf daß X mit der -nolisten tcp option gestartet wird und alles ein bischen besser verpackt ist um universeller auf Plugins und ihre Optionen, u.s.w. reagieren zu können, ist die Funktionalität ähnlich meinem Script zum starten vom VDR. Bei mir ist eben das meiste "hart verdrahtet". Ich werde aber morgen abend nochmal die "-nolisten tcp" Option beim starten des Xservers testen, ob es irgendwelche Änderungen bringt. Eigentlich soll das Ding ja nur paranoide Sicherheitsfanatiker unterstützen, aber zu Haus bin ich der Chef ....


    Schönen Tag noch
    msv

  • Zitat

    Originally posted by msv
    Ich werde aber morgen abend nochmal die "-nolisten tcp" Option beim starten des Xservers testen, ob es irgendwelche Änderungen bringt. Eigentlich soll das Ding ja nur paranoide Sicherheitsfanatiker unterstützen


    das glaube ich nicht, dass das was aendert. Ich konnte dein Problem leider noch nicht reproduzieren. Bei mir hoert der Xserver dabei immer unter anderem auch auf Port 6000...


    da muss irgendwas anderes Verruecktes passieren auf deinem System. Ich starte den Xserver ueberigens immer mit '-retro -noreset' .


    - sparkie

  • Moin,


    also gestern Abend mal die Optionen beim X-start ausprobiert - gleiches Ergebnis. Dann mal mit xinit getestet und ich dachte ich habs gefunden. Aber hier hatte ich nach dem dritten restart das gleiche Problem mit der hohen CPU Last. Na, ich hatte gestern nicht so viel Zeit um Logs vergleichen zu können. Am Wochenende gehts weiter....


    msv

  • Hi,


    ich bins mal wieder...


    Also ich hab mein Problem mit der hohen Prozessorlast gelöst. Da das ganze ja nach einem Reboot ganz gut lief habe ich noch mal wieder verglichen was bei den verschiedenen Programstarts so in den verschiedenen Logs auftaucht. Dabei ist mir bei dmesg aufgefallen, daß drm nur beim ersten start von X auftauchte. Aha, also die Module. Ich hab dann mal nach dem killen von X das drm modul entfernt und neu X/vdr-sxfe neu gestartet. Shit, immer noch gleicher Efekt. Dann nach dem Stop von X das i915 modul rausgeschmissen und X/vdr-sxfe neu gestartet und ... BINGO!!! ... das wars!


    Beim starten des X-Servers ist ihm wohl eine saubere initialisierung des laufenden Modules i915 nicht gelungen. Na dem helfe ich jetzt also in meinem /etc/init.d/vdrrc nach mit rmmod.


    So das Bild ist soweit perfekt, es scheinen auch keine Frames verloren zu gehen. Was aber jetzt noch sehr störend ist, ist das unregelmäßige seitliche Zucken des Bildes, mal nach rechts, mal nach links. Es passiert so alle Sekunde mit kleinen Pausen hin und wieder. Das ist besonders deutlich im oberen Bereich. Als wenn hier immer mal ein paar Pixel pro Zeile zu- oder abgezählt werden mit zunehmender Zeilennummer dann weniger (irgendein Rundungsfehler???). Der offset ist vielleicht sujektiv 1 cm ganz oben. Echt störend. Wo kommt das her? Werden hier Frames auf der Platte, die bei mir ja nur über meinen Fileserver (nfs) angebunden ist, zwischengebunkert und kommen dann irgendwie nicht zur rechten Zeit ans laufen?



    gruß
    msv

  • Hallo Sparkie,


    ich bin ja immer noch auf der Suche nach einer Lösung für mein "Ruckelproblem". Es hört sich ähnlich an wie damals in diesem Thread: http://www.vdrportal.de/board/thread.php?threadid=78480&threadview=0&hilight=ruckeln&hilightuser=0&page=3


    habt ihr denn hier noch eine wirkliche Lösung gefunden?


    Ich habe übrigens nochmal mit den Modulen etwas experimentiert da ich gerne mal die Debug lines sehen wollte. Mir ist nicht so ganz klar was hier eigentlich passiert. Per default wir beim X start ja das Modul i915 geladen. Deine Patches gehen aber immer nur in die Sources für i830. Darum habe ich mal vor dem X start ein "modprobe -a i830" gemacht. Das läüft dann genauso, leider mit dem gleichen Ruckeln. Was mir aber bisher nicht gelungen ist, ist die Ausgabe der Debuglines. Ich bekomme immer nur die erste :

    Code
    16:36:57 |<- -20ms                               0                              +20ms ->|      R


    Es ist hier egal ob ich

    Code
    Option      "SF_Debug"                  "True"


    setze oder auskommentiere.


    Was mache ich falsch??????


    gruß
    msv

  • Hi Sparkie,


    na gut
    Option "SF_Debug" "True"
    funktioniert nicht. Es muß
    Option "SF_Debug" "1"
    oder so sein....


    Ich hab jetzt mal meine Xorg.0.log angehängt mit Debug. Sieht soweit ja ganz gut aus. Aber vom Gefühl her Zuckt mein Bild bei jedem Regelschritt in die Gegenrichtung. In der Anfangsphase des Einschwingens ist das Bild komplett ruhig. Das "zuckeln" startet erst, wenn dann geregelt wird und scheint immer dann zu kommen, wenn die Richtung gewechselt wird. Aber das kann auch meine subjective Wahrnehmenug sein wenn der TV zuckt und gleichzeitig die Zeile auf meinem Laptop (ssh auf VDR) auf den Knien weiterspringt.


    Vielleicht kannst du ja mit diesen Beobachtungen was anfangen...


    Gruß
    msv

  • Hallo msv


    Zitat

    Originally posted by msv
    na gut
    Option "SF_Debug" "True"
    funktioniert nicht. Es muß
    Option "SF_Debug" "1"
    oder so sein....


    du hast noch eine aeltere Vesion des Patches/der xorg.conf am Laufen. Die Syntax hat sich
    mit 0.2.0 geaendert. Ungerade Zahlen fuer SF_Debug geben jede Sekunde eine Debugzeile aus,
    gerade Zahlen nur dann wenn die vorgegebenen Werte ueberschritten werden. SF_Debug auf 1 zu setzen ist aber schon ok.


    Zitat

    Ich hab jetzt mal meine Xorg.0.log angehängt mit Debug. Sieht soweit ja ganz gut aus.


    richtig - ist optimal.


    Zitat

    Das "zuckeln" startet erst, wenn dann geregelt wird und scheint immer dann zu kommen, wenn die Richtung gewechselt wird. Aber das kann auch meine subjective Wahrnehmenug sein wenn der TV zuckt und gleichzeitig die Zeile auf meinem Laptop (ssh auf VDR) auf den Knien weiterspringt.


    das Problem, das hier inzwischen schon mehrfach geschildert wurde ist, dass offenbar modernere TVs zu grosse Zeitkonstanten fuer das Timing der Ablenkelektronik einsetzen. Das Problem konnte
    ich allerdings auf meinen TVs (sogar modernen LCDs) nur ansatzweise (bei Entwicklung des Patches) beobachten.
    Grosse Zeitkonstanten sind von Vorteil wenn die Signalquelle exakt arbeitetet (z.B. TV-Stationen). Da dann Aussetzer bedingt durch analoge Uebertragungsprobleme (atmosph. Stoerungen etc.) besser ueberbrueckt werden koennen.
    Ist aber von Nachteil wenn die Quelle kein absolut konstantes Timing hat. Wie z.B. alte VHS Rekorder mit Gleichlaufschwankungen oder unser variables Timing.
    Manche TVs haben hierfuer sogar noch eine Einstellmoeglichkeit im OSD vorgesehen mit der man die Quelle manuell festlegen kann. Abhaengig davon wird die Zeitkonstante dann entsprechend gewaehlt.


    Softwareseitig haben wir bereits alle Moeglichkeiten ausgeschoepft das Video-Timing moeglichst 'sanft' zu regeln.
    Der FRC Patch fuer die Radeons kann um Faktor 20 feinfuehliger regeln als der FRC Patch fuer Intel.
    Was uns hier natuerlich wenig nuetzt. :)
    Eine Verbesserung koennte bei Intel eine Hardwareloesung bieten, die hier:
    DVI/HDMI-Ausgänge für FF-Karten und T-Online S100
    schon mal angedacht wurde. Ich weiss nicht wieweit diese Projekt fortgeschritten ist. Bzw. ob man hier
    was 'abkupfern' koennte.


    - sparkie

  • Hallo Sparkie,


    danke für die Erklärung. Leider bedeutet das aber für mich, daß ich doch erstmal bei meiner FF Card bleibe und nebenbei mal weiter mit deiner Regelung experimentieren werde.


    Ich bin mir im Moment auch nicht ganz sicher, ob ich wirklich deinen letzten Patchstand benutze (Ich meine irgendwo mal ein Git gesehen zu haben). Wo liegt den dein wirklich letzter Entwicklungsstand mit den guten Ergebnissen gegen Debian Sqeeze. Ich muß das dann am Wochenende mal mir der von mir jetzt benutzten Version vergleichen. Vieleicht bin ich ja noch nicht bei der letzten nahezu aber noch nicht ganz perfekten Version angekommen.


    Wenn man so die diversen Threads hier durch geht findet man ja alle möglichen Versionen und ich habe die erste genommen, die ohne Hunks gegen meine intel source patchbar war. Die Datei hieß aber auch wieder nur xv-intel.patch.txt ohne Versionsnummer. In deinem repository unter http://lowbyte.de/vga-sync-fields finde ich anscheinend nur Versionen für Lenny. Und Juni 2009 ist ja nun auch schon ein halbes Jahr her. Solange gibts mein Board D945GSEJT ja fast erst.


    Das mit der Ablenkelektronik werde ich mir nochmal näher anschauen. Ich hab schließlich mal Radio und Fersehtechnik gelernt (Grundig Zauberspiegel und so, schon 40Jahre her), aber nachdem man dann Anfang der 70er auf den Ex und Hop Zug bei der Technik aufgesprungen ist bin ich dann abgespungen...


    Weiter gehts am Wochenende..


    msv

  • Hallo,
    mach das Styropor raus!
    Damit kann man nur Wärme dämmen, aber keinen Schall.

    Grüße, Dieter :)

  • Hallo Dieter,


    das ist zwar richtig wenn man die Styroporplatte einfach nur auf die Gehäuseteile klebt, aber hier handelte es sich um ein damal gehyptes Konzept des Gehäusebaus. Es sind geformte Styroporteile, die per entsprechender Aussparungen als Träger für die PC komponenten dienen. Dadurch sollen Vibrationen minimiert werden. Drumrum zur eigentlichen Abschirmung ist dan nur noch ein dünnes Blech aufgezogen. Man muß dabei natürlich auf einen guten Airflow achten. Mein Enermaxnetzteillüfter springt im Sommer dann auch schon ab 25Cels Raumtemperatur an und "nervt". Daher jetzt mein Lüfterloser Neubau....


    Gruß
    msv

  • Hallo,
    Styropor hat ganz miese Schalldämmeigenschaften.
    Ev. Hilft es bei Vibrationen, aber auch da gibt es viele bessere Möglichkeiten. Wenn man dann noch die Wärmedämmung betrachtet braucht man noch extra Lüfter um die Wärme abzuführen.
    Sicher kein gutes Konzept.

    Grüße, Dieter :)

  • hi,


    ich wollte dies nochmal zum Abschluß bringen. Also die Frage im Subject kann ich sicherlich mit "Nein" beantworten.


    Aber auch nach tagelangen Versuchen den Intel Mod für Xserver zu verändern "schneller, öfter, kleiner" oder auch genau umgekehrt habe ich das Zucken meines Bildes beim einsetzen der Regelung nicht in den Griff bekommen. Sparkie vermutete ja, daß es mit dem angeschlossenen TV im Zusammenhang steht. Gut, wenn dann mal ein neuer TV ansteht wirds wohl auch HDMI/DVI werden. Aber das kann noch ein bischen dauern. Mein Panasonic ist noch nicht so alt. Na noch hab ich ja die FF Galaxy Karte. Wenn sich mal was neues bei VGA2Scart tut kann ich ja immer noch umschalten und per SXFE versuchen. Vielleicht haben die Treiberleute ja nochmal einen guten Einfall dazu...


    Die Kombination Galaxy FF/RiserCard im M103 von JCP paßt allerdings nicht. Die Karte ist zu hoch und paßt daher in der Breite nicht mehr ins Gehäuse. Ich hab nun also meinen alten VDR komplett entkernt und nur noch das D945GSEJT MoBo, Galaxy FF (jetzt direkt im Board) + j2 Scartadapter, und ein zusätzliches Slotblech für die SATA Anschlüsse (Pseudo Esata) drin. Alles Lüfterlos. Selbst das Netzteil ist raus. Dadurch ist der Kamin durchs Gehäuse nach oben hin offen. Zu Sommer hin schau ich dann mal ob ich doch noch einen Lüfter reinbau. Als Netzteil habe ich das externe Netzteil vom JCP M103.


    So, nun ist das Wohnzimmer wieder aufgeräumt und Weihnachten kann kommen.


    Danke an alle Helfer
    msv

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!