Temperature Monitors

Avalanche will adjusts the intervals between null polls depending on what it is doing, so its null poll rate will not be uniform. However, there shouldn’t really be any polling if there are no open connections, at least as far as I can recall. This doesn’t look to be the case, so I’ll make a note to look into that next time I dig it out.

Testing today yields the following provisional results:

!Avalanche can be launched without affecting CPU speed control adversely (contrary to what I said earlier – I still cannot account for the different behaviour if launched at boot), but once connection with a server is made, disconnecting but leaving !Avalanche running disables CPU ‘slow’ speed, and the only way to restore the latter is by quitting !Avalanche. I’ll continue to test, but the above is the result of several iterations.

Avalanche starts various modules if not already loaded. Something in Avalanche using a sub-optimal module?
Toolbox elements are unlikely¹ as many other applications would trigger the effect, so you’re probably down to these candidates:

RmEnsure BypassAlt 0.00 X RMLoad System:Modules.BypassAlt
RmEnsure SysLogDevice 0.00 X RMLoad System:Modules.SysLogDev
RmEnsure SocketWatch 0.00 X RMLoad System:Modules.Network.SockWatch

¹ Not impossible.

RmEnsure BypassAlt 0.00 X RMLoad System:Modules.BypassAlt
RmEnsure SysLogDevice 0.00 X RMLoad System:Modules.SysLogDev
RmEnsure SocketWatch 0.00 X RMLoad System:Modules.Network.SockWatch

Of the above,

167 204379B4 202DAB74 SocketWatch

is loaded (!Avalanche is currently launched and connected to my laptop server).

EDIT: closing the server window (i.e. disconnecting) but leaving !Avalanche running, *modules still lists SocketWatch as above.

FURTHER EDIT: quitting !Avalanche and running *modules still lists SocketWatch, but CPU speed control is back to normal i.e. slowing down on idle.
So SocketWatch not the culprit?

SocketWatch shouldn’t cause a problem. It relies on socket events, not Wimp polling. Its whole purpose is to remove the need for sockets-based apps to poll for traffic.

Update: I’m pretty sure now, based on the last couple of days’ usage, that !Avalanche is responsible for locking the Pi into high-speed mode, once it has connected to the laptop server. This is not to denigrate !Avalanche’s usefulness: having quick access in the RISC OS desktop to Firefox on Windows offers a better and more comprehensive browsing experience than any native browser (I haven’t tried Iris, to be fair, but I have used Otter extensively), and it is useful to be able to view RISC OS-generated PDFs etc as they will be seen by the majority of recipients. I have also found !Avalanche reliable and stable in daily use. However, having disconnected the server (at which point CPUClock was showing an unvarying 1500MHz and 60 deg.C) and quit !Avalanche, ten minutes later and I’ve got 51-53 deg.C at a steady 600MHz.

I see similar here on both the Titanium and RPi400, cpu is permanently at full speed on an Avalanche connection and remains so after a disconnection until Avalanche is quit when things do cool down again. TaskUsage does show a slight increase in polls on connection which continues after disconnection.

Otherwise Avalanche is really very good.

(Speed and temperature measurements are from CPUClock.)

I am using an ARMX6 here and not seeing the reported issues, I have !Avalanche on the icon bar all the time v0.28 if it makes any difference, and on checking its not using any CPU use at all here, whereas Organizer is using up to 1%, and my speed is varying all the time, but !Iris and it webkit processes are using lots of processor CPU and temp is 48 C and at maximum CPU speed. So not seeing the stick at maximum CPU speed.

Avalanche is 0.28 here.

After disconnection and CPU stuck at high TaskUsage shows Avalanche as using 0% cpu. The total usage is also 0% but the cpu is none the less permanently high.

Iris idling uses 55% cpu and as such masks any idling issues that Avalanche might have.

I have had a bit of a play with an ARMX6 and an IGEPv5. I haven’t yet seen the problem, except ….

… at one point I was viewing the ARMX6 on the IGEP, where the ARMX6 was itself viewing the IGEP! That is not to be recomended, since any change in one view triggers a change in the other view which triggers a change in the other view….

I am currently posting this from the ARMX6 using the VNC view on the IGEP, and all cpu speeds and temperatures are behaving normally. I’ll leave everything running to see if the problem appears later.

I have managed to get the ARMX6 into an apparent locked fast speed, although TaskUsage showed nothing hogging the processor. Avalanche was connected and displaying the remote IGEP desktop. I then quit CPUClock, including module, and then reran it. After CPUClock relaunched, the cpu speed was switching between fast and slow. However, this lasted only for a minute or so and the cpu speed appeared once again locked at fast.

Killing the Avalanche connection immediately restored the fast/slow switching, although the ratio of fast to slow seems much higher than normal for an idling machine. Ahhh – after about 5 mins the fast speed ratio increased and it is now constant at fast again.

