Wieviel Ram braucht der (Mann ) VDR ??

  • Hi Leute,


    ja ich weiss - suchen ist dein Freund (VDR-WIKI) - aber ich wollte mal wirklich wissen, wieviel RAM der VDR braucht bzw. ob mehr auch Vorteile hat.
    Meine VDRs haben derzeit 1Gb RAM - bringen 4Gb mehr an Nutzen??
    Oder was kann ich mit dem mehr an RAM sinnvolles tun??


    Also mal los mit euren Meinungen ;D


    Grüße
    Magicdragon67

  • Livebuffer in ne Ramdisk und was noch so temporär rumfliegt (epg, bilder) könnte die Performance etwas erhöhen.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Ich denke nicht, dass EPG-Daten in einer RAM-Disk viel bringen werden. Die EPG-Daten werden beim Start des VDR vollständig ins RAM geladen und nur bei Änderungen wird in größeren Abständen geschrieben. So hätte man die EPG-Daten dann doppelt im RAM.


    1GB RAM ist etwas knapp, aber solange es kein swapping gibt, braucht man auch nichts zu tun.

    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Gut, dann bringts beim EPG vielleicht nicht viel. Waren nur Beispiele, was man so mit mehr RAM anfangen kann.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • 1GB RAM ist etwas knapp


    Das stimmt allerdings bei yaVDR 0.5, wenn Streaming oder noch mehr ins Spiel kommen. Es ist dann nicht schwer knapp über 1 GB zu kommen. Ich habe mein System noch nicht über 2 GB hinaus gesehen. Andersrum formuliert, was kostet noch RAM!?


    Albert


  • Das stimmt allerdings bei yaVDR 0.5, wenn Streaming oder noch mehr ins Spiel kommen. Es ist dann nicht schwer knapp über 1 GB zu kommen. Ich habe mein System noch nicht über 2 GB hinaus gesehen. Andersrum formuliert, was kostet noch RAM!?


    Albert


    Kommt auf das Board an, DDR3 RAM ist günstig, hat man aber noch ein altes Board mit DDR RAM wirds über 1 GB teuer.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Kommt auf das Board an, DDR3 RAM ist günstig, hat man aber noch ein altes Board mit DDR RAM wirds über 1 GB teuer.


    Ist mir bekannt. Das war eine rhetorische Frage. Ich ging schon von DDR3 aus.


    Albert

  • Kommt natürlich auch noch darauf an ob es ein "reiner" vdr ist oder der rechner noch für weitere Dinge verwendet wird.
    Bei mir ist es so gesehen ein Homeserver der 24/7 läuft. Dort passiert dann noch einiges mehr als nur vdr. Zum Beispiel:
    Backup
    Streaming
    Radio
    Calibre Library
    Apache
    Exim
    etc.
    Es wird auch mal Firefox gestartet und Youtube Videos angeschaut.


    Achso und ich habe 4Gb verbaut und bin damit voll zufrieden. Ich denke 2Gb würden auch reichen aber 1Gb ist bei mir definitiv zu wenig. Für nur vdr aber denk ich ausreichend.


    Grüße
    Martin


  • Gut, dann bringts beim EPG vielleicht nicht viel. Waren nur Beispiele, was man so mit mehr RAM anfangen kann.


    Ist zwar off topic, aber da schon lange nicht mehr darüber diskutiert wurde... ;)


    Genau das Gegenteil mit den EPG-Daten zu machen würde erheblich was bringen. Was ich meine ist, die EPG-Daten eben nicht beim VDR-Start in das RAM zu laden, sondern sie in einer Datenbank auf der Platte zu lassen. Das würde den Start des VDRs erheblich beschleunigen. Das wurde durch Verlagerung der EPG-Daten auf eine SSD bereits von Anderen nachgewiesen. Es ist klar, dass es noch schneller geht, wenn man die Daten gar nicht erst vollständig lädt. Vor längerer Zeit habe ich bereits gezeigt, dass die Verzögerung, die der Datenbankzugriff auf die Festplatte für einzelne EPG-Datensätze mit sich bringt kaum der Rede wert ist. Und wann braucht man schon mal alle Datensätze gleichzeitig? Außerdem spart das RAM.


    Da KLS ja nach seiner Aussage kaum Plugins oder ähnliches einsetzt, nehme ich an, dass er nicht auf externe EPG-Quellen zurückgreift und deshalb sein epg.data-File deutlich kleiner ist als von denen die eine externe EPG-Quelle benutzen. Deshalb dürfte sich dieser Effekt bei ihm wohl kaum zeigen. Deshalb wird er da wohl auch weiterhin keinen Handlungsbedarf sehen.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Andersrum formuliert, was kostet noch RAM!?

    Als ich zuletzt gekuckt habe jedenfalls deutlich mehr als vor 'nem halben Jahr...


    [Blockierte Grafik: http://ein-eike.de/wordpress/wp-content/uploads/2013/04/RAM-Preisentwicklung.png]

  • Als ich zuletzt gekuckt habe jedenfalls deutlich mehr als vor 'nem halben Jahr...


    Interessante Entwicklung. Ich habe offensichtlich seit längerem keinen RAM mehr gekauft. Trotzdem hält sich der Preis noch im Grenzen, wie diese. Ist aber nur eine Meinung.


    Albert

  • Zitat


    gda:
    Ich denke nicht, dass EPG-Daten in einer RAM-Disk viel bringen werden. Die EPG-Daten werden beim Start des VDR vollständig ins RAM geladen und nur bei Änderungen wird in größeren Abständen geschrieben.


    Zitat


    gda:
    Das würde den Start des VDRs erheblich beschleunigen. Das wurde durch Verlagerung der EPG-Daten auf eine SSD bereits von Anderen nachgewiesen.


    Entscheide dich mal ;)
    Eine EPG-Datei mit externen Inhalten (tvm) hat bei mir so fuer 100 Kanaele eine Groesse von ~ 10 - 11 MB.
    Wenn ich diese "enorme" Groesse von Daten beim Start von Festplatte in eine Ramdisk kopiere , geschieht das in einen Bruchteil einer Sekunde.
    Also warum schreibst du , dass es nichts bringt , die EPG Daten in eine Ramdisk zu kopieren,
    waehrend das Einlesen von SSD den Start erheblich beschleunigt :S

  • Also meine hat mit tvm 45 MB.


    Gda hat doch geschrieben, dass die epg-Daten einmal gelesen und dann im Speicher gehalten werden, also wozu noch in eine Ramdisk.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Also wenn das Einlesen von einer SSD erheblich schneller vonstatten geht , dann sollte es von einer Ramdisk noch einen Tick
    schneller sein.
    Also :
    Entweder der Algorithmus wie die Daten (sequentiell ?) eingelesen werden ist langsam , dann macht es sehr wohl Sinn , die Daten in eine Ramdisk zu kopieren
    oder
    es ist so ziemlich egal ob von Festplatte oder SSD eingelesen wird. Auch bei deinen 45 MB geschieht das in Millisekunden.

  • Hallo,
    es muss doch aber erst mal in die Ram-Disk kommen.
    Eine SSD ist nicht-flüchtig...
    Ist fast wie den Swap in eine Ram-Disk zu legen :)

    Grüße, Dieter :)

  • Also wenn das Einlesen von einer SSD erheblich schneller vonstatten geht , dann sollte es von einer Ramdisk noch einen Tick
    schneller sein.
    Also :
    Entweder der Algorithmus wie die Daten (sequentiell ?) eingelesen werden ist langsam , dann macht es sehr wohl Sinn , die Daten in eine Ramdisk zu kopieren
    oder
    es ist so ziemlich egal ob von Festplatte oder SSD eingelesen wird. Auch bei deinen 45 MB geschieht das in Millisekunden.


    Es gab hier aber Messung die um den Faktor 1000 anders lagen. Was durchaus damit zusammen hängen kann, dass die Platte zu diesem Zeitpunkt während des Boots von zig Prozessen gleichzeitig gequält wird und die meiste Zeit damit zubringt den Kopf zu bewegen. Sieh dir mal einen Bootchart an was da so abgeht.
    Die EPG-Daten gar nicht erst zu laden kostet noch weniger Zeit! Und der Vorschlag die EPG-Daten von einer Ramdisk zu laden um den Start zu beschleunigen ist, sorry AlterSack36, bescheuert, denn das Kopieren von der Platte in die Ramdisk um sie dann dem VDR vorzuwerfen, dauert länger als wenn der VDR die Daten gleich von der Platte liest.


    Aber ich hätte es besser wissen müssen. Hier ist keine Diskussion über solche Themen möglich.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Zitat

    Aber ich hätte es besser wissen müssen. Hier ist keine Diskussion über solche Themen möglich.


    Ja klar , bisserl kindisch jetzt.


    Ich behauptet einfach mal , es sollte voellig egal sein ~50 MB nun von SSD oder FP einzulesen.
    Einen "fuehlbaren" "erheblichen" Geschwindigkeitszuwachs sollte es da nicht geben.
    Wenn doch , sehe ich da doch eher Handlungsbedarf bei Systemoptimierung.


    Ich nehme lieber die paar Miliselkunden beim Start in Kauf um nen Filestream (~50 MB) in den Buffer zu lesen als jedesmal
    beim Oeffnen des Menues in der Datenbank rumzuwurschteln um die Daten OnDemand zu lesen.
    Wenn deine Festplatte so zerfranst ist , dass du beim Booten Schwierigkeiten hast , dann kann das auch nicht die Loesung sein.


    Btw. ich habe jahrelang Epg-Daten und zig andere Sachen in eine Ramdisk gelesen. ( allerdings zur Geraeuschdezimierung)
    Dank OpenRC und parallelem Booten hat die Pladde auch ordentlich geroedelt aber da gab es nie Probleme.
    Ausserdem ist die Idee soweit mit Datenbank eh Asche , bevor man nicht drueber nachgedacht hat , was mit
    den ganzen Plugins/etc ist , welche auf die EPG Daten zugreifen.


    Kannst ja selber sehen :



    2,5 " FP

    Code
    stefan@server:/tmp$ ls -lh epg.data
    -rw-r--r-- 1 stefan users 57M Jun 18 00:49 epg.data


    einmal Einlesen im normalen Betrieb:

    Code
    stefan@server:/tmp$ time ./readfile2ram epg.data
    Time required for execution: 0 seconds.
    
    
    
    
    real    0m0.006s
    user    0m0.000s
    sys     0m0.004s


    und einmal FP unter voller Last (simuliert mit hdparm):

    Code
    stefan@server:/tmp$ time ./readfile2ram  epg.data
    Time required for execution: 0 seconds.
    
    
    
    
    real    0m0.006s
    user    0m0.004s
    sys     0m0.004s
  • Wowowowo leute haltet mal den Ball flach.


    ich wollte hier keine neue Grundsatzdiskussion lostreten.
    Es ging mir einfach nur drum zu erfahren, ob 1GB Ram ( das hab ich jetzt ) oder 4GB - und ob die einen Vorteil bringen - Preis ist im Moment Nebensache - ich hab die Riegen schon da liegen - war n Fehlkauf .


    Also wenn ichs mal zusammenfasse - machen die 4 GB im VDR durchaus Sinn - vor Allem im Hinblick auf mögliche Erweiterungen in Zukunft.


    Danke mal, ich weiss nun was ich wissen wollte - so nun könnt Ihr meinen Thred weiter Karpern :D


    Grüße und Danke


    Magicdragon67


  • irgendwie kann ich mir schwer vorstellen, dass das auch unter "Last" kaum weniger lang braucht als die Zugriffszeit einer guten 2,5" Platte und eine theoretische Leserate fast einem GB/s liefern soll - es sei denn da spielt massiv Caching mit rein...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich behauptet einfach mal , es sollte voellig egal sein ~50 MB nun von SSD oder FP einzulesen.


    One, zumindest beim XBMC Start unter yaVDR 0.5 macht es schon bei Deiner Größenordnung einen enormen unterschied.


    Also wenn ichs mal zusammenfasse - machen die 4 GB im VDR durchaus Sinn - vor Allem im Hinblick auf mögliche Erweiterungen in Zukunft.


    Korrekt.


    Albert

Jetzt mitmachen!

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