Οι "έξυπνοι/ες" linuxάδες/ούδες από το sudo τη βρίσκουν

[sotos21]

Είναι άδικο, εμένα μου τρώνε τα win για το efi και τον grub 10,6sec

Κώδικας: Επιλογή όλων

sotiris@ubuntu:~$ systemd-analyze
Startup finished in 7.564s (firmware) + 3.117s (loader) + 1.576s (kernel) + 10.674s (userspace) = 22.933s
sotiris@ubuntu:~

[fog]

Τελικά τα windows είναι "βαριά" ακόμη και στη "γειτονιά" να βρίσκονται

Αν δε βαριέσαι Σωτήρη δώσε την:

Κώδικας: Επιλογή όλων

systemd-analyze blame

και κάνε επικόλληση τα πάνω-πάνω που αργούν.

Άσχετο... Ο kernel μου γιατί αργεί τόσο; Αν είχα τους χρόνους σας στον kernel θα έπεφτα στα 3 sec

[sotos21]

Κώδικας: Επιλογή όλων

sotiris@ubuntu:~$ systemd-analyze blame
          7.270s NetworkManager-wait-online.service
          1.708s dev-disk-by\x2duuid-52fd2a00\x2dff2d\x2d4615\x2daae0\x2db325853
          1.683s systemd-udev-settle.service

Θα κοιτάξω στην άλλη εγκατάσταση του 15.04(είναι σε αναμονή για αναβάθμιση σε 15.10) που δεν έχω εγκατεστημένους τους κλειστούς για το ασύρματο και θα ξαναποστάρω.
Δεν ξέρω για τον kernel σου γιατί αργεί, μια επιστημονική εξήγηση είναι ότι δεν σε γουστάρει.

[fog]

Χμμ... αυτό υποψιαζόμουν και για τον kernel μου (γι αυτό θα τον αντικαταστήσω με τον πρώτο kernel που θα bootάρει στο 1,5 sec )και για την καθυστέρηση του userspace σου. Ας γλυτώσουμε λοιπόν 7 δευτερόλεπτα:

Κώδικας: Επιλογή όλων

sudo systemctl disable NetworkManager-wait-online.service

If you have services which fail if they are started before the network is up, you may use NetworkManager-wait-online.service in addition to NetworkManager.service. This is, however, rarely necessary because most networked daemons start up okay, even if the network has not been configured yet.

πηγή

[sotos21]

Με 4.1 kernel και την εντολή σου voila

Κώδικας: Επιλογή όλων

sotiris@ubuntu:~$ systemd-analyze
Startup finished in 1.591s (kernel) + 2.197s (userspace) = 3.789s
sotiris@ubuntu:~$

Εδώ όμως δεν υπάρχει η καθυστέρηση που αφορά τα 7.564s (firmware) + 3.117s (loader) ίσως επειδή αυτή η εγκατάσταση έχει τον grub, ίσως επειδή δεν έχει κάποιο κλειστό οδηγό(εκτός της cpu)

[fog]

Έτσι κι αλλιώς εκείνα τα μετράει ξεχωριστά. Στο userspace είχες 10 κάτι και απο αυτά τα 7 κάτι τα έτρωγε η αναμονή οπότε εκεί κάπου θα ήσουν. Το 1sec πάνω κάτω μπορεί νάναι οποιαδήποτε ψιλοδιαφορά, αφού είσαι στον ίδιο υπολογιστή αλλά διαφορετική εγκατάσταση.
Και στο "καλό" σύστημα πάντως θα σου κόψει άλλα 7 sec. Άσε που αν μετανιώσεις γιατί ζαλίζεσαι από την ταχύτητα, κάνεις το disable->enable στην εντολή και πας αργά και σταθερά

[fkol k4]

Ok. από ό,τι βλέπω το παλέψατε πολύ περισσότερο από εμένα.
Αν κάποιος πάντως θέλει (και μιας και σήμερα κυκλοφόρησε και ο 4.0.1 ως τελευταίος σταθερός πυρήνας Linux), μπορεί να δοκιμάσει από εδώ και τον τελευταίο δικό μου.
Οι αλλαγές που έχει:

• lzo compression mode (χρειάζεται lzop & liblzo2-2)
• Patches για BFQ I/O Scheduler ως default επιλογή
• Intel Xeon optimization
• 1000 Mhz Timer frequency
• Ενεργοποιημένο Btrfs support (όχι module)

