Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 09, 2023 04:38AM |
Registered: 5 years ago Posts: 119 |
tme@nr104:~$ sudo /etc/init.d/ntp stop && sudo date -s "$(ssh stora date -R)" && date -R && sleep 60 && hostname; date -R && ssh stora 'hostname;date -R' Stopping NTP server: ntpd. Mon Jan 9 10:53:48 CET 2023 Mon, 09 Jan 2023 10:53:48 +0100 nr104 Mon, 09 Jan 2023 10:54:48 +0100 stora Mon, 09 Jan 2023 10:54:55 +0100
tme@nr104:~$ sudo /etc/init.d/ntp stop && sudo date -s "$(ssh stora date -R)" && date -R && sleep 60 && hostname; date -R && ssh stora 'hostname;date -R' Stopping NTP server: ntpd. Mon Jan 9 10:55:05 CET 2023 Mon, 09 Jan 2023 10:55:05 +0100 nr104 Mon, 09 Jan 2023 10:56:05 +0100 stora Mon, 09 Jan 2023 10:56:11 +0100
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 09, 2023 03:09PM |
Admin Registered: 12 years ago Posts: 17,127 |
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 10, 2023 01:16AM |
Registered: 5 years ago Posts: 119 |
tme@rn102:~$ sudo crontab -l | tail -2 [sudo] password for tme: 0 * * * * /root/rearm-wakealarm * * * * * /sbin/hwclock -s tme@rn102:~$ ssh root@router 'hostname; date -R' && hostname; date -R router Tue, 10 Jan 2023 08:05:33 +0100 rn102 Tue, 10 Jan 2023 08:05:30 +0100
tme@rn102:~$ ssh root@router 'hostname; date -R' && hostname; date -R router Tue, 10 Jan 2023 08:05:53 +0100 rn102 Tue, 10 Jan 2023 08:05:48 +0100
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 10, 2023 02:18PM |
Registered: 5 years ago Posts: 119 |
tme@nr102:~$ sudo date -s "$(ssh root@router date -R)" root@router's password: Tue, 10 Jan 2023 09:08:28 +0100
tme@nr102:~$ ssh root@router 'hostname; date -R' && hostname; date -R root@router's password: router Tue, 10 Jan 2023 21:04:04 +0100 nr102 Tue, 10 Jan 2023 20:04:04 +0100
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 10, 2023 03:31PM |
Admin Registered: 12 years ago Posts: 17,127 |
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 13, 2023 12:10PM |
Registered: 5 years ago Posts: 119 |
[ 0.000000] Switching to timer-based delay loop, resolution 53ns [ 0.000001] sched_clock: 32 bits at 19MHz, resolution 53ns, wraps every 114537122277ns [ 0.007872] clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 101938038664 ns [ 0.019438] Console: colour dummy device 80x30 [ 0.024168] Calibrating delay loop (skipped), value calculated using timer frequency.. 37.49 BogoMIPS (lpj=187492)Do you see something interresting here?
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 13, 2023 02:48PM |
Admin Registered: 12 years ago Posts: 17,127 |
> [ 0.000000] Switching to timer-based delay > loop, resolution 53ns > [ 0.000001] sched_clock: 32 bits at 19MHz, > resolution 53ns, wraps every 114537122277ns > [ 0.007872] clocksource: > armada_370_xp_clocksource: mask: 0xffffffff > max_cycles: 0xffffffff, max_idle_ns: 101938038664 > ns > [ 0.019438] Console: colour dummy device 80x30 > [ 0.024168] Calibrating delay loop (skipped), > value calculated using timer frequency.. 37.49 > BogoMIPS (lpj=187492) >> Do you see something interresting here?
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 14, 2023 04:23AM |
Registered: 5 years ago Posts: 119 |
[ 0.000001] sched_clock: 32 bits at 19MHz, resolution 53ns, wraps every 114537122277nsA 19 MHz clock has one tick per 53 ns and if has 31 bits it would wrap every 115 s. So far so good. My hunch is that the 19 MHz input clock is actually closer to 17 MHz. That would explain the observations, right?
compatible = "netgear,readynas-104", "marvell,armada370", "marvell,armada-370-xp"Maybe 'armada-370-netgear-rn102.dts' and 'armada-370-netgear-rn104.dts' need a new clock definition to overrule the inherited one?
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 14, 2023 06:17PM |
Admin Registered: 12 years ago Posts: 17,127 |
[ 0.000000] Switching to timer-based delay loop, resolution 53ns [ 0.000006] sched_clock: 32 bits at 18MHz, resolution 53ns, wraps every 114840871909ns [ 0.007894] clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 102208375848 ns [ 0.019513] Console: colour dummy device 80x30 [ 0.023962] Calibrating delay loop (skipped), value calculated using timer frequency.. 37.39 BogoMIPS (lpj=186996)
[ 0.000000] Switching to timer-based delay loop, resolution 53ns [ 0.000001] sched_clock: 32 bits at 19MHz, resolution 53ns, wraps every 114537122277ns [ 0.007872] clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 101938038664 ns [ 0.019438] Console: colour dummy device 80x30 [ 0.024168] Calibrating delay loop (skipped), value calculated using timer frequency.. 37.49 BogoMIPS (lpj=187492)
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 14, 2023 08:48PM |
Admin Registered: 12 years ago Posts: 17,127 |
+ timer@20300 { + clock-frequency = <600000000>; + status = "okay"; + }; +
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 15, 2023 02:42AM |
Registered: 5 years ago Posts: 119 |
root@rn104:/boot# cp -a uImage uImage.bak root@rn104:/boot# cp -a uInitrd uInitrd.bak root@rn104:/boot# cp -a zImage-5.19.2-mvebu-370xp-tld-1 zImage.fdt root@rn104:/boot# cat dts/armada-370-netgear-rn104.dtb >> zImage.fdt root@rn104:/boot# mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.19.2-mvebu-370xp-tld-1 -d zImage.fdt uImage Image Name: Linux-5.19.2-mvebu-370xp-tld-1 Created: Sun Jan 15 08:22:58 2023 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 5074362 Bytes = 4955.43 KiB = 4.84 MiB Load Address: 00008000 Entry Point: 00008000 root@rn104:/boot# mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-5.19.2-mvebu-370xp-tld-1 -d initrd.img-5.19.2-mvebu-370xp-tld-1 uInitrd Image Name: initramfs-5.19.2-mvebu-370xp-tld Created: Sun Jan 15 08:23:16 2023 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 10392569 Bytes = 10148.99 KiB = 9.91 MiB Load Address: 00000000 Entry Point: 00000000 root@rn104:/boot# sync root@rn104:/boot# shutdown -r nowFrom the attached boot log:
[ 0.000000][ T0] Switching to timer-based delay loop, resolution 53ns [ 0.000001][ T0] sched_clock: 32 bits at 19MHz, resolution 53ns, wraps every 114537122277ns [ 0.007872][ T0] clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 101938038664 ns [ 0.019438][ T0] Console: colour dummy device 80x30 [ 0.024168][ T0] Calibrating delay loop (skipped), value calculated using timer frequency.. 37.49 BogoMIPS (lpj=187492)So no change here.
Gave up waiting for root file system device. Common problems: - Boot args (cat /proc/cmdline) - Check rootdelay= (did the system wait long enough?) - Missing modules (cat /proc/modules; ls /dev) ALERT! LABEL=rootfs does not exist. Dropping to a shell! BusyBox v1.30.1 (Debian 1:1.30.1-6+b3) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs) help Built-in commands: ------------------ . : [ [[ alias bg break cd chdir command continue echo eval exec exit export false fg getopts hash help history jobs kill let local printf pwd read readonly return set shift source test times trap true type ulimit umask unalias unset wait (initramfs)
root@t470s:/media/tme/rootfs/boot# mv uImage.bak uImage root@t470s:/media/tme/rootfs/boot# mv uInitrd.bak uInitrd root@t470s:/media/tme/rootfs/boot# cp -a zImage-5.19.2-mvebu-370xp-tld-1 zImage.fdt root@t470s:/media/tme/rootfs/boot# cat dts/armada-370-netgear-rn104.dtb.lagging >> zImage.fdt root@t470s:/media/tme/rootfs/boot# mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-5.19.2-mvebu-370xp-tld-1 -d zImage.fdt uImage Image Name: Linux-5.19.2-mvebu-370xp-tld-1 Created: Sun Jan 15 09:17:29 2023 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 5074371 Bytes = 4955.44 KiB = 4.84 MiB Load Address: 00008000 Entry Point: 00008000 root@t470s:/media/tme/rootfs/boot# mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-5.19.2-mvebu-370xp-tld-1 -d initrd.img-5.19.2-mvebu-370xp-tld-1 uInitrd Image Name: initramfs-5.19.2-mvebu-370xp-tld Created: Sun Jan 15 09:17:49 2023 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 10392569 Bytes = 10148.99 KiB = 9.91 MiB Load Address: 00000000 Entry Point: 00000000 root@t470s:/media/tme/rootfs/boot# syncConnected the SSD to the eSata port on the box and booted. Now everything is as before, it seems.
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 15, 2023 02:59PM |
Admin Registered: 12 years ago Posts: 17,127 |
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 18, 2023 01:05AM |
Admin Registered: 12 years ago Posts: 17,127 |
Mirabox 192.168.0.252 Globalscale Mirabox Linux version 5.19.2-mvebu-370xp-tld-1 (root@tldDebian) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1.0 PREEMPT Sun Aug 21 14:07:19 PDT 2022 Debian 10.2
root@Mirabox:~# dmesg |grep -3 clocksource [ 0.000000] kfence: initialized - using 2097152 bytes for 255 objects at 0x(ptrval)-0x(ptrval) [ 0.000000] Switching to timer-based delay loop, resolution 53ns [ 0.000001] sched_clock: 32 bits at 19MHz, resolution 53ns, wraps every 114840871909ns [ 0.008585] clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 102208375848 ns [ 0.021045] Console: colour dummy device 80x30 [ 0.026200] Calibrating delay loop (skipped), value calculated using timer frequency.. 37.39 BogoMIPS (lpj=186996) [ 0.037233] pid_max: default: 32768 minimum: 301 -- [ 0.120039] rcu: Max phase no-delay instances is 1000. [ 0.127140] devtmpfs: initialized [ 0.135209] VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 6 [ 0.143927] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.154436] futex hash table entries: 256 (order: -1, 3072 bytes, linear) [ 0.162033] prandom: seed boundary self test passed [ 0.170095] prandom: 100 self tests passed -- [ 2.080222] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 2.090034] PTP clock support registered [ 2.111673] vgaarb: loaded [ 2.120682] clocksource: Switched to clocksource armada_370_xp_clocksource [ 2.141373] VFS: Disk quotas dquot_6.6.0 [ 2.146034] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 2.178996] NET: Registered PF_INET protocol family
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 18, 2023 01:29AM |
Registered: 5 years ago Posts: 119 |
tme@t470s:~/Downloads$ grep -3 clocksource dmesg.lst [ 0.000000] kfence: initialized - using 2097152 bytes for 255 objects at 0x(ptrval)-0x(ptrval) [ 0.000000] Switching to timer-based delay loop, resolution 53ns [ 0.000001] sched_clock: 32 bits at 19MHz, resolution 53ns, wraps every 114537122277ns [ 0.007872] clocksource: armada_370_xp_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 101938038664 ns [ 0.019438] Console: colour dummy device 80x30 [ 0.024168] Calibrating delay loop (skipped), value calculated using timer frequency.. 37.49 BogoMIPS (lpj=187492) [ 0.034290] pid_max: default: 32768 minimum: 301 -- [ 0.110959] rcu: Max phase no-delay instances is 1000. [ 0.117666] devtmpfs: initialized [ 0.126529] VFP support v0.3: implementor 56 architecture 2 part 20 variant 9 rev 6 [ 0.134613] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.144256] futex hash table entries: 256 (order: -1, 3072 bytes, linear) [ 0.151252] prandom: seed boundary self test passed [ 0.158862] prandom: 100 self tests passed -- [ 2.054169] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 2.078575] PTP clock support registered [ 2.089990] vgaarb: loaded [ 2.099139] clocksource: Switched to clocksource armada_370_xp_clocksource [ 2.120027] VFS: Disk quotas dquot_6.6.0 [ 2.124320] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 2.160606] NET: Registered PF_INET protocol family
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 18, 2023 06:49PM |
Admin Registered: 12 years ago Posts: 17,127 |
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 20, 2023 02:57AM |
Registered: 5 years ago Posts: 119 |
RN102 0 0 0.000001 0.007872 0.019438 0.024168 0.034290 0.110959 0.117666 0.126529 0.134613 0.144256 0.151252 0.158862 2.054169 2.078575 2.089990 2.099139 2.120027 2.124320 2.160606 Mirabox 0 0 0.000001 0.008585 0.021045 0.026200 0.037233 0.120039 0.127140 0.135209 0.143927 0.154436 0.162033 0.170095 2.080222 2.090034 2.111673 2.120682 2.141373 2.146034 2.178996 Ratio NaN NaN 1.000000 0.916948 0.923640 0.922443 0.920957 0.924358 0.925484 0.935803 0.935287 0.934083 0.933464 0.933960 0.987476 0.994517 0.989732 0.989841 0.990032 0.989882 0.991560
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 21, 2023 01:26AM |
Admin Registered: 12 years ago Posts: 17,127 |
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 22, 2023 02:09PM |
Registered: 5 years ago Posts: 119 |
* Timer 0 is used as free-running clocksource, while timer 1 is * used as clock_event_device.
define TIMER_DIVIDER_SHIFT 5The shifting by 5 indicates that shed_clock (timer 0) is the CPU clock divided by 64, i.e. 1.2 GHz / 64 = 18.75 MHz which gives a time resolution of 53.333... ns as expected.
Quote
sched_clock() is used for scheduling and timestamping.
Re: Time is lagging substantially on Netgear ReadyNAS RN102 and RN104 January 22, 2023 05:38PM |
Admin Registered: 12 years ago Posts: 17,127 |
Quote
https://www.kernel.org/doc/Documentation/timers/timekeeping.txt
When the wall-clock accuracy of the clock source isn't satisfactory, there
are various quirks and layers in the timekeeping code for e.g. synchronizing
the user-visible time to RTC clocks in the system or against networked time
servers using NTP, but all they do basically is update an offset against
the clock source, which provides the fundamental timeline for the system.
These measures does not affect the clock source per se, they only adapt the
system to the shortcomings of it.