Quitting Avalanche, and the fast/speed switching immediately reverted to complete normality, with cpu staying at slow speed until some action is carried out.

All very curious.

One other thing I should note is that during the time the cpuspeed appeared to be locked at fast, there was no indication the cpu temperature increased. The ARMX6 is normally very stable in terms of temperature, being underclocked and fan cooled, but I should have thought there would have been a small rise in temperature at that time.

but I should have thought there would have been a small rise in temperature at that time.

Might depend upon what the machine is actually doing? If it’s essentially doing nothing, only faster ;), then an increase might be minimal – especially for a board that’s not only being run slow, but is fan cooled too.

Judging by what’s been said so far here (and only a total guess) I’m wondering if Avalanche is hooking into various things (and running null polls) in order to be able to send state to the remote connection, and not fully unhooking itself afterwards, leading to the Wimp thinking there’s something happening that needs faster speed? Still claiming those nulls?

there was no indication the cpu temperature increased

That might just be showing how well fan cooling can work.

My machines are fanless and it is clearly seen that Avalanche after a disconnection will take the machine take to, or keep it at, its hottest. The Titanium maxes out at 80°C from a quiescent base of around 60°C, which I am sure that is well within the capabilities of the device. The RPi400, 2400MHz with its magnificent heat spreader, hardly notices maxing out at 45°C, up from 35°C. The RPi4B, 2147MHz in a passive Flirc case, rises to 57°C. An overclocked RPi4 in an unventilated ‘official’ case might get a bit sweaty.

It just seems a bit odd that Avalanche after a disconnection does not return to its before connection status, but there may be a reason.

With a reasonably cooled machine there is perhaps no big issue and a pragmatic ‘solution’ might be to not load CPUClock and forget all about it.

With a reasonably cooled machine there is perhaps no big issue and a pragmatic ‘solution’ might be to not load CPUClock and forget all about it.

I agree: AFAICS none of the temperatures described by posters above should prove to be significantly life-shortening, nor presumably is there any problem with a Pi4 (for example) running at 1500MHz indefinitely, providing temps remain within a reasonable range. My Pi4 is mounted vertically behind the monitor on a homemade VESA mount, caseless with a WiFi HAT, orientated so that the USB sockets are at the bottom. Temps with !Avalanche not operating are 52-53 deg.C, with !Avalanche in operation around 60-61 deg.C. CPUClock throttling is set at 65 deg.C. It’s not overclocked. I don’t anticipate any problem running at these temperatures indefinitely.

With a reasonably cooled machine there is perhaps no big issue and a pragmatic ‘solution’ might be to not load CPUClock and forget all about it.

Indeed. I never normally run CPUClock on the ARMX6 because the temperature remains cool, even when working hard.

Both the Titanium and IGEPv5, although in an enclosure fitted with a fan, do ramp the temperature up on any excuse, so I do normally run CPUClock on those.

Perhaps the temperature increase is mostly due to the higher CPU frequency, rather than Avalanche directly. Although Avalanche clearly shouldn’t be polling when there are no connections, a few tens of null poll events per second, each using a tiny fraction of a second shouldn’t really require the CPU to ramp up.

Maybe they shouldn’t, but something Avalanche is doing is causing the ramp-up. However that in itself is not a cause for concern, so long as operating temperatures remain within acceptable limits, and the general consensus (as far as I can see) seems to be that they do.

Still has a power consumption implication. If you’re on mains that’s probably not a concern, but if you’re on battery, even in a car if it’s parked up for quite a while, it may be.

even in a car if it’s parked up for quite a while, it may be.

Probably not that relevant, really.
Given that Avalanche is a client and not a server, I’m trying to think of a case where you’d leave a Pi running unattended in a car with such a thing loaded.
In fact, a Pi left running unattended in a car is possibly a novel way of discharging the battery whatever it’s doing.

To put this into context, however, a Pi1 and Uniroi 7" display were happily powered from a 15000mAh brick for all that I wanted to do during the day (maybe seven or eight hours?). The battery never ran out, and seeing as how the consumption was low, if I wanted to do something else for a while, I just left everything running.
Granted, it was a Pi1, but on the other hand I’d have expected the screen to be the power draw here.
Photo: https://heyrick.eu/blog/images/20210815openair.jpeg

When it comes to car batteries, they’re much more massive. Various internet estimates give figures in the range if 60-90 hours, though this may just be the Pi itself (any display or add-on will take power), plus there’s a huge difference between “having enough charge” and “having enough charge to start the car”.

Conclusion? If you have plugged your machine into a car, don’t run Avalanche.
That being said, RISC OS isn’t terribly good at wireless networking, so if you’re running your machine in a car, what’s it going to connect to? ;-)