Υπόψιν, ο πυρήνας δεν είναι φτιαγμένος για γρήγορο boot, εν έχω αφαιρέσει modules (σ' εμένα φορτώνει σε ~5 sec)

[fog]

Υπόψιν, ο πυρήνας δεν είναι φτιαγμένος για γρήγορο boot, εν έχω αφαιρέσει modules (σ' εμένα φορτώνει σε ~5 sec)

Κώδικας: Επιλογή όλων

22:20:44 ✔ fog@edge ~ $ systemd-analyze time
Startup finished in 3.306s (kernel) + 1.610s (userspace) = 4.916s
22:20:46 ✔ fog@edge ~ $ uname -r
4.0.1-main-bfq-lzo


Μια χαρά, συνέχισε να φτιάχνεις "αργούς" πυρήνες
Ευχαριστώ.

[the_eye]

Μια άσχετη ερώτηση, μπορεί να είναι ασυμπίεστος ;
Δεν νομίζω ότι τίθεται θέμα χωρητικότητας στους δίσκους !

General setup —-> Kernel compression mode —->lzo
Αυτό σημαίνει πως ο πυρήνας καταλαμβάνει λίγο περισσότερο χώρο στον δίσκο, αλλά φορτώνει πολύ ταχύτερα καθώς το decompression rate του lzo ειναι πολύ μεγαλύτερο.

[fkol k4]

Μια άσχετη ερώτηση, μπορεί να είναι ασυμπίεστος ;
Δεν νομίζω ότι τίθεται θέμα χωρητικότητας στους δίσκους !

Σε Arch Linux γίνεται αν βάλεις την επιλογή 'raw' αντί για οποιουδήποτε άλλου αλγόριθμου συμπίεσης.
Σε Ubuntu δεν το δοκίμασα γιατί δεν ήταν στις προεπιλογές που υπήρχαν στο αρχείο, αλλά υποθέτω πως μπορεί να δουλεύει και εκεί.

Βέβαια, το θέμα είναι πως αν κάποιος έχει σχετικά ικανό επεξεργαστή, στην πράξη ένα συμπιεσμένο αρχείο διαβάζεται γρηγορότερα από ένα ασυμπίεστο.
Αυτό συμβαίνει γιατί για μερικούς αλγόριθμους ο ρυθμός αποσυμπίεσης είναι απίστευτα μεγάλος.
Εδώ για παράδειγμα, φαίνεται ένας συγκριτικός πίνακας με τους ρυθμούς συμπίεσης/αποσυμπίεσης ανάλογα με τον αλγόριθμο.

Spoiler: show

Κώδικας: Επιλογή όλων

Name            Ratio  C.speed D.speed
                        MB/s    MB/s
LZ4 (r101)      2.084    422    1820
LZO 2.06        2.106    414     600
QuickLZ 1.5.1b6 2.237    373     420
Snappy 1.1.0    2.091    323    1070
LZF             2.077    270     570
zlib 1.2.8 -1   2.730     65     280
LZ4 HC (r101)   2.720     25    2080
zlib 1.2.8 -6   3.099     21     300

Αν υποθέσουμε λοιπόν πως έχουμε αποσυμπίεστα δεδομενα σε έναν δίσκο, τότε μπορούμε να διαβάσουμε δεδομένα με ρυθμό που καθορίζει ο δίσκος αυτός. Δηλαδή, ~100ΜΒ/sec για έναν HDD ή ~450ΜΒ/sec για έναν SSD.
Αν μπορούμε όμως αντί να διαβάσουμε απευθείας όλα τα δεδομένα, διαβάσουμε μόνο το συμπιεσμένο κομμάτι και ο επεξεργαστής μας είναι ικανός να αποσυμπιέζει τα δεδομένα real time, τότε μπορούμε να πετύχουμε πολύ υψηλότερες ταχύτητες.

Αν καταφέρει η ομάδα του Btrfs να ενσωματώσει την υποστήριξη LZ4 όπως υπολογίζει, αυτό θα δώσει μεγάλη προώθηση στις επιδόσεις.

EDIT:
Τώρα πρόσεξα πως εννοούσες τη ύθμιση για την μεταγλώττιση, ενώ εγώ σου απάντησα για το initramfs.
Όχι, δεν έχω δει τέτοια επιλογή, μπορείς όμως να χρησιμοποιήσεις LZ4 που έχει πολύ χαμηλό λόγο συμπίεσης και υπερβολικά γρήγορο ρυθμό αποσυμπίεσης