Poor timekeeping on a RasPi-5/4GB after Bookworm OS update....

Dec 04, 2023 Last reply: 2 years ago 54 Replies

RasPi-5 4 GB.



APT update/upgrade from a mid-November OS (possibly Oct-10?) to the current version (Dec-03) and noticed a major drop in excellent NTP timekeeping performance. Was there anything which might have caused this? Thanks! Current data:



formatting link
All NTPsec settings look the same, as far as I can tell. Servers the same. Just something in the OS which has changed possibly lowering the CPU response, perhaps it's sleeping for moments or something. Process priorities? Suggestions welcome!



I know there's a Bookworm in beta but no idea whether this issue is fixed, or even known about?


Check that you still are using ntp and the systemd virus hasn't taken over yet another part of your OS.

systemctl status ntp

Should be state it is active.

systemctl status systemd-timesyncd

Should report not found.

---druck

Such threads are NOT encouraging ....

There SHOULD be almost NO diff between using Deb derivs on a Pi-3/4/5 ... but is that TRUE ???

If Pi's are becoming a total pain in the ass, well, I'll have to look for new solutions.

Many thanks for that. TL:DR: it's just ntp.

However, it appears to be NTPsec rather than the older NTP I normally use.

Detailed report:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ pi@RasPi-29:/var/lib $ systemctl status systemd-timesyncd Unit systemd-timesyncd.service could not be found.

