On Mon, 14 Oct 2019 13:01:52 +0100
Chris Elvidge  wrote:

>On 14/10/2019 12:24, NY wrote:
>> "druck"  wrote in message news:qno2oo$759$1@dont-email.me...
>>
>> On 09/10/2019 20:31, Dennis Lee Bieber wrote:
>>> > I'd updated both 3B+, 4B2G, and 4B4G to the most recent Noobs
>>> Raspbian > last week. Today I ran "sudo apt-get update/sudo apt-get
>>> upgrade" on > systems (main item: an SSL update). While the second 3B+
>>> was processing > the "upgrade" phase, I plugged in the 4B2G. I was
>>> able to run the same > update/upgrade, shutdown, swap with the 4B4G,
>>> update/upgrade (needed two > updates -- NTP had not synched the time
>>> and it rejected a repository for
>>
>> The lack of a battery-backed (or even capacitor-backed) real-time clock
>> is a nuisance if the Pi reboots and there isn't an internet connection
>> by the time the Pi needs it - if it takes longer for the router to boot
>> and establish a connection than it takes the Pi to boot. I run a
>> weather-station recording package (Cumulus) on my Pi and occasionally
>> after a power cut the Pi has booted up with the wrong time (eg 30 or so
>> minutes in the past) so I've had readings every minute marked with the
>> wrong time which leads to a graph that goes back in time (!) until NTP
>> eventually syncs the Pi's clock (*). It happens so rarely that it's not
>> worth devising my own external battery-backed RTC solution, but it's
>> annoying when I have to go in and hand-modify the times in the log files
>> and restart the software so it reads and displays them on its graphs.
>
>I have killed and disabled the systemd service fake-hwclock.service
>(systemd does a load/force at startup, which can screw the time
>abominably) and then do "fake-hwclock load" at reboot (in /etc/cron.d/)
>and run "/sbin/fake-hwclock save" as a root cron job every minute.
>
>>
>>> > being invalid [the R-Pi was using the last boot time, and the
>>> repository > was dated five days in the future ]), and shutdown...
>>> ALL BEFORE the > 3B+ finished its upgrade of the same files.
>>> >
>>> > Either that 3B+ has a very slow SD card, or a distinct speed
>>> difference.
>>
>>> The Raspberry Pi 4's SD card reader is many times faster than on
>>> previous models.
>>
>> Have you found that access to the system drive and swap area is affected
>> by the slower SD access of the 3B+? I also use my 3B+ Pi as a PVR (a
>> video recorder) and I was impressed that the software I use (TVHeadend)
>> was able to write several overlapping programmes, including in HD, to
>> the SD card without any apparent bottleneck. I only switched to
>> recording to USB hard drive because I needed more space than on a 32 GB
>> SD card.
>>
>>
>> (*) Sometimes it has taken maybe 20-30 minutes before the timestamp of
>> the weather readings is correct - I'm not sure whether it's NTP that is
>> taking that long to set the system time correctly, or whether it's the
>> weather-station software that isn't noticing that the system time has
>> been corrected. Both times it's happened are when I haven't been around,
>> so I've been able to look at the system time (eg using the date command)
>> in the interim.
>

Just as a matter of interest, has anyone tried the devuan image for the Pi?
If so, does this startup and run better or worse than systemD distros?


--
W J G

--- SoupGate-Win32 v1.05