After getting another Pi 5, I've moved a Pi 4B running Bookworm in to
the role taken by a Pi 3B running Bullseye, which is monitoring 6
ds18b20 sensors, configured as 2 1-wire buses with 3 sensors on each.

With the Pi 3B, I could either read the sensors sequentially taking
about 0.9s each, or using threads simultaneously in 1.0s. The Pi 4B with Bookworm reads the sensors sequentially a shade faster at just over
0.8s, but when reading simultaneously, returns 2 after 0.8s, another 2
after 1.6s and the last two at 2.4s.

Anyone have an explanation for this?

It's not a problem as I changed some time ago from performing one
simultaneous read every 5 minutes to reading sequentially every minute
and averaging over 15 minutes.

---druck

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Thu, 19 Sep 2024 10:36:16 +0100, druck wrote:

With the Pi 3B, I could either read the sensors sequentially taking
about 0.9s each, or using threads simultaneously in 1.0s. The Pi 4B with Bookworm reads the sensors sequentially a shade faster at just over
0.8s, but when reading simultaneously, returns 2 after 0.8s, another 2
after 1.6s and the last two at 2.4s.

Is this Python code? Python threading cannot currently take full advantage
of multiple CPUs, owing to having to serialize all interpreter operations through the “Global Interpreter Lock”.

This is going to be fixed from 3.13 onwards.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)