pi@RasPi-29:/var/lib $ systemctl status ntp

  • ntpsec.service - Network Time Service Loaded: loaded (/lib/systemd/system/ntpsec.service; enabled; preset: enabled) Active: active (running) since Sun 2023-12-03 15:04:12 GMT; 2 days ago Docs: man:ntpd(8) Process: 846 ExecStart=/usr/libexec/ntpsec/ntp-systemd-wrapper (code=exited, status=0/SUCCESS) Main PID: 856 (ntpd) Tasks: 1 (limit: 4915) CPU: 10.267s CGroup: /system.slice/ntpsec.service `-856 /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g

-N -u ntpsec:ntpsec

Dec 05 19:04:12 RasPi-29 ntpd[856]: LOG: frequency file /var/lib/ntp/ntp.drift-tmp: No such file or directory . . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

From the "Process:" line it looks like systemd has poked its nose in somehow. The last line notes that a directory in /var/lib was missing, although I think the drift files only affects fresh starts. Nevertheless I created the missing directory in case it makes any difference, appreciating that it may need recreating every boot as it's in /var.

systemctl status ntpsec

produces the same output.

I think the blame may be laid at the changes within the OS, rather than totally in the hardware itself.

Essentially systemd is forcing old code that has been stable for years to be rewritten to conform to it - as far as I can tell.

Thus invalidating all the old help files and tutorials on it.

It that 'progress' that Liberals love to worship.

It's not the first time that something like this has happened in the Linux environment, and lack of backwards compatibility is a rather inconvenient and tiresome "feature".

It is the bane of all software - and it forces you to upgrade constantly or never upgrade at all.

Many people I know would be entirely happy with Wordstar on CP/M and a dot matrix printer....Come to think of it a pi Zero with a bit of screen added and Joes Own Editor would do that.

Why use a clone when you can use the original on a Pico :-)

formatting link
and I'm sure you could do the dot matrix bit with a Pico too:
formatting link
Theo

That's not my experience: I've moved a few personal background programs from the old sysv system to systemd without much problem at all: it was just a matter of setting up a systemd descriptor, which wasn't any harder than doing it for the old system: in fact I thought it was a bit easier since all the 'scriptlets' are now in a single file rather than the two or three scripts that some background tasks could need.

No mass storage. No output for an 80x25 style screen. I love my Picos finally, but they cannot even drive a floppy disk.

Whereas a Zero can come with an SSD an HDMI attached screen and probably drive a parallel port.

In terms of a 'word processing station' I think that is about ideal.

all very ingenious, but...I guess a zero running Raspios could drive a modern inkjet or laser printer via USB.

Agreed ... but I don't think anybody is going to put up with an 80x24 screen anymore.

GUI/WYSIWYG is a lot better. There are a number of medium-power word processors that run on Linux and the ubiquitous LibreOffice suite adds even more clout. For dirt simple, use Leafpad and friends.

A Pico is a microCONTROLLER ... it's meant for operating "things" or being a "thing".

Love microCs but there'd be no point in making a word-processor using one. Yea, somewhere there IS a SD-Card library, so you can have yer storage, and there IS a serial library so you can pull out your beloved serial terminal (or make your own). Even Ard Uno's have those libs handy. I even found a TCP stack lib and made a (very slow/simple) web server out of one and hung it on one of the company's unused domains for a couple of years. ASCII-Art "graphics". Now a printer ... find an old Oki rs232 matrix printer or something so you won't need much for a 'driver'.

Hmmmmm ... a few weeks back I did report an unusual problem related to the PLATFORM/Hardware. It involved the "autostart" features in LXDE. Something that worked properly on Pi-3's did NOT work on Pi-4s. This change coincided with using BookWorm - but it WAS distinctly related to the model of Pi.

This was NOT a matter of what you initially installed on. Tried something installed on a 3, moved the card to a 4 and PROBLEM. Installed from scratch on a 4, STILL the problem.

There's SOMETHING in the hardware that makes BookWorm take an alternate path. Don't have a Pi5 yet, so I don't know how that will react.

DID find out how to make 'autostart' work ... but it was weird AND related to Wayland-vs-X11. With Wayland the documented place for the 'autostart' has to be different - and a FOLDER populated with ".desktop" type files.

As for "time-keeping" ... normally the Pi looks for certain internet time servers - and should thus keep perfect time, likely to the millisecond.

Actually the RPi, all models, can do much better than millisecond, down to tens of microseconds when you add a GPS/PPS device. In the instance I reported the only update was an upgrade of the OS (and its components).

Here's a RasPi-400 Wi-Fi synced to in-house stratum-1 NTP servers:

formatting link
within about 100 microseconds or better.

The two RasPi-5 are running off the same 5 GHz Wi-Fi as is the RPi-400. I'll try changing one of them to the 2.4 GHz Wi-Fi but I'm not expecting any improvement!

There's three of them open on this desktop now, although for serious work I usually use 80x<as much as I can fit> terminals.

Yet when I need to write a letter and snail mail it I use vi and groff - old habits die hard and 1980s documents still work fine.

To be honest, those screens with very limited capability and no distraction were far far more productive than today's GUIS. In terms of commercial computin, windows were a huge step backward in productivity.

I guess that's why most professional book authors don't use it.

Depends how you use them. When I used terminals I usually had three or four on my desk (and from time to time found myself typing on the wrong keyboard). These days (since around 1990 when I met my first X terminal) I tend to have more terminals but they're all on the one (or two) big screen(s) and use the same keyboard. They're also colour, tabbed and come with big scrollback buffers - way nicer than 1980s terminals even before you throw in the window manager with unlimited virtual desktops for separating threads of activity.

Nah, you just have to use them right - now IDEs OTOH ...

But you do not spend your days listening to customers and entering their details on the same screen over and over. Or writing a series of letters over and over. Or checking in today's stock, and booking it out again.

That is the reality of commercial computing, where it actually *aided* productivity.

The last time I peeked at a winders PC in a bank, it was running nothing but an IBM terminal emulator with an 80x25 screen hooked up to a mainframe somewhere in probably Berkshire.

Those of us who read Byte will remember Jerry Pournelle's Chaos Manor column and his first editor and word processor descriptions. For creative writing he just wanted to see the words and no s*it, no status lines. Just his words. If he wanted info etc. he would press a button. But when creating, he just wanted his words. When he moved to graphical systems there was so much moaning about word processors displaying status he didn't want.

Me, here I am with a Windows laptop with 2x 24in monitors showing some corporate hellish crap (Outlook/Teams/company webpage on Edge) plus RDP session to a big-iron Windows box (64 core) and that has X stuff from the big iron Linux boxes... 7x Xterm, Xemacs, normal emacs in Xterm, Gedit, Notepad++, Cygwin, Perforce. The most productive for writing software for me, emacs with syntax highlighting or Xemacs with syntax highlighting. Sure I can use Visual Studio on Windows or VS Code on Linux (the debuggers are nice) but for just writing code, emacs. (And sometimes vi or nano).

Less distraction please.

It all depends in what you're used to writing code (or text) on:

- The base case has to a box of 80 column punch cards and a 12 key hand punch: the standard kit when I learnt to program computers, first assembler then COBOL: many of us carried a stack of 20 cards: the minimal set of cards that a COBOL compiler would compile without complaints

- paper tape was an improvement (could be written and read with a teletype or, better, a Flexowriter. But its main advantage over cards was that it couldn't be scrambled if you dropped it.

- next step was the use a teletype as a terminal, but only because it could be used interactively. The standard interface for minicomputers and the early microcomputers.

- an 80 x 24 monochrome Visual Display Unit was the next step up but its ease of use depended entirely on the software driving it: a lot of mainframes sed block-mode screens: you could locally edit a screenful of text before hitting 'SEND', which caused the editor program to append the current screenful the the file and show you the next 24 lines. This was slightly better than using a teletype and was the way you programmed almost all mainframes. Minicomputers and 2 gen microcomputers uses what was effectively a teletype fitted with a 80 x 24 display instead of a paper tape reader and punch. The architype at this stage was a DEC VT100 or one of the monochrome Wyse devices.

- then, finally, we got colour graphic terminals but know what, IME you're no more productive writing code on these than on a Wyse or DEC: and know what, I prefer to write code on a modern Linux system with a bog standard monochrome text editor, such as vi, microEmacs or, currently, gedit and to use 'make' to compile C and 'ant' to compile Java and with everything run from the command line in a console window.

Not in my book. I've tried IDEs and don't like them - most just clutter the screen and the mouse just gets in the way if its used for anything much more than simple cut'n paste operations or launching applications.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required