ZitatGRUB: TIMEOUT=0
halte ich für keine wirklich gute Idee. Ich würde das wenigstens auf 2 Sekunden einstellen. Das erleichtert Einiges, falls es mal Probleme gibt und man manuell im Bootloader eingreifen muss.
ZitatGRUB: TIMEOUT=0
halte ich für keine wirklich gute Idee. Ich würde das wenigstens auf 2 Sekunden einstellen. Das erleichtert Einiges, falls es mal Probleme gibt und man manuell im Bootloader eingreifen muss.
halte ich für keine wirklich gute Idee. Ich würde das wenigstens auf 2 Sekunden einstellen. Das erleichtert Einiges, falls es mal Probleme gibt und man manuell im Bootloader eingreifen muss.
Ja das stimmt natürlich. Aber ich dachte halt: wenn schon denn schon
Und im Notfall kann man ja immer noch eine LiveCD benutzten ...
BananaJoe:
Vielen Dank für deinen Ratschlag. Gut finde ich es auch, dass andere User auf Risiken hinweisen.
Trekkie00:
Vielen Dank für die Verlinkung des Artikels, der sich ebenfalls -- wie BananaJoe's Hinweis -- auf SSD-Optimierung bezieht.
Diesen werde ich lesen und schauen, was ich davon in der Praxis umsetzen kann, ebenso werde ich mich mit TRIMM unter Suse auseinandersetzen.
@Beide:
Bootzeit 0 oder 2 Sekunden geht nicht, da ich gerne auch mein zweites Betriebssystem anwählen möchte.
@Uhelp:
ZitatUnd wer weiß, vielleicht wird Win hauptsächlich von der SSD geladen, openSUSE nicht.
Auch das zu prüfen, hat sich niemand die Mühe gemacht.
Geht das aus den von mir angegebenen Dateien nicht hervor? Mein Wissenstand leicht leider nicht für die Interpretation.
@Uhelp:
ZitatEgal: Wir machen das Auto besonders rot.
Und dann ist es schneller, als jedes andere rote Auto.
GRINSWo man aber wirklich gut schrauben kann UND auch tatsächlich etwas bewirkt, wäre halt doch das kernel-Tunen...
Ich sehe es etwas anders! Hat mir doch der User Kanonentux mit seinem Ratschlag eine Verkürzung der Bootzeiten auf beiden Systemen um 10 Sekunden ermöglicht. Es geht mir auch nicht um einen Vergleich zwischen dem einen Betriebssystem und dem anderen. Lediglich um etwaige Kniffe, wie dieser von Kanonentux, der einiges an Zeit spart. Und 10 Sekunden ist wirklich ein spürbarer Vorteil.
ZitatBringt das Kompilieren des Kernels wirklich so deutliche Geschwindigkeitsvorteile?
Ich denke dies ist ein Ratschlag, welcher durchaus zum Erfolg führen kann. Ob dies für mich als Anfänger in die Kategorie: "einfach und ungefährlich" gehört, vermute ich eher nicht--> würde dies hier aber nicht ohne einen Kumpel an meiner Seite (der dann auch wissen muss was er tut) durchführen wollen.
Trekkie00:
ZitatUm hier einen zuverlässigen Vergleich anstellen zu können, müsste man erst mal wissen, welche Optimierungen er unter Windows durchgeführt hat, so dass man beurteilen könnte, ob diese auf Linux übertragbar sind.
Wie gesagt, ein Vergleich ist für mich von keiner Relevanz. Wichtig ist (und dies ist derzeit der Fall) das alles stabil läuft. Klar, schaue ich dann mal ob etwas verbessert werden kann (wie z.B. die Bootzeit). Ob dabei Win7 oder Suse die Nase vor'n hat, ist mir aber schnurz --> Wobei es schön ist, wenn beides schnell da ist.
D_Dau
ZitatBezieht dein System die "Uhrzeit" per NTP während des Starts?
Dieses verzögert den Start jedenfalls bei mir doch merklich.
Nach wie vor, leidet mein Suse unter der kleinen Krankheit der abweichenden Uhrzeit. Ich habe verschiedene Möglichkeiten (welche hier im Forum besprochen sind) ausprobiert, jedoch stellt sich meine Uhrzeit kurze Zeit danach wieder um. Die Uhrzeit ist auf UTC gestellt; bedeutet dies, dass die Uhrzeit nicht per NTP bezogen wird?
@Uhelp:
ZitatDass Win schneller ist, zeigt, dass entweder die Voraussetzungen faslch sind, oder openSUSE irgendwo klemmt, weil es sich ein wenig mit Fehlern befasst.
Welches OS liegt denn wo auf der Platte?
( fdisk -l )
Hast du an meinen Dateianhängen und Informationen erkennen können, ob sich das Suse mit Fehlern befasst?
@tomfa-ng:
Bei dir von dir empfohlenen Software, welche ich installieren soll, zur Ermittlung weiterer Informationen, bestehen da Risiken bei der Ausführung, oder ist es eine "harmlose" Software?
Ich bedanke mich bei allen Diskussionsteilnehmern an der Vielzahl von Ratschlägen und Hilfestellungen.
Sehr würde mich ein kurzes Feedback über die Infos freuen, nach denen ich gefragt worden bin:
1x wo sich welche Laufwerke befinden:
Klick
1x dmesg und var log messages
Klick
Ist hier soweit alles ok?
den Artikel zu dem TRIM im ubuntuusers wiki finde ich ganz gut. Da wird auch erwähnt, dass TRIM per mountoption "discard" bei manchen SSDs probleme machen kann und man lieber fstrim nehemen sollte.
(Der rote Kasten bei "Trim per Online-discard)
http://wiki.ubuntuusers.de/SSD/TRIM
Das die Uhrzeit auf UTC gestellt ist bedeutet nicht automatisch das sie per NTP bezogen wird.
Du könntest mal prüfen ob der NTP Daemon / Service läuft.
Ich kann jetzt grad nicht gucken wie der in Suse heißt, da ich es zur
Zeit nicht installiert habe. Aber das wissen andere hier bestimmt.
Es sollten aber beide Betriebssysteme auf die gleiche Zeit (UTC bzw. localtime) eingestellt sein. Sonst kann es passieren, dass beim Wechsel zwischen den Systemen immer die Zeit verstellt wird.
Bei den meisten Linux Distributionen wird (in der standard Konfiguration) davon ausgegangen dass die Hardwareuhr des Rechners (die Uhrzeit die man im Bios einstellt) auf UTC steht. Bei Windows7 weiss ich es nicht, da ich seit XP kein Windows mehr benutzt habe. Bei XP war es jedenfalls Localtime. Wenn man bei Win7 UTC einstellen kann würde ich persönlich das empfehlen.
Das Problem wenn nicht beide Betriebsysteme auf die gleiche Zeit (UTC, localtime) eingestellt sind ist folgendes.
sagen wir mal die Hardwareuhr steht auf 15:00 (UTC) die aktulle Zeit hier in Deutschland ist dann also UTC+1 Stunde (bzw. zwei wegen Sommer/Winter) also sagen wir mal 16:00
Wenn das Betriebsystem nun auf UTC eingestellt ist und die Zeitzone auf Deutschland ist alles ok.
Ist es aber auf Locasltime eingestellt "denkt" es die Uhr geht eine Stunde nach und (WindowsXP zumindest) verstellt die (Hardware?)Uhr auf 16:00
Wird jetzt wieder Linux gestartet, was auf UTC steht, geht es davon aus dass die 16:00 UTC ist und rechnet noch eine Stunde (bei Zeitzone Deutschland/Berlin) drauf.
Hoffe das war jetzt so richtig erklärt und verständlich.
Also wichtig: Beide Betriebsysteme auf die gleiche Zeit (UTC oder localtime) einstellen.
Danke, aber ich weiss schon wie man das macht.
Mir war nur danach das für den Fragesteller nochmal etwas zu erklären, weil ich den Eindruck hatte da herrscht noch viel Unklarheit.
Hi BananaJoe,
gerade dein Hinweis, dass auf beiden Systemen eine Änderung vorgenommen werden muss, damit die Uhrzeit nicht ständig sich verändert hat zum Erfolg geführt:
Artikel 1 und
Artikel 2.
Nun kann ich sicher sein, die Uhrzeit nicht mehr über NTP zu beziehen (wenn ich es richtig verstanden habe)?
Kennt jemand die Modifikation des Befehles, damit dieser mir unter Suse nützt?
Zu dem eingeführten Off-Topic:
Wird durch dieses S.M.A.R.T (Siehe Screenshots) nicht der Trimbefehl automatisch ausgeführt?
Oder muss hier noch etwas konfigurieren?
Nach wie vor würde ich mich über ein Feedback zu den Daten freuen, um die ich gebeten worden bin:
(da hier wohl a= Fehler zu sehen sind, sofern welche vorliegen und b= Potential zur Verkürzung der Bootzeit zu sehen ist?
1x wo sich welche Laufwerke befinden:
Klick
1x dmesg und var log messages
Klick
Ist hier soweit alles ok?
@tomfa-ng:
Bei dir von dir empfohlenen Software, welche ich installieren soll, zur Ermittlung weiterer Informationen, bestehen da Risiken bei der Ausführung, oder ist es eine "harmlose" Software? Ich frage deswegen, da mir eine längere Bootzeit lieber ist-- als wegen der Verkürzung Risiken einzugehen. Danke im Voraus für eine Rückmeldung.
Vielen Dank!
@tomfa-ng:
Bei dir von dir empfohlenen Software, welche ich installieren soll, zur Ermittlung weiterer Informationen, bestehen da Risiken bei der Ausführung, oder ist es eine "harmlose" Software? Ich frage deswegen, da mir eine längere Bootzeit lieber ist-- als wegen der Verkürzung Risiken einzugehen. Danke im Voraus für eine Rückmeldung.
Diese ist ungefährlich, also harmlos und gibt nur Daten aus, welcher Dienst welche Zeit zum starten braucht, bzw. wie lang die gesamte Startzeit genau ist.
zypper if systemd-analyze
Loading repository data...
Reading installed packages...
Information for package systemd-analyze:
Repository: repo-oss
Name: systemd-analyze
Version: 44-10.1.1
Arch: x86_64
Vendor: openSUSE
Installed: No
Status: not installed
Installed Size: 9.9 KiB
Summary: Tool for processing systemd profiling information
Description:
'systemd-analyze blame' lists which systemd unit needed how much time to finish
initialization at boot.
'systemd-analyze plot' renders an SVG visualizing the parallel start of units
at boot.
Alles anzeigen
systemd-analyze blame
6454ms systemd-modules-load.service
5413ms systemd-vconsole-setup.service
3215ms NetworkManager.service
3162ms tlp.service
2100ms remount-rootfs.service
1326ms postfix.service
1136ms home.mount
1099ms cycle.service
1068ms avahi-daemon.service
1034ms localnet.service
965ms systemd-logind.service
864ms smpppd.service
625ms udev-root-symlink.service
623ms boot.mount
571ms fglrxrebuild.service
546ms systemd-remount-api-vfs.service
515ms quota.service
507ms systemd-tmpfiles-setup.service
378ms systemd-readahead-replay.service
369ms xdm.service
335ms syslog.service
307ms udev.service
276ms upower.service
255ms systemd-sysctl.service
244ms network-remotefs.service
223ms systemd-readahead-collect.service
206ms var-run.mount
201ms console-kit-log-system-start.service
199ms fbset.service
192ms cpufreq.service
168ms network.service
153ms brld.service
94ms bluez-coldplug.service
79ms sbl.service
77ms sshd.service
73ms udev-trigger.service
68ms var-lock.mount
67ms console-kit-daemon.service
65ms atieventsd.service
58ms systemd-user-sessions.service
57ms media.mount
51ms dev-hugepages.mount
45ms sys-kernel-security.mount
42ms rtkit-daemon.service
34ms dev-mqueue.mount
26ms rc-local.service
25ms acpid.service
17ms sys-kernel-debug.mount
Alles anzeigen
systemd-analyze plot > systemd-plot.svg
[Blockierte Grafik: http://s13.postimage.org/brp44fzkz/systemd_plot.jpg]
Den brld.service könnte ich, z.B., deaktivieren und hätte somit wieder 153ms (toll) beim Startvorgang gespart.
ZitatAlles anzeigenMal systemd-analyze installieren und ausführen, für Tatsachen.
Quellcode
1
systemd-analyze time
Quellcode
1
systemd-analyze blame
und Ausgabe als Bildchenübersicht:
Quellcode
1
systemd-analyze plot > systemd-analyse.svg
(alles als User ausgeführt).
Hallo tomfa-ng,
ich habe die Installation durchgeführt.
Folgende Ergebnisse habe ich erhalten:
Interpretiere ich richtig, dass das System angibt für das Booten 19,05 Sekunden zu benötigen?
(Umgerechnet)
Warum komme ich auf 25318ms wenn ich die Werte von systemd-analyze blame addiere, müsste ich nicht auf 19052ms (Ergebnis von systemd-analyze time Startup) kommen?
Woran liegt es, dass ich mit der Stopuhr (ab Powerknopf drücken, bis Browser geöffnet ist / Kaltstart) auf 58 bis 60 Sekunden komme? Woher kommt die 40 Sekunden Differenz?
systemd-analyze blame
3624ms media-PCSpiele.mount
2643ms media-Musik.mount
2492ms media-Hoerspiele.mount
2388ms network.service
2014ms console-kit-log-system-start.service
1952ms media-Verwaltung.mount
1850ms media-Benjamin.mount
1789ms media-Ariane.mount
1739ms media-Fotos.mount
1730ms media-Sonstiges.mount
1678ms media-Ins7.mount
1532ms fbset.service
1265ms media-InsLinux.mount
1079ms media-Ronja.mount
608ms avahi-daemon.service
565ms systemd-logind.service
536ms SuSEfirewall2_init.service
535ms media-Gemeinsam.mount
425ms quota.service
408ms systemd-tmpfiles-setup.service
401ms network-remotefs.service
395ms acpid.service
325ms media-Videos.mount
Alles anzeigen
Warum benötigen die angelegten Partitionen unterschiedlich lang im Bootvorgang? Geht es hier nach/um Größe und belegtem Speicherplatz? Das hieße, um so voller der neue PC wird, um so langsamer das Booten, selbst wenn die Partitionen auf einer zweiten Festplatte liegen, wie es jetzt bei mir der Fall ist?
320ms postfix.service
289ms systemd-vconsole-setup.service
208ms SuSEfirewall2_setup.service
178ms syslog.service
133ms systemd-modules-load.service
104ms cpufreq.service
99ms brld.service
67ms rc-local.service
61ms systemd-user-sessions.service
53ms udev-trigger.service
50ms systemd-readahead-collect.service
49ms bluez-coldplug.service
49ms xdm.service
48ms systemd-readahead-replay.service
48ms cycle.service
46ms systemd-sysctl.service
44ms systemd-remount-api-vfs.service
43ms var-lock.mount
41ms udev.service
40ms var-run.mount
38ms udisks2.service
36ms media.mount
35ms console-kit-daemon.service
31ms localnet.service
30ms sys-kernel-debug.mount
26ms remount-rootfs.service
26ms sshd.service
25ms dev-mqueue.mount
23ms udev-root-symlink.service
20ms sbl.service
19ms dev-hugepages.mount
17ms home.mount
16ms sys-kernel-security.mount
4ms upower.service
2ms rtkit-daemon.service
1ms sys-fs-fuse-connections.mount
Alles anzeigen
Wenn überhaupt, ist für mich - zur Optimierung - nur der "4 stellige Millisekunden-Bereich" von Interesse, da ich alles andere gar nicht "merken/spüren" würde.
Was sind diese beiden "Dienste"?
Würde ich mich dazu entschliessen, dass die Partition "PC-Spiele" für mich unter Linux uninteressant ist, da dort nur Windows-Spiele installiert sind, würde ich 3,62 Sekunden sparen? Ist dieser Schluss richtig, oder handelt es sich um einen Trugschluss?