Uptime command

The other day I noticed that there doesn’t seem to be any easy way to see how long the system has been running. So I wrote a module to read the monotonic timer and spit it out :)

The module is currently available from here (click the Uptime tab) or PackMan. You might want to put it in !Boot.Choices.Boot.PreDesk so that it starts automatically. Once it’s running, just type *Uptime for the details. The output is more-or-less the same as you get in Unix.

If you run into any issues then let me know… you’d think that not much can go wrong with such a simple command, but you never know!

If you run into any issues then let me know… you’d think that not much can go wrong with such a simple command, but you never know!

Does it take into account monotonic timer wrap-around? :-)

Hah, I did actually consider that, but didn’t write any code to handle it. IIRC it’s close to 18 months before it wraps around: I wish you the best of luck in keeping the system running for that long in the first place :)

Dave Higton’s central heating control system would like to have a few words with you :-)

If I had a second Pi that was running the server, it would probably be similar. What causes resets here is dev work (building new ROMs, stupid crashes, yada yada) and the fact that sometimes rural electricity is flakey. It can survive a hurricane, but it can’t cope with milking time. Hmmm!

If the machine is left to do one job reliably, then it can just get on and do it… RISC OS doesn’t autoupdate, run a bazillion leaky services, or gigabytes of frameworks to print “hello”. So, yeah, I can totally see Dave’s machine managing long uptimes. After all, what’s the point of a crashy heating controller?

OK, I revise my answer to “I can’t think of a reliable way to accomplish it” :P

I’m open to suggestions. First of all, is there already a “rollover counter” somewhere? If so, that’ll simplify things a bit!

If not, my best idea was something like this (with nice round numbers to simplify things):

• Track number of rollovers, starting at zero
• Set a CallEvery for 250 days
• If the current time is less than the highest seen time, increment rollover counter
• When *Uptime issued, add count*500 days to the result.

I leave it as a exercise to the reader to realise why this won’t work :)

First of all, is there already a “rollover counter” somewhere?

Nope.

If not, my best idea was something like this

That looks like a reasonable way of doing it to me.

I leave it as a exercise to the reader to realise why this won’t work :)

Easy, *Uptime should also do the rollover check. And (depending on how much you want to future-proof things) it should either disable interrupts or use a spinlock to make sure the callevery won’t fire while it’s getting the current monotonic time + rollover value.

Also (since the module appears to be written in C) you can just change the days/hours/minutes calculation to use a 64bit int (and add rollover_count << 32) rather than manually adding on the correct number of days/hours/minutes.

You didn’t notice the same problem that I did… namely that if the module isn’t loaded at boot, and is instead manually loaded after the counter already rolls over, then the result will be wrong.

I’m not convinced that that’s a major issue, but it’s still a possibility. In any case I’ll think about implementing something :)

I’m tempted to come up with a test ROM that uses a 16-bit counter so that it rolls over every 11 minutes, but I suspect that that’ll break all sorts of things! (and the relevant code is probably assembly, which is a bit of a black box for me).

You didn’t notice the same problem that I did… namely that if the module isn’t loaded at boot, and is instead manually loaded after the counter already rolls over, then the result will be wrong.

I think that’s an acceptable bug, considering that the OS doesn’t track counter rollover itself.

I’m tempted to come up with a test ROM that uses a 16-bit counter so that it rolls over every 11 minutes, but I suspect that that’ll break all sorts of things! (and the relevant code is probably assembly, which is a bit of a black box for me).

The way I’d test for that kind of problem would be to initialise the counter to a value that’s close to the rollover point. You’ll only get one shot at testing for any rollover bugs before you have to reboot, but it will avoid breaking all the code which assumes the timer is 32 bits wide.

Sounds like a plan.

Brave people might want to try version 0.08 [edit: no longer there; use the latest], which “should” handle timer wraparound. Note that this version hasn’t been through much testing, so it is not for use in nuclear reactors and it may eat your lunch, etc. The earlier version 0.07 linked in the first post is still available.

Note that 0.07 will actually fail at ~250 days instead of ~500! No prizes for guessing why…

Using 0.07 on my ARMini:

*uptime
03:56 up 44 days, 0:21

Not bad as this is my primary machine :-)

I’ve had one NetSurf crash in that time, 34 days ago. The log file is getting quite large…

I had a RiscPC that was up continuously for just over four years. Took it down myself when one of its two hard drives failed, in order to replace the hard drive. It was being used as a fileserver, fairly heavily used for about ten hours a day, five days a week, lightly at other times. (HUGE hard drives – one of them was 120MiB!)

The way I’d test for that kind of problem would be to initialise the counter to a value that’s close to the rollover point.

I don’t suppose our resident kernel expert happens to know where this is initialised? :)

Meanwhile, thinking forward to version 1.0, I’d like to be able to distribute it though PackMan, but it seems that PackMan can only handle apps, not modules. It’s easy enough to bundle it up into an app directory, but I’m interested in thoughts on where to put it – it doesn’t seem that a star command should go into Apps; would Resources be “good enough”?

I’m also planning to make 1.0 open source. I may also release the source to an earlier version, depending on how things go.

I don’t suppose our resident kernel expert happens to know where this is initialised? :)

A kernel expert I ain’t, but isn’t this actually a hardware issue? I suspect the counter may start at zero as soon as power comes on, and not actually have a “reset” input at all.

