need technical help with the rtc

English Programming/Scripting
1

I just built a completely new system and it is fantastic or it should be.

It seems to be stable through all the stress tests I have tried but I recently ran the Firestrike test and that dam thing keeps saying my results are invalid because my rtc is skewing, indicating I am cheating or there is a hardware fault. Obviously I am not cheating. They say if I am not cheating and have an otherwise stable system, then send in various junk and their developers will analyse it for me. Sure, no doubt they mean well but how long will that take, in the meantime I have to decide if I am going to RMA the mobo.

The Firestrike test is a DX11 test that obviously only runs on Windoze and whilst I have no problem with the Futuremark company and developers, I never ever trust anything that WIndoze tells me. Ergo, their results are based on WIndoze so I do not trust them, especially when they validated one of my OC runs but reject the stock runs :\ There is also the possibility that there is something wrong inside Windoze 7 as Micro$oft have been rolling out easy upgrade steps to W7 to help idiots upgrade :sarcastic: to Windoze 8. Futuremark, the guys that create the Firestrike test have recently banned all WIndoze 8 computers from submitting test results to them due to a completely trashed rtc in Windoze 8 rotfl!

The Firestrike test uses some external software to gather timing information and that is where the problem actually lies. Either their code is wrong for this latest chipset on my ASUS mobo or there really is a hardware issue. ASUS have a hardware diagnostic program that specifically tests the rtc and that passes my hardware, including the rtc, as successful all the time.

However, I have noticed some dodgy handling of the systems sensors using hwmonitor. There appears to be a whole bunch of voltages and the cpu fan missing when I use hwmonitor but this is random as other times I use hwmonitor, the missing sensors are there.

So I would like to write some simplish code to test the RTC but although I know I can access the rtc, I am not sure what I can do to test it’s accuracy. I am a competent C/C++ developer and have been working on linux in a commercial environment for years, including messing about with the kernel and modules.

I just need a hint on what to do to test the rtc accuracy?

2

On 2014-09-17 13:26, back to suse wrote:

> I just need a hint on what to do to test the rtc accuracy?

What do you understand as the RTC?

Some people mean by that the CMOS clock that runs on a battery, keeps
time while the computer is powered down, and serves to initialize the
system clock when the machine boots.

But that clock has about one second precision, and reading it is slow.

And the kernel can update it periodically, thus changing it.

Then there is the system clock, kept by the operating system and the
cpu. Originally, there was a timer chip (also used for sound on the
board speakers) that generated about 17 interrupts per second, IIRC, and
the CPU just counted them. If the system was busy, it could miss some of
these.

Then other hardware timers were added with higher precision, and there
are several of them. But in the end, it is the CPU which somehow checks
those timers and updates an internal “clock”, which is no more than a
memory position to count, let’s call it “ticks”.

How exactly this is done, and what hardware is used (there are several
timers, some on the graphic card), depends on what hardware is available
on the motherboard, and what each operating system does with them… in
Linux you can force the kernel to use one or another.

For instance, one method was to supplement the old 18.2 Hz
timer, or later equivalents, with readings from other local
timers with perhaps higher precision, but which cycled, so
that the combination was precise and safe from missed interrupts.

And then you can be using a daemon such as NTP that gets a clock reading
from internet and then adjusts the local clock. And, in Linux, it can
change its frequency, speeding it up or down till it syncs with the
“reference”, and then adjusts that frequency so that it keeps exact
sync. But till it does, that frequency changes… I don’t know how this
is done in Windows.

So you see, I’m afraid that evaluating the system timer in Linux can
tell you about nothing regarding what happens in Windows…

But the kernel itself will tell you if it is flaky. Check the kernel
log, specially around boot time, and the ntp log if it is running.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

3

Thanks very much for the info.

I did mean the HPT but as you point out there is more than one timer, that may not be the one that the test is calling flaky.

Based on the test bench that claims the system timer is random and the fact that half my system sensors are awol most of the time, I guess I’ll just have to rma the mobo and hope the next one is better.

4

On 2014-09-19 09:06, back to suse wrote:
>
> Thanks very much for the info.
>
> I did mean the HPT but as you point out there is more than one timer,
> that may not be the one that the test is calling flaky.
>
> Based on the test bench that claims the system timer is random and the
> fact that half my system sensors are awol most of the time, I guess I’ll
> just have to rma the mobo and hope the next one is better.

Do a grep for HPT in the log. If the kernel finds a problem with it, it
will say so. But it is called HPET here, I understand.

Looking on my logs, I see:


> /var/log/warn-20110320.bz2:Nov  5 02:43:11 Telcontar kernel: [402192.639918] hpet1: lost 3 rtc interrupts
> /var/log/warn-20110320.bz2:Nov  5 02:43:13 Telcontar kernel: [402194.983306] hpet1: lost 3 rtc interrupts
> /var/log/warn-20110320.bz2:Nov  5 02:43:16 Telcontar kernel: [402197.326695] hpet1: lost 3 rtc interrupts
> /var/log/warn-20110320.bz2:Nov  5 02:44:12 Telcontar kernel: [402253.567931] hpet1: lost 4 rtc interrupts

That particular problem only happened that year – same board, so the
board was not at fault.

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)