View previous topic :: View next topic |
Author |
Message |
flammenflitzer Advocate
Joined: 25 Nov 2003 Posts: 3532 Location: Berlin
|
Posted: Fri Jul 31, 2020 9:30 am Post subject: [er]Interne SSD M.2 SATA - Sinnvoll für Gentoo? Erfahrungen? |
|
|
Hallo, macht es vom Gewinn an Geschwindigkeit Sinn, Gentoo auf einer internen SSD M.2 SATA zu installieren? Und wie sieht es mit der Haltbarkeit bei der Nutzung mit Gentoo aus, da durch die regelmäßigen Updates m.E. doch mehr auf der SSD geschrieben wird als beispielsweise unter Windows?
Last edited by flammenflitzer on Sun Aug 09, 2020 7:34 am; edited 1 time in total |
|
Back to top |
|
|
pietinger Moderator
Joined: 17 Oct 2006 Posts: 5118 Location: Bavaria
|
Posted: Fri Jul 31, 2020 10:03 am Post subject: Re: Interne SSD M.2 SATA - Sinnvoll für Gentoo? Erfahrungen? |
|
|
flammenflitzer wrote: | Hallo, macht es vom Gewinn an Geschwindigkeit Sinn, Gentoo auf einer internen SSD M.2 SATA zu installieren? |
JA !! Ich habe in meinem Notebook nur eine SSD; am Hauptrechner eine SSD und eine HD. Die HD dient nur als Datengrab für große Dateien (und als Sync für die SSD).
Die Bootzeiten machen einfach nur noch Spass Genauso toll ist es wenn Du auf etwas größeres klickst - wie z.B. libreoffice-calc - und es ist instant gestartet / offen.
flammenflitzer wrote: | Und wie sieht es mit der Haltbarkeit bei der Nutzung mit Gentoo aus, da durch die regelmäßigen Updates m.E. doch mehr auf der SSD geschrieben wird als beispielsweise unter Windows? |
Genau das hat mir (damals) auch Sorgen bereitet und ich habe deshalb die /usr/portage (war 2016 noch dort) als eigene partition auf die HD gelegt. Ich habe aber schon verschiedene Stimmen gehört die meinten, selbst ein täglicher "emerge --sync" würde der SSD nicht so zusetzen und sei kein Problem. Ich kann leider keine Erfahrungwerte geben, da meine älteste SSD erst 4 Jahre alt ist. Was auf alle Fälle empfehlenswert ist: Nimm mindestens 16 GB RAM damit Du alle compiles in tmpfs durchführen kannst. |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Fri Jul 31, 2020 10:05 am Post subject: |
|
|
Ich habe meine Maschinen vor etwas über einem Jahr von SATA SSDs auf M.2 NVMe SSDs umgestellt (Achtung: M.2 NVMe, nicht M.2 SATA. Von M.2 SATA halte ich nicht viel).
Gefühlt sind sie dadurch ein ganzes Stück schneller geworden. Man merkt es beim Booten und beim Starten von Programmen.
Wenn ich mit "smartctl" oder "nvme" auf die restliche Lebenszeit der NVMe SSDs schaue, steht dort: 100%. Geschrieben wurden bisher ein paar Hundert GB. Das ist nichts! Von der Schreiblast werden die NMVe SSDs also noch Jahrhunderte halten
Ich kompiliere ausschließlich im RAM.
Hier ist ein gute Seite mit vielen weiteren Informationen: https://www.pc-experience.de/hardwareuntermenupunkt/nvme-m-2-faqs-tipps-und-fakten.html?showall=1
Last edited by mike155 on Fri Aug 07, 2020 12:18 pm; edited 1 time in total |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Fri Jul 31, 2020 10:24 am Post subject: |
|
|
Nachdem ich meinen Post geschrieben habe, habe ich mich der aktuellen c't zugewendet. Dort gibt es einen Test von PCIe-SSDs, erstaunlicherweise mal wieder ohne Samsung. Ich verstehe nicht, warum die c't Samsung SSDs regelmäßig außen vor lässt. Das ist mehr jetzt mehrfach aufgefallen. Samsung ist Marktführer und ich mag Samsung SSDs sehr!
Jedenfalls scheint es bei SSDs ein neues, außerordentlich wichtiges Kriterium zu geben, das ich bisher noch gar nicht auf dem Schirm hatte:
Quote: | Der Trend zur steuerbaren Beleuchtung von PC-Komponenten macht auch vor SSDs nicht halt. In diesem Test ist wieder einmal eine SSD vertreten, die automatisch in verschiedenen Farben leuchtet. |
Okay, dann wird man sich in Zukunft neben Geschwindigkeit, Stromverbrauch und Haltbarkeit auch noch um die Beleuchtung kümmern müssen. |
|
Back to top |
|
|
l3u Advocate
Joined: 26 Jan 2005 Posts: 2610 Location: Konradsreuth (Germany)
|
Posted: Fri Jul 31, 2020 1:17 pm Post subject: |
|
|
Ich hab Ende letztes Jahr einen neuen Rechner gebaut, und eine 500-GB-NVMe-SSD und eine 500-GB-HD reingebaut (beide WD Black). Portage und sämtliche git-Repositorys liegen auf der HD, alles andere auf der SSD (teils via bind-mounts, teils per Symlinks). Bisher kann ich nicht klagen. Da RAM recht billig geworden ist, würde ich sogar mein Vorgehen empfehlen und 32 GB reinbauen. 10 davon nutze ich für ein tmpfs für's Kompilieren. Läuft alles recht schnell, wobei ich einen alten Intel Core sowieso mit vier Kernen gegen einen Ryzen 5 3600 getauscht habe. Also von daher kann ich nicht genau abgrenzen, wieviel vom Geschwindigkeitszuwachs auf das Konto der SSD geht (ich hab ja allein schon -j4 gegen -j12 getauscht, und im RAM bauen ist doch etwas flotter als auf einer HD ;-)
Für Langzeitberichte fehlt natürlich noch die Nutzungsdauer. Aber bisher läuft alles 1A.
Da mittlerweile ja scheinbar SSDs selbst in (Hochlast-)Servern verbaut werden, braucht man sich vielleicht über die begrenzten Schreibzyklen nicht mehr allzu viele Gedanken machen. Aber eine fachkundige Aussage kann ich dazu nicht treffen … |
|
Back to top |
|
|
ManfredB Veteran
Joined: 27 Dec 2007 Posts: 1740
|
Posted: Fri Jul 31, 2020 3:56 pm Post subject: |
|
|
Ich habe in meinem PC 2 SSDs und 2 HDDs.
SSD 1 mit Linux-Distributionen
SSD 2 mit /home-Paritionen für die Linux-Distributionen
Die HDDs sind für Daten - Downloads - Isos - MediaThek usw.
Da ich viele Gentoo-Installationen habe, ist es mit den SSDs wunderbar.
Code: |
System: Host: gamk_a6 Kernel: 5.7.10 x86_64 bits: 64 Desktop: KDE Plasma 5.19.4 Distro: Gentoo Base System release 2.7
Machine: Type: Desktop System: CSL- & KG product: A0000001 v: N/A serial: PCCSL2018038241
Mobo: ASUSTeK model: TUF B450-PLUS GAMING v: Rev X.0x serial: 180937167304657 UEFI: American Megatrends v: 0409
date: 08/24/2018
CPU: Topology: 6-Core model: AMD Ryzen 5 2600 bits: 64 type: MT MCP L2 cache: 3072 KiB
Speed: 1379 MHz min/max: 1550/3400 MHz Core speeds (MHz): 1: 1377 2: 1436 3: 1547 4: 1546 5: 1439 6: 1381 7: 1443
8: 1539 9: 1419 10: 1416 11: 1375 12: 1375
Graphics: Device-1: NVIDIA GP106 [GeForce GTX 1060 6GB] driver: nouveau v: kernel
Display: x11 server: X.org 1.20.8 driver: nouveau unloaded: modesetting resolution: <xdpyinfo missing>
OpenGL: renderer: NV136 v: 4.3 Mesa 20.1.4
Audio: Device-1: NVIDIA GP106 High Definition Audio driver: snd_hda_intel
Device-2: Advanced Micro Devices [AMD] Family 17h HD Audio driver: snd_hda_intel
Sound Server: ALSA v: k5.7.10
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: 40:b0:76:0b:96:a6
Drives: Local Storage: total: 8.87 TiB used: 1.03 TiB (11.6%)
ID-1: /dev/sda vendor: Samsung model: SSD 860 EVO 500GB size: 465.76 GiB
ID-2: /dev/sdb vendor: Seagate model: ST4000DM004-2CV104 size: 3.64 TiB
ID-3: /dev/sdc vendor: Crucial model: CT500MX500SSD1 size: 465.76 GiB
ID-4: /dev/sdd vendor: Seagate model: ST4000DM000-1F2168 size: 3.64 TiB
ID-5: /dev/sde type: USB model: TO Exter nal USB 3.0 size: 465.76 GiB
ID-6: /dev/sdf type: USB model: ATA FUJITSU MHZ2250B size: 232.89 GiB
Partition: ID-1: / size: 19.56 GiB used: 6.60 GiB (33.8%) fs: ext4 dev: /dev/sda6
ID-2: /home size: 19.56 GiB used: 2.67 GiB (13.6%) fs: ext4 dev: /dev/sde6
ID-3: swap-1 size: 14.77 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sdd1
Sensors: Missing: Required tool sensors not installed. Check --recommends
Info: Processes: 244 Uptime: 9m Memory: 15.62 GiB used: 849.2 MiB (5.3%) Shell: bash inxi: 3.0.38
|
Gruß
Manfred |
|
Back to top |
|
|
forrestfunk81 Guru
Joined: 07 Feb 2006 Posts: 567 Location: münchen.de
|
Posted: Fri Aug 07, 2020 11:26 am Post subject: |
|
|
Ich kann SSDs auch nur empfehlen. Meine erste habe ich um 2009/2010 rum gekauft und in der Zwischenzeit waren es wahrscheinlich ca 8 auf 5 unterschiedlichen Gentoo Installationen. Mindestens zwei SSDs liefen davon gut über 4 Jahre als Hauptdisk (privater Laptop und Router im 24/7 Betrieb). Der Router hat außerdem mangels genügend RAM mit /var/tmp/portage auf der SSD gebaut. Ausgetauscht wurden die SSDs nur, weil die verfügbare Speichergröße doch enorm zugenommen hat. Die letzten 3 SSDs waren ebenfalls NVMe und das gibt schon nochmal einen deutlichen Boost, wobei auch SATA SSDs spürbar schneller waren als HDs. Hersteller habe ich Samsung, OCZ und vielleicht auch eine Intel. Bin sehr zufrieden mit allen.
Anfangs war ich auch skeptisch wegen der Schreibzyklen, aber das hat sich als grundlos erwiesen. Smartctl schaue ich mir nur noch sehr selten mal an. Aktuell hier auf einem über 3 Jahre alten Gentoo Laptop mit Samsung SATA SSD in werktäglicher Benutzung:
Power_On_Hours: 7298 (entspricht 912 Arbeitstagen)
Wear_Leveling_Count: 89 %
Media_Wearout_Indicator: 88 %
Auf diesem Gerät wird nicht nur Gentoo kompiliert (das meiste im RAM), sondern auch Software Entwicklung betrieben, mit ebenfalls vielen Kompiliervorgängen täglich (nicht im RAM), Minikube, einige Docker Container, Application Server, Code Analyse Tools, diverse Datenbanken, Elasticsearch, automatisierte Test und was so dazu gehört. Kurz: es gibt wohl wenige Anwendungsszenarien, in welchen End User Systeme mehr Disk IO aushalten müssen. Dafür sind 88 % Wearout (also 12 % verbraucht) nach 3 Jahren ganz ok, denke ich.
[Edit]
Auf allen SSDs war/ist auch eine LUKS Festplattenverschlüsselung im Einsatz, auch für die root Partition. Davon wurde in Kombination mit SSD (zumindest früher immer) abgeraten. Aber soweit ich weiß, wurden auch dort einige Verbesserungen eingeführt und abgeraucht ist mir noch keine.
Aber wie immer gilt: es ist sinnvoll aktuelle Backups zu haben _________________ # cd /pub/
# more beer |
|
Back to top |
|
|
flammenflitzer Advocate
Joined: 25 Nov 2003 Posts: 3532 Location: Berlin
|
Posted: Sun Aug 09, 2020 7:34 am Post subject: |
|
|
Ich habe eine gekauft. Danke an alle. |
|
Back to top |
|
|
ManfredB Veteran
Joined: 27 Dec 2007 Posts: 1740
|
Posted: Sun Aug 09, 2020 7:42 am Post subject: |
|
|
Viel Freude mit der neuen SSD.
Gruß
Manfred |
|
Back to top |
|
|
musv Advocate
Joined: 01 Dec 2002 Posts: 3365 Location: de
|
Posted: Mon Aug 10, 2020 11:01 am Post subject: Re: Interne SSD M.2 SATA - Sinnvoll für Gentoo? Erfahrungen? |
|
|
pietinger wrote: | Nimm mindestens 16 GB RAM damit Du alle compiles in tmpfs durchführen kannst. |
Mach ich zwar auch, aber beim nächsten System werd ich das nochmal überdenken.
Der Grund dafür ist einfach, dass man ccache nicht mit tmpfs nutzen kann. Und bei einigen dicken Brocken (chromium, webkit) ist das tatsächlich hilfreich.
Mit den begrenzten Schreibzyklen hab ich keine Probleme. Ich hatte 2011 mal 3 OCZ, die mir allesamt abgeraucht sind. Seitdem hatte ich nie wieder Probleme mit Platten/SSDs jeglicher Art. Ich würde schon davon ausgehen, dass die Dinger mittlerweile einen den HDDs ebenbürtigen Reifegrad erreicht haben.
Genau wie Mike155 würde ich aber wohl eher auf NVMe anstatt SATA setzen. |
|
Back to top |
|
|
flammenflitzer Advocate
Joined: 25 Nov 2003 Posts: 3532 Location: Berlin
|
Posted: Mon Aug 10, 2020 12:52 pm Post subject: |
|
|
Ich habe 1TB Kingston NVMe SSD. Zur Probe habe ich auch kubuntu installiert. Da ist der Desktop nach wenigen Sekunden da. Gefühlt 4x so schnell wie mein Gentoo (mitPlasma/kde5), welches in etwa gleich auf liegt wie Windows10 (dort ist das schnelle Herunterfahren deaktiviert, sonst wäre Gentoo das langsamste System beim Start). |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Mon Aug 10, 2020 2:21 pm Post subject: |
|
|
Dann solltest Du Dich auf die Ursachenforschung begeben. Es kann ja nicht so stehenbleiben, dass Gentoo das langsamste System ist!
- Ich nehme an, dass Du sowohl unter Kubuntu, als auch unter Gentoo Systemd verwendest?
- Verwendest Du KDE/Plasma sowohl unter Kubuntu, als auch unter Gentoo?
- Welche Zeit gibt
Code: | dmesg | grep "crng init done" |
unter Gentoo und unter Kubuntu aus?
Du könntest mal schauen, nach wie viel Sekunden nach dem Start des Bootens X11 unter Kubuntu und unter Gentoo gestartet wird.
Wenn es unter Gentoo länger als unter Kubuntu dauert, gibt es ein Problem im Boot-Prozess. Dann könntest Du prüfen, ob es Fehlermeldungen gibt vom Kernel oder von Systemd, die das Booten verzögern.
Falls X11 auf Gentoo und Kubuntu nach der gleichen Zeit gestartet wird, liegt das Problem in X11 oder in KDE/Plasma. Auch da kann so einiges schief gehen, was zu Verzögerungen führen kann.
|
|
Back to top |
|
|
flammenflitzer Advocate
Joined: 25 Nov 2003 Posts: 3532 Location: Berlin
|
Posted: Thu Aug 13, 2020 1:19 pm Post subject: |
|
|
5.7.11-gentoo
systemd-analyze time Code: |
Startup finished in 22.992s (firmware) + 10.529s (loader) + 2.583s (kernel) + 4.459s (userspace) = 40.565s
graphical.target reached after 4.446s in userspace | dmesg | grep "crng init done" Code: | [ 3.600678] random: crng init done | systemd-analyze blame Code: |
2.300s dev-nvme0n1p7.device
1.899s systemd-remount-fs.service
765ms *******\x2d4.mount
622ms *******.mount
581ms *******.mount
558ms *******\x2d1.mount
552ms *******\x2d2.mount
546ms *******\x2d3.mount
544ms systemd-networkd.service
495ms systemd-resolved.service
487ms systemd-timesyncd.service
446ms systemd-logind.service
396ms upower.service
304ms systemd-journald.service
249ms systemd-modules-load.service
236ms *******.mount
227ms systemd-binfmt.service
224ms udisks2.service
202ms NetworkManager.service
201ms systemd-udevd.service
196ms systemd-udev-trigger.service
169ms colord.service
152ms systemd-userdbd.service
120ms user@1000.service
109ms dev-hugepages.mount
109ms dev-mqueue.mount
109ms sys-kernel-debug.mount
108ms sys-kernel-tracing.mount
108ms kmod-static-nodes.service
88ms systemd-fsck-root.service
84ms systemd-fsck@dev-disk-by\x2duuid-45f71e3f\x2d754a\x2d4368\x2d90ef\x2d3980ae2596dd.service
49ms systemd-journal-flush.service
42ms polkit.service
40ms home*******.mount
39ms sys-kernel-config.mount
31ms bluetooth.service
29ms tmp.mount
27ms systemd-sysctl.service
25ms dev-disk-by\x2dpartuuid-000388cb\x2d72b0\x2dc772\x2dc2ec\x2df71996110700.swap
20ms proc-sys-fs-binfmt_misc.mount
16ms sys-fs-fuse-connections.mount
15ms systemd-tmpfiles-setup.service
15ms systemd-rfkill.service
14ms user-runtime-dir@1000.service
11ms systemd-tmpfiles-setup-dev.service
10ms systemd-random-seed.service
9ms alsa-restore.service
8ms systemd-update-utmp.service
6ms wpa_supplicant.service
5ms systemd-update-utmp-runlevel.service
3ms systemd-user-sessions.service
2ms rtkit-daemon.service |
|
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Thu Aug 13, 2020 1:44 pm Post subject: |
|
|
@flammenflitzer: das sind schon mal sehr interessante Zahlen. Jetzt wären natürlich die Vergleichs-Zahlen unter Kubuntu interessant. Bis die vorliegen, können wir mit meinem System vergleichen - wobei ich ganz andere Hardware habe.
- Der Random Number Generator ist's nicht. Ich habe einen ähnlichen Wert:
Code: | [ 3.136962] random: crng init done |
Interessant ist die Ausgabe von "systemd-analyze time". Bei mir kommt:
Code: | # systemd-analyze time
Startup finished in 1.069s (kernel) + 4.692s (userspace) = 5.761s
graphical.target reached after 4.685s in userspace |
Bei Dir kommen da doch ganz erhebliche Werte (40 Sekunden statt 6 Sekunden) zusammen!
Für die beiden Top-Werte in Deiner Ausgabe von "systemd-analyze blame" habe ich andere Werte:
Code: | # systemd-analyze blame | egrep "(nvme|systemd-remount)"
352ms dev-nvme0n1p2.device
6ms systemd-remount-fs.service |
Das kann auf ein Problem hindeuten, kann aber auch Zufall oder harmlos sein - es ist sicherlich nicht die Haupt-Ursache für die Verzögerung bei Dir.
|
|
Back to top |
|
|
flammenflitzer Advocate
Joined: 25 Nov 2003 Posts: 3532 Location: Berlin
|
Posted: Thu Aug 13, 2020 1:51 pm Post subject: |
|
|
Folgende Fehlermeldungen habe ich Code: | 13.08.20 15:08 bluetoothd RFCOMM server failed for Message Notification: socket(STREAM, RFCOMM): Protocol not supported (93)
13.08.20 15:08 bluetoothd RFCOMM server failed for Message Access: socket(STREAM, RFCOMM): Protocol not supported (93)
13.08.20 15:08 bluetoothd RFCOMM server failed for Phone Book Access: socket(STREAM, RFCOMM): Protocol not supported (93)
13.08.20 15:08 bluetoothd RFCOMM server failed for Synchronization: socket(STREAM, RFCOMM): Protocol not supported (93)
13.08.20 15:08 bluetoothd RFCOMM server failed for File Transfer: socket(STREAM, RFCOMM): Protocol not supported (93)
13.08.20 15:08 bluetoothd RFCOMM server failed for Object Push: socket(STREAM, RFCOMM): Protocol not supported (93)
13.08.20 15:08 bluetoothd RFCOMM server failed for Headset Voice gateway: socket(STREAM, RFCOMM): Protocol not supported (93)
13.08.20 15:08 pulseaudio [pulseaudio] backend-ofono.c: Failed to register as a handsfree audio agent with ofono: org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono was not provided by any .service files
13.08.20 15:08 bluetoothd RFCOMM server failed for :1.36/Profile/HSPHSProfile/00001108-0000-1000-8000-00805f9b34fb: socket(STREAM, RFCOMM): Protocol not supported (93)
13.08.20 15:08 pulseaudio [pulseaudio] pid.c: Daemon already running.
13.08.20 15:08 /hp-systray hp-systray(qt5)[3527]: error: Unable to find hp-upgrade --notify on PATH.
13.08.20 15:08 pulseaudio [alsa-sink-ALCS1200A Analog] alsa-sink.c: ALSA weckte uns auf, um neue Daten auf das Gerät zu schreiben, doch es gab nichts zum Schreiben!
13.08.20 15:08 pulseaudio [alsa-sink-ALCS1200A Analog] alsa-sink.c: Dies ist höchstwahrscheinlich ein Fehler im ALSA-Treiber »snd_hda_intel«. Bitte melden Sie diesen Fehler den ALSA-Entwicklern.
13.08.20 15:08 pulseaudio [alsa-sink-ALCS1200A Analog] alsa-sink.c: Wir wurden durch das POLLOUT-Set geweckt, allerdings lieferte ein anschließender snd_pcm_avail() den Wert 0 oder einen anderen Wert < min_avail.
13.08.20 15:08 akonadi_control org.kde.pim.akonadicontrol: "D-Bus communication error 'org.freedesktop.DBus.Error.NoReply': 'Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.'"
13.08.20 15:08 akonadi_control org.kde.pim.akonadicontrol: "D-Bus communication error 'org.freedesktop.DBus.Error.NoReply': 'Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.'"
13.08.20 15:08 akonadi_control org.kde.pim.akonadicontrol: "D-Bus communication error 'org.freedesktop.DBus.Error.NoReply': 'Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.'"
13.08.20 15:08 akonadi_control org.kde.pim.akonadicontrol: "D-Bus communication error 'org.freedesktop.DBus.Error.NoReply': 'Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.'"
13.08.20 15:08 akonadi_control org.kde.pim.akonadicontrol: "D-Bus communication error 'org.freedesktop.DBus.Error.NoReply': 'Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.'" |
Code: | Startup finished in 22.992s (firmware) + 10.529s (loader) | Ich denke, das sind die rund 33 Sekunden, die dein System schneller ist. Damit kann ich nichts anfangen....
Der Rest 2.583s (kernel) + 4.459s (userspace) = 7,042 |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Thu Aug 13, 2020 3:52 pm Post subject: |
|
|
flammenflitzer wrote: | Code: | Startup finished in 22.992s (firmware) + 10.529s (loader) |
Ich denke, das sind die rund 33 Sekunden, die dein System schneller ist. Damit kann ich nichts anfangen....
Der Rest 2.583s (kernel) + 4.459s (userspace) = 7,042 |
Was heißt "damit kann ich nichts anfangen?". Das ist doch genau der Ort, an dem man ansetzen kann. Man kann Google fragen:
Code: | systemd analyze firmware loader |
Und schon findet man ein paar Artikel, in denen beschrieben wird, wie man die Zeiten für "firmware" und "loader" deutlich verringern kann.
Beispiele:
|
|
Back to top |
|
|
flammenflitzer Advocate
Joined: 25 Nov 2003 Posts: 3532 Location: Berlin
|
Posted: Thu Aug 13, 2020 4:41 pm Post subject: |
|
|
Den ersten und einige andere habe ich gelesen. So wie ich das verstehe soll ich die BIOS Einstellungen optimieren. Ist das richtig? Warum sollte ich die BIOS Einstellungen für Gentoo Boot optimieren, wenn es für Kubuntu nicht nötig ist. Oder habe ich da etwas falsch verstanden? |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Thu Aug 13, 2020 5:22 pm Post subject: |
|
|
Ja, BIOS Einstellungen alleine können es nicht sein, weil dann auch Kubuntu betroffen wäre. Aber der letzte Post im ersten Link sagt:
Also könnte es beispielsweise sein, dass die BIOS-Einstellung stimmt, aber der Bootloader-Workaround nur unter Kubuntu, aber nicht unter Gentoo konfiguriert ist.
Ich wünschte, ich könnte Dir genau sagen, was Du tun musst. Aber das kann ich nicht. Ich vermute, dass "22.992s (firmware) + 10.529s (loader)" die Stelle ist, an der man suchen muss. Ich würde mir ansehen, was unter Kubuntu anders ist - und versuchen, das auch auf das Gentoo System zu übernehmen. Schau Dir beispielsweise mal an, wie GRUB unter Kubuntu konfiguriert ist und mit welchen Command Line Argumenten der Kernel gestartet wird.
Wie bootest Du Dein System? Über BIOS? Oder über UEFI? Evtl. mit CSM? Falls Du unter UEFI bootest, könntest Du testweise mal CSM an oder abschalten oder auf BIOS umschalten. UEFI ist nicht ganz einfach und erfordert einige Einstellungen (auch in GRUB, im Kernel und im Betriebssystem), bis es sauber läuft. Es könnte sein, dass auf Deinem Gentoo System etwas noch nicht stimmt. |
|
Back to top |
|
|
flammenflitzer Advocate
Joined: 25 Nov 2003 Posts: 3532 Location: Berlin
|
Posted: Sat Aug 15, 2020 4:52 am Post subject: |
|
|
kubuntu:~$ systemd-analyze time Code: | Startup finished in 21.622s (firmware) + 5.109s (loader) + 3.599s (kernel) + 7.252s (userspace) = 37.584s
graphical.target reached after 7.245s in userspace | kubuntu:~$ systemd-analyze blame Code: | 6.239s NetworkManager-wait-online.service
903ms systemd-logind.service
860ms udisks2.service
781ms snapd.service
419ms dev-loop1.device
336ms dev-loop4.device
334ms dev-loop3.device
329ms dev-loop2.device
289ms dev-nvme0n1p5.device
245ms snap-snapd-8790.mount
245ms snap-core18-1885.mount
244ms snap-gtk\x2dcommon\x2dthemes-1506.mount
243ms snap-keepassxc-978.mount
242ms snap-snapd-8542.mount
196ms man-db.service
188ms fwupd.service
158ms accounts-daemon.service
149ms dev-loop0.device
140ms upower.service
140ms networkd-dispatcher.service
117ms user@1000.service
112ms bluetooth.service
109ms avahi-daemon.service
106ms boot-efi.mount
102ms NetworkManager.service
100ms polkit.service
86ms dev-nvme0n1p6.swap
83ms logrotate.service
75ms apport.service
75ms thermald.service
74ms systemd-journald.service
72ms wpa_supplicant.service
70ms systemd-resolved.service
60ms systemd-timesyncd.service
60ms grub-common.service
59ms dev-sde7.swap
58ms gpu-manager.service
57ms systemd-udev-trigger.service
57ms systemd-journal-flush.service
52ms ModemManager.service
42ms rsyslog.service
36ms secureboot-db.service
36ms grub-initrd-fallback.service
33ms systemd-udevd.service
32ms keyboard-setup.service
32ms packagekit.service
29ms e2scrub_reap.service
29ms systemd-rfkill.service
27ms apparmor.service
25ms pppd-dns.service
22ms systemd-fsck@dev-disk-by\x2duuid-04FE\x2d56A1.service
21ms snapd.seeded.service
18ms snapd.apparmor.service
13ms plymouth-start.service
13ms systemd-modules-load.service
12ms plymouth-read-write.service
11ms plymouth-quit.service
11ms systemd-tmpfiles-setup.service
11ms kerneloops.service
10ms systemd-sysusers.service
9ms systemd-random-seed.service
8ms modprobe@drm.service
7ms alsa-restore.service
6ms dev-hugepages.mount
6ms dev-mqueue.mount
6ms systemd-sysctl.service
5ms sys-kernel-debug.mount
5ms systemd-user-sessions.service
5ms setvtrgb.service
5ms user-runtime-dir@1000.service
5ms sys-kernel-tracing.mount
5ms systemd-update-utmp-runlevel.service
5ms systemd-remount-fs.service
4ms systemd-update-utmp.service
4ms systemd-tmpfiles-setup-dev.service
3ms kmod-static-nodes.service
2ms console-setup.service
2ms sddm.service
2ms rtkit-daemon.service
2ms sys-fs-fuse-connections.mount
1ms sys-kernel-config.mount
1ms ufw.service
1ms snapd.socket |
Ist nur gefühlt schneller. Allerdings erscheint bei gentoo nichtIch habe das Gefühl, das sddm unter Gentoo langsamer ist. |
|
Back to top |
|
|
flammenflitzer Advocate
Joined: 25 Nov 2003 Posts: 3532 Location: Berlin
|
Posted: Sat Aug 15, 2020 2:47 pm Post subject: |
|
|
Ich habe etwas am Kernel geändert:
systemd-analyze time Code: |
Startup finished in 19.194s (firmware) + 8.288s (loader) + 2.043s (kernel) + 4.526s (userspace) = 34.053s
graphical.target reached after 4.513s in userspace |
Schnelles booten war im BIOS schon aktiviert. Ich denke, ich mache da mal eine neue Diskussion zum Thema auf. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|