I replaced the sd card with a sandisk A1 64gb.
givesRandom writes are 774 times faster, random reads are ~5x faster. Inspecting givesTasks that previously took 20sec are taking 2sec.
But reboots still take 8 minutes. I've found it's not actually the boot that's slow, but the shutdown. I've tried "sudo shutdown now" and nothing happens for minutes. Furthermore, the clock sync is off by about 3mins when it comes back from a "sudo reboot now", which can be seen in the syslog. So it's taking ~3mins to get to a point in shutdown where it stops updating the clock, and then it takes another ~3mins to just start the booting the linux kernel, after which it realizes it's behind by 3mins and corrects this to jump to the actual time. I've further confirmed this theory by sending an email with the rpi timestamp in it before the timesync occurs, and it's off by ~3minutes.
So my pi takes 8 minutes between "sudo shutdown now" and booting the linux kernel? Maybe it's a network issue keeping it from shutting down, or a power issue? It has an ethernet connection and is wired to a 12v battery via voltage regulator. Or maybe I just copied a corrupted filesystem over to a new sd card?
Code:
sh /usr/share/agnostics/sdtest.shCode:
Run 1prepare-file;0;0;33283;65seq-write;0;0;34656;67rand-4k-write;0;0;3098;774rand-4k-read;13347;3336;0;0Sequential write speed 34656 KB/sec (target 10000) - PASSRandom write speed 774 IOPS (target 500) - PASSRandom read speed 3336 IOPS (target 1500) - PASSCode:
systemd-analyze blameCode:
2.464s e2scrub_reap.service2.164s dev-mmcblk0p2.device1.747s rpi-eeprom-update.service1.578s raspi-config.service1.473s udisks2.service1.282s rc-local.service1.107s systemd-timesyncd.service1.069s ModemManager.service1.019s cups.service 745ms ssh.service 742ms rng-tools-debian.service 712ms systemd-udev-trigger.service 698ms avahi-daemon.service 651ms gldriver-test.service 641ms glamor-test.service 630ms polkit.service 612ms keyboard-setup.service 546ms networking.service 537ms systemd-journal-flush.service 518ms lightdm.service 505ms dphys-swapfile.service 498ms systemd-udevd.service 498ms systemd-logind.service 472ms pulseaudio-enable-autospawn.service 450ms wpa_supplicant.service 420ms user@1000.service 412ms systemd-fsck@dev-disk-by\x2dpartuuid-e9c8be79\x2d01.service 411ms dhcpcd.service 381ms rsyslog.service 379ms systemd-journald.service 347ms systemd-rfkill.service 332ms systemd-fsck-root.service 329ms console-setup.service 293ms alsa-restore.service 256ms modprobe@drm.service 204ms packagekit.service 185ms gpsdctl@ttyACM0.service 184ms systemd-tmpfiles-setup.service 184ms systemd-remount-fs.service 180ms gpsdctl@ttyACM1.service 150ms systemd-modules-load.service 143ms run-rpc_pipefs.mount 138ms sys-kernel-debug.mount 136ms triggerhappy.service 134ms dev-mqueue.mount 133ms sys-kernel-tracing.mount 130ms fake-hwclock.service 125ms kmod-static-nodes.service 123ms modprobe@configfs.service 121ms modprobe@fuse.service 121ms systemd-random-seed.service 96ms systemd-user-sessions.service 89ms plymouth-read-write.service 83ms boot.mount 82ms systemd-update-utmp.service 81ms systemd-tmpfiles-setup-dev.service 79ms systemd-tmpfiles-clean.service 75ms nfs-config.service 75ms systemd-sysusers.service 74ms sys-kernel-config.mount 68ms plymouth-start.service 67ms systemd-sysctl.service 58ms sys-fs-fuse-connections.mount 45ms wd_keepalive.service 28ms user-runtime-dir@1000.service 22ms systemd-update-utmp-runlevel.service 19ms ifupdown-pre.service 3ms plymouth-quit-wait.serviceBut reboots still take 8 minutes. I've found it's not actually the boot that's slow, but the shutdown. I've tried "sudo shutdown now" and nothing happens for minutes. Furthermore, the clock sync is off by about 3mins when it comes back from a "sudo reboot now", which can be seen in the syslog. So it's taking ~3mins to get to a point in shutdown where it stops updating the clock, and then it takes another ~3mins to just start the booting the linux kernel, after which it realizes it's behind by 3mins and corrects this to jump to the actual time. I've further confirmed this theory by sending an email with the rpi timestamp in it before the timesync occurs, and it's off by ~3minutes.
So my pi takes 8 minutes between "sudo shutdown now" and booting the linux kernel? Maybe it's a network issue keeping it from shutting down, or a power issue? It has an ethernet connection and is wired to a 12v battery via voltage regulator. Or maybe I just copied a corrupted filesystem over to a new sd card?
Statistics: Posted by mgrocketman — Sun Mar 31, 2024 7:29 am