Hibernation: dumme Idee oder machbar?

Wie lange braucht denn dein Notebook, um aus dem Hibernation Modus wieder aufzuwachen, bis es auf einen Mausklick auch reagiert? Meins deutlich über 40 Sekunden, was die Startzeit meines LinVDR-Systems ist......
Gruß
Dumpfbacke

Hi,

also, Hibernation unter Windows möchte ich nicht mehr missen. Auch meine Desktoprechner werden stets nur in den S4 schlafen gelegt. Die Startzeit unter Windows läßt sich damit deutlich beschleunigen.

Unter Linux sieht es nach meiner Erfahrung ein wenig anders aus. Ich habe das mit Suse 9.1 das letzte Mal probiert. Ergebnis: Hat genauso lange gedauert wie ein normaler Start und war sehr unzuverlässig. Ich fürchte, für den VDR bringt das keine Vorteile.

Aber vielleicht kann ja jemand noch über positive Erfahrungen berichten?

Viele Grüße,
Holger

Prinzipiell gibt es unter Linux zwei Möglichkeiten für Hibernation:

1.) Mit den ACPI-Schlafmodi, was allerdings nicht zufriedendstellend funktioniert und eigentlich gleich wieder vergessen werden kann.

2.) Mit swsusp (http://www.suspend2.net/), was den Vorteil hat, dass es komplett in Software funktioniert. D.h. jeder Rechner ob mit oder ohne ACPI kann in den Tiefschlaf geschickt werden. Hierbei wird der Inhalt des Arbeitsspeichers in die Swap-Partition geschrieben und beim booten des Kernels wieder eingelesen.
Allerdings bedarf es ein wenig einlesen in Dokumentation und das bauen eines neuen Kernels.

Also prinzipiell find ich die Idee ganz gut, aber ich seh da auch so manche Probleme.

Die Aufwachgeschwindigkeit hängt von der RAM-Größe ab: habe ich 512 MB, so muss er auch 512 MB von der Festplatte lesen. Beim Start des VDR muss er da nie im Leben so viel reinladen. Weiß nicht, ob VDR selber überhaupt mehr als 64 MB braucht (mein System läuft mit 128 MB RAM). Der andere Speicher wird er für Caching verwendet, welcher sich aber erst im Betrieb füllt. Also hätte man dadurch schon eine zusätzliche Verzögerung.

Ein anderes Problem ist die Firmware für die FF-DVB-Karte. Die ist ja nach dem Ausschalten des Stroms aus der Karte und müsste neu initialisiert werden. Und genau das passiert ja beim Booten. Also ein normaler Suspend-To-RAM (vielleicht noch mit ACPI) würde da nicht mehr reichen. Weiß noch, dass ich damals beim Betrieb unter Windows auch kein Standby oder ähnliches überlebt hab, wenn die TV-Software lief.

Also müsste man dann doch wieder wie ein bissl booten und unnötig viel Speicher von der Festplatte auslesen, so dass es meines Erachtens keinen Vorteil bringt. Ich persönlich hab so ca. 50 Sekunden mit ct-VDR. Manchmal hilft auch das einfach entrümpeln des Systems, indem man sich von unnötigen Diensten trennt. Wobei LinVDR und ct-VDR seit Version 3 da schon gut entrümpelt sind.

Manchmal sollte man auch einfach mal die lilo.conf anschauen. Denn bei ct-VDR steht da z.B. nach der Installation eine Wartezeit von 10 Sekunden drin. Diese verzögert den Start des VDR nur unnötig, da er ja da nix weiter macht.

Außerdem isses nunmal ein PC, wo das BIOS auch erstmal ein paar Sekunden frist, bis es überhaupt mit dem Bootvorgang von der Festplatte beginnt. Hängt also auch vom verwendeten Board ab.

Interessant ist http://www.vdr-wiki.de/wiki/index.php/VDR_Bootzeiten da haben die Leute schon das maximale aus ihren Komponenten rausgeholt, dass schafft kein Suspend-To-RAM!

Bye, gabe!

EDIT: Link korrigiert

Ich habe die Geschichte mit Suspend to Disk bisher auch nur auf meinem Notebook laufen. Wenn ich das Notebook (IBM T22, P3m-800 mit 256 MB, Debian Sarge mit Eigenbau-Kernel auf Basis von 2.6.8-10) von der Konsole aus schlafen schicken, gehen sowohl das "Runterfahren" als auch Wiederherstellen deutlich schneller als auf die herkömmliche Art und Weise.

Allerdings habe ich die Erfahrung gemacht, dass die Treiber der PCMCI-WLAN-Karte (Netgear WG511) ziemlich zickig sind. Mit laufender WLAN-Karte ist ein Suspend to Disk definitiv nicht möglich, ich muss entweder den PCcard-daemon vorher ausschalten oder die Karte am besten ganz entfernen.

Ich befürchte, dass sich die DVB-Treiber ähnlich zickig verhalten werden.

Hmmmh,

wirklich interessant:

VDR Bootzeiten,
aus VDR Wiki, der freien Wissensdatenbank

(Dieser Artikel enthält momentan keinen Text)

Uli

Zitat

VDR Bootzeiten,
aus VDR Wiki, der freien Wissensdatenbank

(Dieser Artikel enthält momentan keinen Text)

Mach mal das Komma hinter dem Link weg, dann hast Du die richtige Seite.

Zitat

gabe schrieb
Die Aufwachgeschwindigkeit hängt von der RAM-Größe ab: habe ich 512 MB, so muss er auch 512 MB von der Festplatte lesen. Beim Start des VDR muss er da nie im Leben so viel reinladen. Weiß nicht, ob VDR selber überhaupt mehr als 64 MB braucht (mein System läuft mit 128 MB RAM). Der andere Speicher wird er für Caching verwendet, welcher sich aber erst im Betrieb füllt. Also hätte man dadurch schon eine zusätzliche Verzögerung.

Meiner Erfahrung nach scheint Windows dem kompletten Speicherinhalt auf die Festplatte zu schreiben. Auf meinem Desktop-Rechner (P4-3000 mit 1024 MB RAM, 160er Samsungs mit 7.200rpm) ist Suspend to Disk ziemlich störend, da es beim Shutdown einfach nur elendig lange dauert. Beim Neustart sind Hibernation und normaler Boot-Vorgang ca. gleichschnell.

Bei meinem Notebook habe ich unter Linux den Eindruck, dass die Menge der geschriebenen Daten abhängig davon ist, was gerade auf der Kiste läuft (auffällig bei X/kein X).

Also LinVDR bootet bei mir mit optimierten Kernel in etwa 10Sekunden, der rest ist die Zeit die das BIOS braucht (11-12s)
Ich glaube nicht das man mit Hibernate da noch viel rausholen kann. (Bei CT VDR könnte es natürlich was bringen )

XD

Zitat

VDR Bootzeiten,
aus VDR Wiki, der freien Wissensdatenbank

wobei manche anscheinend ihre Traumwerte angegeben haben

Zitat

wobei manche anscheinend ihre Traumwerte angegeben haben

Ja, davon träume ich auch

Naja, egal. Habe ja schon beschrieben, dass man durch Suspend-To-RAM wohl mehr Probleme hat. Da muss man sich dann so tief mit Linux auseinandersetzen, dass man gleich einen optimal abgespeckten Kernel bauen kann.

Bye, gabe

Hi,

ob sich ein Suspend2Disk lohnt häng m.E. sehr stark davon ab,
1) wie eng oder weit der Einsatzbereich des Rechners ist (das bedeutet nämlich, dass viele Geräte und Module geladen werden müssen)
2) wie bereit man ist, den Bootprozess auf den Einsatzzweck zu optimieren, denn das bedeutet meistens einen Verlust an Flexibilität (Beispiel: Hotplug deaktivieren bringt etliche Sekunden, aber dann ne USB-Platte dranzuhängen is nich)
3) wie versiert man ist in der Manipulation und Optimierung des Boot Prozesses (Beispiel: einige Optimierung findet bereits an der Initrd statt und das ist sicher nicht trivial)