but isn’t this actually a hardware issue?

Nope, it’s a software counter.

close to the rollover point.

Just add an offset after reading the Monotonic time in a test version.

Would it be worth having something in Boot that logs the current time at start up – preferably just after NetTime has set the clock and use this as the basis of the Uptime calculation?

Meanwhile, thinking forward to version 1.0, I’d like to be able to distribute it though PackMan, but it seems that PackMan can only handle apps, not modules. It’s easy enough to bundle it up into an app directory, but I’m interested in thoughts on where to put it – it doesn’t seem that a star command should go into Apps; would Resources be “good enough”?

PackMan can handle Modules, you don’t need to bungle it up into an app directory, but maybe I’m misunderstanding what you mean. You just need to put it in a folder where you want it installed. The list of the base folders available can be seen in the Advanced/Paths menu from PackMan. You can also add the Component field to the Control record so that the default you give it can be overridden. Email me (my address is in the !PackMan !Help) if you need more information.

Modules have been put in !System.310.Modules frequently, I don’t know if this is good practice or not though.

When my server starts, it reads the monotonic time and subtracts that from the current RTC time to determine when the machine was booted, and then it just calculates the difference between that and the RTC time to work out the time the machine has been active…

I don’t suppose our resident kernel expert happens to know where this is initialised? :)

I don’t think it is explicitly initialised; it looks like it will get zero-initialised with the rest of the kernel workspace.

However the IRQ handler which updates it (‘TickOne’) is installed here, so if you were to set the value just before that bit of code then that would probably be good enough. E.g.

LDR a1, =&ffff0000 ; or whatever other value you want
LDR a2, =ZeroPage
STR a1, [a2, #MetroGnome] ; yes, internally it's called MetroGnome.

PackMan can handle Modules, you don’t need to bungle it up into an app directory, but maybe I’m misunderstanding what you mean. You just need to put it in a folder where you want it installed.

Since the module needs to be kept running to allow it to track counter rollover, it would make sense to have it in PreDesk so that it’s run on startup (or at least have an obey file which will RMLoad it via !System)

Modules have been put in !System.310.Modules frequently, I don’t know if this is good practice or not though.

As long as they’re RISC OS 3.1 compatible, that’s fine. The key with !System is to put your module in the folder that corresponds to the oldest OS version that the module will run on (although this does open up the possibility that an older version of the same module in a newer folder could block the newer version of the module from being seen; I haven’t checked but I’m assuming SysMerge / Installer deals with that)

When my server starts, it reads the monotonic time and subtracts that from the current RTC time to determine when the machine was booted, and then it just calculates the difference between that and the RTC time to work out the time the machine has been active…

Which is fine, as long as you don’t mind changes to the RTC time affecting the reported uptime (network time synchronisation, leap seconds, manual time setting by users, etc.)

Which is fine, as long as you don’t mind changes to the RTC time affecting the reported uptime

I use it as a guide rather than an absolute “system alive for n centiseconds”. ;-)

(network time synchronisation,

Implies the time was either wrong or has drifted.
I should probably add some code to detect erratic huge changes, like my Beagle has no RTC so will start with default time until NetTime fixes that…

leap seconds,

Rare enough, so will only throw the calculation off by a second every n years!

manual time setting by users, etc.)

That’s on their heads, then. :-)

Just add an offset after reading the Monotonic time in a test version.

That’ll work if I can’t get Jeffrey’s suggestion to work. Thanks.

PackMan can handle Modules

I was sleepy when I tested it¹; obviously I didn’t test it too well! I’ll play around with it some more later :)

calculates the difference between that and the RTC time

After a little experimentation on a Unix system, it seems that the RTC is completely ignored. The rollover counter will hopefully handle most things, but I could potentially use the RTC to work out the “initial state”: If RTC is 500 days out then increment the rollover count.

However the IRQ handler which updates it (‘TickOne’) is installed here, so if you were to set the value just before that bit of code then that would probably be good enough.

Thanks; will give that a go.

As long as they’re RISC OS 3.1 compatible, that’s fine.

The current version does run under 3.1, although it’ll probably crash and burn if you try to load it before CLib!

¹ But not when I was writing the actual code… I promise :)

The key with !System is to put your module in the folder that corresponds to the oldest OS version that the module will run on (although this does open up the possibility that an older version of the same module in a newer folder could block the newer version of the module from being seen; I haven’t checked but I’m assuming SysMerge / Installer deals with that)

Shouldn’t the OS look in the folder that corresponds to the OS revision and load the modules there, then thereafter look in lower and lower folders only loading modules it doesn’t already have.

Most modules get updated so that later versions of the module will work also on earlier hardware, hence would appear in ‘310.Modules’ and not in later ones like ‘520.Modules’. Some modules are only relevant to hardware that first appeared in later versions of RISC OS and so would not be relevant to earlier versions. Not sure whether there are any modules that have different versions in different ‘xxx.Modules’ directories?

Shouldn’t the OS look in the folder that corresponds to the OS revision and load the modules there, then thereafter look in lower and lower folders only loading modules it doesn’t already have.

It does so (or better: the module path that the boot structure creates leads to this behaviour). But that leads to exactly the problem Jeffrey described: if there is module A version 2.00 in folder 400, but also module A in folder 310 with a later version (say 2.50), version 2.00 gets loaded.

Hence SysMerge being your only hope to avoid that problem.