xen und vdr: wenn andere Prozesse laufen, kleine Probleme beim vdr

  • Hiho,


    bin so gesehen noch im Aufbau: also zur Zeit läuft mein vdr in einer domu "satana". Wenn ich nun mit manchen Prozessen auf eine HDD zugreife, zickt vdr ein bißchen. Wenn ich vdrconvert zum Beispiel starte oder auch mit samba Dateien kopiere, werden Aufzeichnungen ruckelig wieder gegeben. Außerdem reagiert lirc dann nicht mehr sofort. Im Log sehe ich dann:

    Code
    Oct 24 13:07:57 satana kernel: lirc_serial: ignoring spike: 1 1 471f278d 471f278d 84080 82a8c


    vdr reagiert aber noch: über die FB bei vdradmin kann ich fröhlich hin und herschalten.
    Ausgelastet finde ich die domu zu den Zeitpunkten dann nicht. vdrconvert braucht teilweise 50% CPU-Last, aber da vdr ja nicht soviel braucht, sollte ihn das doch nciht so stören, oder ?


    ich habe auf der dom0 xen-hypervisor 3.0.3-0-2, in der domu nutze ich xen-3.1. Meine "Festplattenordnung" ist noch etwas konfus... vdr nutzt einige hdds mittels lvm und andere hab ich über "xm block-attach" durchgereicht. Aber die Ruckler gab es auch schon, als vdr "nur" über die HDDs mit lvm lief. Von daher schließe ich meine Mixtur da eigenlich aus.


    Bzgl. der Ruckler sehe ich da zur Zeit zwei Möglichkeiten:
    1. hab mal gelesen, dass xen etwas langsamer mit den hdds arbeitet. Zur Zeit ist das video0-Verzeichnis auf der selben physikalischen HDD wie auch die root-Partition von der domu und auch dom0. Daher hoffe ich, dass ich das Problem etwas beheben kann, wenn ich /video0 auf eine andere, eigene physikalische HDD verschiebe.
    2. Falls das doch nciht hilft, vermute ich fast, dass das doch am Chipsatz liegt. Wie in der Sig zu erkenne, nutze ich ein Epox-Board. Der via-Chipsatz soll da zwar schon wesentlich besser mit Mutlitasting umgehen können, aber vielleicht reicht das ja doch noch nciht... Sprich: vielleicht sollte man da doch auf intel- oder nvidia Chipsatz setzten ?


    Bzgl. des Lirc-Problems bin ich etwas ratlos. In der Dom0 hab ich in der menu.lst "xencons=tty" ( so hat das meine ich bei brumm-bär auch geklappt). Ansonsten geb ich dann die io-Daten über die Xen-cfg datei mit. Von daher sollte da ja alles laufen...
    Könnte eventluell auch am Chipsatz liegen, fänd ich halt nur doof... Falls sonst keiner noch Ideen dazu hat, wollte ich den ir-empfänger der ff mittels remote-plugin ausprobieren.


    Hat vielleicht sonst jemand Erfahrung damit gesammelt ? Wäre auch dankbar, über Kernel- und Xen-infos, wenn ihr keine Ruckler habt.

    THX
    Kamikaze

    ***********************

    Hauptvdr: Easyvdr 3.5

    Clients: Easyvdr 3.5

    Einmal editiert, zuletzt von Kamikaze ()

  • Zitat

    ...
    Bzgl. der Ruckler sehe ich da zur Zeit zwei Möglichkeiten:
    1. hab mal gelesen, dass xen etwas langsamer mit den hdds arbeitet. Zur Zeit ist das video0-Verzeichnis auf der selben physikalischen HDD wie auch die root-Partition von der domu und auch dom0. Daher hoffe ich, dass ich das Problem etwas beheben kann, wenn ich /video0 auf eine andere, eigene physikalische HDD verschiebe.
    ...


    Denke übrigens nicht mehr, dass das an der HDD liegen könnte... Die Probleme treten auch auf, wenn ich über DVD-Switch ein Image abspiele, und die Images liegen auf einer anderen physikalischen HDD... Also: bin über jeden Erfahrungsbericht dankbar !


    THX
    Kamikaze

    ***********************

    Hauptvdr: Easyvdr 3.5

    Clients: Easyvdr 3.5

    Einmal editiert, zuletzt von Kamikaze ()

  • Hiho,


    auch auf die Gefahr hin, dass das Thema anscheinend keinen außer mir interessiert / oder keiner außer mir damit Probleme hat. Habe die Probleme mit dem Ruckeln bei vdr-Aufnahmen weiter eingegrenzt:


    Zitat

    vdrconvert braucht teilweise 50% CPU-Last, aber da vdr ja nicht soviel braucht, sollte ihn das doch nciht so stören, oder ?


    Als ich die CPU-Auslastung oben erwähnte, sprach von der cpu-Auslastung in der domu. Wenn ich mir parallel dazu die CPU-Auslastung per "xm top" in der Dom0 ansehen, dann muss ich leider feststellen, dass die domu satana, wo mein vdr läuft, 99% CPU Auslastung hat, wenn solche Prozesse wie vdradmin oder vdrconvert laufen...
    Testweise habe mal ein Board mit Intel-Chipsatz eingebaut, allerdings war der Prozi nicht so leistungsstark (irgendwas mit 1,irgendwas an GHz). Die Auslastung war zwar auch so da, aber es ruckelte nicht so stark, wie bei dem via-Chipsatz. Falls jemand Hardware-Empfehlung oder Tipps hat, wie ich CPU-Auslastung drücken kann, wäre ich dankbar, wenn ihr die kurz posten könntet.


    THX Kamikaze

    ***********************

    Hauptvdr: Easyvdr 3.5

    Clients: Easyvdr 3.5

  • Um es vorsichtig zu formulieren: Via hat(te) kein glückliches Händchen beim Design seines PCI-Bus-Interfaces.
    Such' mal im Internet nach "Soundblaster VIA". Deshalb wird von ernstzunehmenden OSsen der Bus eingebremst.


    Das Ruckeln bekomme ich auch ohne Xen hin. Deshalb läuft bei mir vdrconvert auf einem anderen physikalischen System.


    Und zu bedenken ist, dass Xen eben kein Echtzeitsystem ist. Der Standardkernel im übrigen auch nicht.


    uwe

    server: yavdr trusty testing, 2 * L5420, 32GB, 64TB RAID6 an OctopusNet (DVBS2- 8 ) + minisatip@dsi400 (DVBS2- 4 )
    frontends: kodi und xine

  • Zitat

    Um es vorsichtig zu formulieren: Via hat(te) kein glückliches Händchen beim Design seines PCI-Bus-Interfaces.
    Such' mal im Internet nach "Soundblaster VIA". Deshalb wird von ernstzunehmenden OSsen der Bus eingebremst.


    mh... dachte mir schon so etwas. Wusse ja, dass via nicht der beste ist, aber ich dachte, dass die sich doch etwas mehr verbessert hätten. Hätte mir dann nur mit dem Intel-Chipsatz mehr Erfolg gewünscht (also nicht nur weniger Ruckler sondern gar keine)... Beim vorherigem System war auch ein Via-Chipsatz und da gab es auch keine Ruckler mit vdrconvert, allerdings auch ohne xen... Mist, doofe Entscheidung: neue HW? doch auf xen verzichten? Noch irgendwelche Tipps ? Vielleicht eine andere Xen-Version oder andere Kernel ?


    CU
    Kamikaze

    ***********************

    Hauptvdr: Easyvdr 3.5

    Clients: Easyvdr 3.5

  • hi!


    hab den intel G33 chipsatz. bisher ist mir aufgefallen dass die fb auf dem xen system mit dem remote-plugin recht träge reagiert. leider habe ich den xen-server noch nicht ausgiebig getestet. im prinzip funktioniert er zwar, aber ich bin mit der dom0 noch nicht glücklich. ich mochte diese gegen ein 64bittiges ubuntu mit xen 3.1 tauschen. auf morgen werd ich mir aber einmal eine aufnahme machen und dann weiter berichten.


    liebe grüße,
    nety

    • server: ctvdr7

    • client: ctvdr61; Etch - 2.6.18-5; e-tobi - VDR 1.4.7; P3 0,5Ghz; Nexus-S-2.2

    • client: 2x; ctvdr61; Etch - 2.6.18-5; e-tobi - VDR 1.4.7; P3 0,5Ghz; DXR3

    • client: smt7020; MLD 2.0

  • Hiho,


    hab auch noch neue Erkenntnisse dazu gewonnen: ich hatte noch vdradmin-am-3.4.6 am Laufen, da ich die autotimer behalten wollte... Wusste und merkte natürlich auch, dass vdradmin-am-3.4.6 lange beim ersten mal Laden der Seite brauchte, aber damit konnte ich ja leben. Heute Morgen habe ich dann vdradmin-am-3.6.0 und epgsearch installiert und siehe da: die Ruckler sind etwas weniger geworden ! die CPU-Auslastung auf der domu ist zwar noch 60-70% und auf der dom0 auch, aber es ist besser als vorher. Dann habe ich testweise das System noch mal auf ein M2N 1394 aufgebaut - also mit nem nforce-Chipsatz et voilà: nix Ruckler. CPU-Auslastung bei vderconvert von der domu bei 10-30 % und auf dom0 bei 30-40 %. Daher habe ich mich jetzt entschlossen, ein neues Mainboard zu holen. Habe mich für das Gigabyte Board M61P-S3 entschieden, da es serielle Schnittstelle, 4 PCI Steckplätze, GraKa on board und nforce-Chipsatz hat. Das Board wurde hier im Portal zwar schon angesprochen, aber ich habe keine "Berichte" gefunden. Sobald ich das dann live hab, werde ich berichten.
    Nety: freue mich schon auf deine Tests. Hast Du die Kerne vom Prozi eigentlich verteilt ?
    [EDIT]
    Fand lirc vorher auch recht träge. Und wenn halt andere Prozesse liefen, verweigert lirc auch gerne den Dienst. Seit dem Wechsel auf vdradminam-3.6.0 hat sich das aber gebessert ! Mal sehen, ob ich lirc auch unter dem neuen Board so zum Laufen bekomme - hab's jetzt in die domu verbannt. Beim nforce-Chipsatz könnte es damit aber zu Problemen kommen, eventuell muss ich den dann doch auf der dom0 lassen... Mal sehen.


    CU
    Kamikaze

    ***********************

    Hauptvdr: Easyvdr 3.5

    Clients: Easyvdr 3.5

    Einmal editiert, zuletzt von Kamikaze ()

  • Hiho,


    ok, mir fiel noch was ein (Schande, dass mir das nicht früher eingefallen ist...): ich hatte anfangs öfter den Fehler, dass die HDDs auf mal nicht mehr reagierten. Im Log fand ich dann folgenden Fehler:

    Code
    hda lost interrupt


    Den Fehler konnte ich erst beseitigen, indem ich beim booten noch die Optionen "ide=nodma" und "noirqdebug" mitgegeben hab. Da ich ja noch Xen-3.0 hatte, hab ich eben auf Xen 3.1.0-1-i386-pae umgestellt et voilà: die Option "ide=nodma" brauche ich nicht mehr. Die CPU-Auslastung bei vdrconvert sind dann zwar immer noch recht hoch, aber beim Abspielen der Aufzeichnungen hab ich keine Ruckler mehr ! (Schade,... hab mich schon fast auf die neue HW gefreut... So spart es dann den Geldbeutel...)


    Der Vollständigkeit halber noch mal meine folgenden Probleme, falls wer ähnliches erlebt: Ich kann jetzt den seriellen Port jetzt nicht mehr an die DomU übergeben. Beim Starten kam immer der Fehler

    Code
    TypeError: function takes exactly 3 arguments (2 given)

    und soweit ich gelesen habe, gibt es für xen 3.1.0.1-i386-pae noch keine Lösung dafür. Daher hab ich lirc nun in der dom0 und starte in der domu den Client.
    Lirc ignoriert so auch teilweise meine FB, wenn vdrconvert läuft, aber gut. Vielleicht hilft da ja doch ncoh das remote-plugin ?!
    Nety: hast du auf deiner Kiste eigentlich auch vdrconvert ?


    CU
    Kamikaze

    ***********************

    Hauptvdr: Easyvdr 3.5

    Clients: Easyvdr 3.5

  • hi!


    vdrconvert habe ich noch nicht installiert. momentan schlage ich mich gerade mit meinen clients herum. beim fernsehbetrieb musste ich feststellen dass mein nfs server der in einer eigene domu liegt auch gelegentlich einbricht und die übertragungsraten für eine flüssige widergabe nicht mehr ausreichen. auch die performance von samba lässt sehr zu wünschen übrig. übertrage ich daten jedoch über ssh bekomme ich akzeptable datenraten von 10Mbyte/s. das streaming von der vdr server domu auf die clients funktioniert jedoch anstandslos.
    brauchbare infos gibts in kürze. hab nur ziemlich viel zu tun :/.


    liebe grüße,
    NEty

    • server: ctvdr7

    • client: ctvdr61; Etch - 2.6.18-5; e-tobi - VDR 1.4.7; P3 0,5Ghz; Nexus-S-2.2

    • client: 2x; ctvdr61; Etch - 2.6.18-5; e-tobi - VDR 1.4.7; P3 0,5Ghz; DXR3

    • client: smt7020; MLD 2.0

  • Hi Nety,


    hatte auch Probleme, wenn ich mit Samba darauf zugegriffen hab. Aber seitdem ich (endlich)die HDD wieder mit dma am Laufen habe, klappt datt bisher anstandslos.


    CU
    Kamikaze

    ***********************

    Hauptvdr: Easyvdr 3.5

    Clients: Easyvdr 3.5

  • hi!


    hab meine dom0 auf das aktuelle ubuntu-server 7.10 amd64 upgedated. mit dem debian installer konnte ich es auf das virtual volume installieren, auch wenn es nicht mit anhieb klappte. ich musste 2 mal den installer starten bis das lgv richtig erkannt wurde. auch das installieren von xen unter der 64bit server version von ubuntu gestaltet sich nicht so einfach wie bei allen anderen versionen, da es kein gesammtes xen paket gibt. man muss sich also alle teile zusammensuchen. meine domU's und die meisten configs habe ich dann einfach von meiner ctsrv2 installation übernommen und bin somit schnell zu einem sehr guten ergebnis gekommen. die performance unter der neuen domu ist schlichtweg atemberaubend. meine 32bit domU's laufen ohne probleme auf dem 64 bit system. einfach genial.
    auf meine fileserver domU habe ich übers gbit nezwerk schon 40MB/s erreicht. somit sind diese um ein vielfaches gestiegen.
    die fernbedienung der nexus in der vdr domu fühlt sich immer noch etwas träge an.
    aufnahmen sind bis jetzt durchwegs ohne ruckler :).


    liebe grüße,
    nety

    • server: ctvdr7

    • client: ctvdr61; Etch - 2.6.18-5; e-tobi - VDR 1.4.7; P3 0,5Ghz; Nexus-S-2.2

    • client: 2x; ctvdr61; Etch - 2.6.18-5; e-tobi - VDR 1.4.7; P3 0,5Ghz; DXR3

    • client: smt7020; MLD 2.0

  • Hey Nety,


    denke mal, du sprichst von dem Xen-System in der deiner sig. Konntest/Könntest/Kannst die Kerne eigentlich auch auf domus verteilen ?


    CU
    Kamikaze

    ***********************

    Hauptvdr: Easyvdr 3.5

    Clients: Easyvdr 3.5

  • hi!


    hab ich noch nicht probiert und mich auch nicht schlau gemacht wie oder ob das funktioniert. ich möchte jetzt aber noch ein paar rechenintensive domus hinzufügen, dann wäre das natürlich interessant.


    grüße,
    nety

    • server: ctvdr7

    • client: ctvdr61; Etch - 2.6.18-5; e-tobi - VDR 1.4.7; P3 0,5Ghz; Nexus-S-2.2

    • client: 2x; ctvdr61; Etch - 2.6.18-5; e-tobi - VDR 1.4.7; P3 0,5Ghz; DXR3

    • client: smt7020; MLD 2.0

  • Hallo,


    diese LIRC-Meldung habe ich auch ohne XEN und bei niedriger CPU-Last. Ich verwende LIRCCVS (da 2.6.23 Kernel) .. habe schon langsam den Verdacht, daß es daher kommt. (Bei 2.6.22. mit LIRC 8.2 hatte ich das Problem noch nicht).


    Hast Du schon eine Lösung dafür gefunden?

    Pentium Quad 8400s, 4 GB RAM, ASUS P5Q-E, 2x Mystique Dual (V2 und V3), 15 TB RAID, yaVDR 0.5a (VDR 2.x)

  • Hey,


    geantwortet hatte ich ja auch schon hier. Hab aber auch lirc aus dem cvs genutzt. Kernel war bei mir ja 2.6.18 unter xen.


    CU
    Kamikaze

    ***********************

    Hauptvdr: Easyvdr 3.5

    Clients: Easyvdr 3.5

Jetzt mitmachen!

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