In meinem Fall basiert der VDR aus Gründen flexibler Nutzbarkeit auf einer full-blown Suse Linux Installation. Unter Version 8.2 war der Bootprozess noch in erträglichem Zeitrahmen von etwa 2min. Das hat sich nach einem Update auf 9.2 deutlich verschlechtert (~3min).

Da der ACPI Kram auf dem Epia nicht so ganz zuverlässig läuft, habe ich auf das Software Suspend 2 (erfordert einen Kernel Patch und Manipulation der initrd) und Hibernate zurückgegriffen (auch hier muss man übrigens die Initrd manipulieren). Ein bißchen Gefrickel gabs noch mit den USB-Treibern, die werden jetzt vorm Suspend entladen. Außerdem müssen dvb und vdr gestoppt werden, was sich recht komfortabel im Konfig von Hibernate einstellen lässt. Da man dort auch einen Reboot nach dem Suspend anordnen kann, eignet sich es sich auch im Zusammenhang mit Nvram.

Nachdem Hibernate passend konfiguriert war, reichte ein Austauschen von

shutdown -r now

im vdrshutdown Skript durch

echo "hibernate" | at now

Die Resumezeit (komplett mit Bios etc.) liegt jetzt bei ca 60 sec. Und damit bin ich schon sehr zufrieden.