if you’re running your machine in a car, what’s it going to connect to?

Wired connection to your Mac, which is wified to the router in your house? ;-)

Various internet estimates give figures in the range if 60-90 hours,

What’s the Pi draw? A car battery can deliver around 10W for that long – leaving nothing to start the car, of course. How much you need to start a car is a how long is a piece of string question: a big diesel engine, cold, in cold weather might need as much as 30% of a full, healthy battery; a warm petrol engine in good condition less than 1%.

I’ve measured the drain on my old Honda Accord’s battery just keeping the alarm and the clock going (without anyone activating the alarm!) – it’s about 150mW. Which ought to mean I can leave it parked for weeks on end and still start it. Except that the battery’s old and has I don’t know how big an internal drain. In winter it needs charging if it’s left more than about a week.

Which ought to mean I can leave it parked for weeks on end and still start it.

For a modern car with alarm and remote central locking, I think VW quote six weeks before you should think of checking the battery state¹. Empirical evidence says that mine drops around 20-30% in three weeks over a summer lock-down, so that might not be too far off the mark.

¹ In the context of asking a dealer for advice on how to get into such a car if the battery is totally flat. It’s a lot of hassle. Don’t do it…

It’s a lot of hassle.

2004 Honda Accord Tourer: you can open the door with a mechanical key. The bonnet catch is mechanical, lever under the dashboard. Hey presto, connect up the charger to the battery. The biggest hassle is setting the clock…

More fun was when the battery in the key went flat: open the car with the key, no problem – but the alarm goes off, and can’t be stopped. Drive home with the alarm going, get Grace’s key, turn off the alarm.

Nobody took a blind bit of notice of an elderly gent driving a car with the hazards flashing and an alarm going…happily the hazards had the decency to defer to the direction indications when required!

how to get into such a car if the battery is totally flat.

Actually pretty easy unless there is really something badly wrong with the design of the VW.
The key will work in the driver’s door. Losing battery won’t be a big problem as the immobiliser (BSI unit) is paired with the key (usually it can only be programmed once), so it ought to function as soon as you get power into the electronics. It’s specifically designed so you can’t replace the actual key without replacing the entire engine management system (well, you can replace only the BSI if you can get the ECU pairing codes; and generally get it right the first time or the ECU will likely disable itself forever).

I had no trouble starting the C1 using jump cables from my toy car, after having no battery hooked up for a couple of months.

Programming the door unlocking, on the other hand, is voodoo. This uses a 433MHz gizmo (it’s not the same thing as the immobiliser) and it needs to be paired with the car. From memory it’s something like turn the ignition on then off, with the driver’s door open, lock and unlock using the door button, twice. Repeat all of this. Close the door. Ignition on and off twice. Open door. Press “lock” on the key fob, twice.
[the fob broke, got a replacement, had to reprogram the car]

Other cars will use other methods. My toy car wants the ignition turned from off to accessories five times with a specific timing; a car we used to have wanted something similar, but the accelerator press and not pressed in alternation. Thank <Deity$Name> for the internet!

What you can take away from this:

• Changing the battery in the remote fob, or the circuit board in the remote, is fiddly but not a big deal. You can get instructions online (if you don’t have it mentioned in the back of the manual).

• If you have an immobiliser, do not lose your keys. They’re paired to the car, both in actual hardware (the steering lock) and in electronics (the immobiliser lock). As an anti-theft device, neither are intended to be replaced.

• With a battery failure, the unlock will probably cease working. It’s not a big deal, it’s a legal requirement that the key work in at least the driver’s door.
  The immobiliser is fixed to the key, on the other hand, so starting the car shouldn’t be an issue once everything is powered up.

but the alarm goes off, and can’t be stopped.

Does that car not have an immobiliser?
[how to tell – if you can get keys cut for it and start the car with a freshly cut key, it probably doesn’t have one]

Mom didn’t like car alarms. In the lovely spot we lived for a while not too far from the forum these messages ought to be in, car alarms were useless. Thugs would push cars to set the alarms off. Once in a while an alarm would go off because somebody bricked a window to swipe something, but nobody would pay any attention because it happened so often. But then, this was where somebody bricked a granny’s living room window in the middle of the day and oddly enough nobody saw a thing… Lovely place, was so happy to leave.

To lamely try to be vaguely on topic – cars have temperature monitors too. Bad things happen if they get too hot. While microchips might simply stop working, or release some magic smoke if you push it too hard too quickly, cars failing from overheating tend to be slightly more impressive. From gushing steam and smoke (and a possibly recoverable engine) to some rather spectacular videos on YouTube of what happens if you drain out the oil and coolant and run the engine in the red. A horribly cruel end to an engine, and a pretty good reminder as to why checking levels is important!