Fazit:
* Software Suspend bringt bei komplexe Installationen Zeitvorteile
* Software Suspend2 erfordert zwar einiges Know-How bei der Installation, ist dann aber wesentlich flexibler zu konfigurieren als Swsusp.

--schmettow.

Hallo Schmettow,

ich habe am WE versucht mir einen TestVDR mit den Wuschfeatures aufzubauen. Also mit bootsplash und suspend2 (um zu testen was das ggf. an Zeit bringt). Dabei habe ich auch natürlich auch das init-Script in der initrd angepaßt. Aber egal wie ich es anstelle, wenn ich echo > /proc/suspend2/do_resume in die init einbaue, dann bekomme ich ne "kernel panic".

Leider habe ich sonst nichts in Zwischennetz gefunden. Muß ich vor dem echo überprüfen, ob das wirklich ein suspend-img ist? Ach ja, ich mach ein susppend in ein file.

Als Basis dient ne minimal FC4 + 2.6.14.4er vanilla- Kernel + bootsplash u. suspend2 patch.

V_R.

Hi,

Mann hast du ein Glück, dass ich hin und wieder mal in alte Threads reinschaue...
Ich habe selbst das ganze Wochenende mit der Absicht vergeigt, ein Update auf 2.6.14 inkl. Suspend2 zu machen - ohne Erfolg. Aber immerhin habe ich schon nach nem halben Tag gemerkt, dass sich die Schnittstelle klammheimlich in /proc/suspend2 suspend2 geändert hat :§$%.

Na denn: Viel Erfolg noch.
--schmettow

P.S. Mit dem komprimierenden Filewriter von Suspend2 kriegt der VDR seinen Hintern jetzt <30sec inkl. BIOS und Grub hoch. Ist doch sensationell, oder?

P.P.S. Dem Gefühl nach würde ich sagen, dass das aktuelle Hibernate nen Knall hat...

Hi schmettow,

wenn Du nicht geantwortet hättest, dann hätteste halt ne PM bekommen.

Zum Thema: Wo hängt es denn bei Dir genau? Vielleicht kommen wir ja zusammen weiter. Welche Version von suspend2 nutzt du genau?

<30sec. hört sich doch gut an.

V_R

Hi,

habs nochmal gestoppt <30 is gelogen. Es sind 35. Es hing an zwei Stellen: 1) hibernate (aktuelle stable) verweigerte sich mit dem Hinweis, dass Grub und Lilo nicht passend konfiguriert sind. Hab ich mit VerifyFiilewrter No unterdrückt. Aber der Kernel 2.6.14.3 machte einfach keine Anstalten, zu resumen.

Sorry, in diesem Jahr rühr ich das System nicht mehr an. Man sieht sich in diesem Thread mit Kernel 2.6.15 wieder, okay?

--schmettow.

Gerne, wenn ich was finde werde ich hier mal mich auslassen.

Schöne Weinachten und Guten Rutsch.

V_R

Hi,

swsuspend (nicht 2) laeuft auf meinem IBM Thinkpad mit 2.6.14.3 prima. Resume geht ziemlich flott.

Es ist uebrigens nicht so, dass swsuspend den GANZEN RAM-Inhalt liest und schreibt. Hier wird einfach die Swap-Funktion genutzt und alles rausgeswappt, was geht, ehe der kleine Rest (nicht so sehr viele MB) dann wirklich so rausgeschrieben wird.

Das ist auch der Grund, warum nach dem Resume z.B. das Umschalten zu einigen grossen Programmen recht lange dauern kann.

Windows macht das uebrigens aehnlich.

Viele Gruesse,

Jan