# calcru: runtime went backwards



## ph0enix (Mar 15, 2009)

I'm seeing messages like this on the console.  What does it mean?


```
calcru: runtime went backwards from 54 usec to 43 usec for pid 758 (devd)
calcru: runtime went backwards from 136 usec to 109 usec for pid 349 (dhclient)
calcru: runtime went backwards from 504 usec to 401 usec for pid 333 (dhclient)
calcru: runtime went backwards from 11672 usec to 9293 usec for pid 333 (dhclient)
calcru: runtime went backwards from 196 usec to 156 usec for pid 179 (adjkerntz)
calcru: runtime went backwards from 755 usec to 601 usec for pid 21 (swi6: task queue)
calcru: runtime went backwards from 102 usec to 81 usec for pid 9 (thread taskq)
calcru: runtime went backwards from 1621 usec to 1291 usec for pid 19 (swi5: +)
calcru: runtime went backwards from 17 usec to 14 usec for pid 17 (swi1: net)
calcru: runtime went backwards from 16892 usec to 13878 usec for pid 0 (swapper)
```


----------



## DutchDaemon (Mar 15, 2009)

It means that your system time went back, confusing a number of applications. Do you use an NTP server (or a pool of NTP servers) that's unreliable? I've had messagers like these when I used the *.pool.ntp.org servers, some of which were grossly inaccurate.


----------



## ph0enix (Mar 15, 2009)

I'm not syncing the clock with time servers at all.  Do you have another idea?

Thanks!

J.


----------



## DutchDaemon (Mar 15, 2009)

I've seen suggestions to change the kern.timecounter value to either TSC or i8254. Try one or the other and see if that fixes the problem:

sysctl kern.timecounter.hardware=TSC *or*
sysctl kern.timecounter.hardware=i8254

If you're happy with either of them, put it in sysctl.conf(5).


----------



## trev (Mar 15, 2009)

Common enough problem, one solution to which is to set kern.hz in
your /boot/loader.conf file to something less than 1000. kern.hz="100" is usually recommended.


----------



## DutchDaemon (Mar 15, 2009)

http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#CALCRU-NEGATIVE-RUNTIME
http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#COMPUTER-CLOCK-SKEW


----------



## danger@ (Mar 16, 2009)

I have also seen in on some older FreeBSD releases before. What version are you running?


----------



## Carpetsmoker (Mar 18, 2009)

I have the same problem with FreeBSD 7 amd64 on my Dual Opteron 2xx system (Can't remember mainboard), the problem seems to occur if the NIC (bge driver) is used heavily or if the CPU is used heavily.
What mainboard/CPU are you using?

Using a different timecounter does not help, I haven't tried setting kern.hz to 100 yet, I'll try that.
I sort of gave up and was planning on installing OpenSolaris ...



> I have also seen in on some older FreeBSD releases before. What version are you running?



Yes, most of what I could find was for FreeBSD 5 ... Not a lot on FreeBSD 6 and 7.


----------



## ph0enix (Mar 19, 2009)

DutchDaemon said:
			
		

> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#CALCRU-NEGATIVE-RUNTIME
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/troubleshoot.html#COMPUTER-CLOCK-SKEW



Ah, disabling EIST in the BIOS did the trick! 

Thank you!

J.


----------



## ph0enix (Mar 19, 2009)

Carpetsmoker said:
			
		

> I have the same problem with FreeBSD 7 amd64 on my Dual Opteron 2xx system (Can't remember mainboard), the problem seems to occur if the NIC (bge driver) is used heavily or if the CPU is used heavily.
> What mainboard/CPU are you using?
> 
> Using a different timecounter does not help, I haven't tried setting kern.hz to 100 yet, I'll try that.
> ...



AMD processors have a similar feature to EIST (Speedstep) built into them (forgot what it's called).  See if you can disable it in the BIOS.  EIST basically lowers the CPU's multiplier (and subsequently its operating frequency) when not under heavy load to save power.

It looks like FreeBSD isn't dealing well with the change in frequencies.


----------



## fronclynne (Mar 20, 2009)

*Well, I noticed a death, but it was on TV*



			
				ph0enix said:
			
		

> It looks like FreeBSD isn't dealing well with the change in frequencies.


Purely out of curiosity, are there any effects besides the messages?  I've seen them plenty of times and never noticed any deaths or maimings.


----------



## Carpetsmoker (Mar 20, 2009)

fronclynne said:
			
		

> Purely out of curiosity, are there any effects besides the messages?  I've seen them plenty of times and never noticed any deaths or maimings.



In my case, it freezes the system, sometimes it comes out of the freeze after some times, sometimes not.


----------



## ph0enix (Mar 21, 2009)

fronclynne said:
			
		

> Purely out of curiosity, are there any effects besides the messages?  I've seen them plenty of times and never noticed any deaths or maimings.



No, I didn't notice any special effects.


----------



## ph0enix (Mar 21, 2009)

FYI:
I just noticed these since disabling EIST:

CPU: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz (3006.83-MHz K8-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
cpu0: <ACPI CPU> on acpi0
est: CPU supports Enhanced Speedstep, but is not recognized.
p4tcc0: <CPU Frequency Thermal Control> on cpu0
cpu1: <ACPI CPU> on acpi0
est: CPU supports Enhanced Speedstep, but is not recognized.
p4tcc1: <CPU Frequency Thermal Control> on cpu1
cpu2: <ACPI CPU> on acpi0
est: CPU supports Enhanced Speedstep, but is not recognized.
p4tcc2: <CPU Frequency Thermal Control> on cpu2
cpu3: <ACPI CPU> on acpi0
est: CPU supports Enhanced Speedstep, but is not recognized.
p4tcc3: <CPU Frequency Thermal Control> on cpu3

...I'm not sure if it hurts anything


----------



## Carpetsmoker (Mar 28, 2009)

There's no option to disable EIST, no mention of it in dmesg ... I suspect my mainboard doesn't even support this feature.

I set kern.hz="100", so far it *seems* to have solved the problem, but more extensive testing is required to be 100% sure.


What does kern.hz actually do? And why did it (probably) fix my problem?


----------



## Alpinweis (Apr 2, 2009)

I am running FreeBSD 7.1 x64 (amd) under VMWare.
I have set kern.hz=100, set BIOS to GMT (there are no other otpions in BIOS to configure) and I still have this problem.

What else can I try?


----------



## Beastie (Apr 3, 2009)

Alpinweis said:
			
		

> What else can I try?


Did you first try to add *debug.acpi.disabled="timer"* to */etc/loader.conf* as suggested DutchDaemon's second link?




			
				Carpetsmoker said:
			
		

> What does kern.hz actually do?


I guess it's either the PIT or the ACPI. The PIT is usually used to manage timeslices for multitasking (i.e. the PIT is interrupting the CPU 1000 times every second).

But I think FreeBSD uses APIC for SMP and it seems there are problem with it.

I can't understand why FreeBSD uses 1000Hz by default. AFAIK, most OS use 100Hz.


----------



## richardpl (Apr 4, 2009)

Beastie said:
			
		

> I can't understand why FreeBSD uses 1000Hz by default. AFAIK, most OS use 100Hz.



It decreases general latency, and on cheap desktop sort of hardware it may be problematic.


----------



## trev (Apr 11, 2009)

Carpetsmoker said:
			
		

> I set kern.hz="100", so far it *seems* to have solved the problem, but more extensive testing is required to be 100% sure.



Great... thanks for confirming it's one of the possible fixes for future victims.


----------



## mathuin (Apr 11, 2009)

I have kern.hz set to 100 but it doesn't fix the problem on my Asus EEE PC 1000 laptop.  I also tried the other time sources to no avail.


----------



## trev (Apr 11, 2009)

Strange - my ASUS EEEPC 701 netbook doesn't have any issues with FreeBSD 7.1-STABLE i386.


----------



## fronclynne (Apr 11, 2009)

*I'll show you a hardcoded maximum*

Back in the days of the amd k6-iii[1], my experience was that about one third of the boards (sample size was about 6, though, so don't try to read any narrow trends into this) would give this error message, no matter what kern.hz was set to[2].  At least one never gave the error, and the final portion would cease (or almost never[3]) at around kern.hz=250.

I attribute at least some of the problem to flaky clocks, for which there seem[ed|s] to be no real cure.


[1] Actually somewhat after, since I got a pile of them second-hand for nothing

[2] Truth be told, I never tried values < 100, which makes me wonder if there's a hardcoded minimum or maximum . . .

[3] Maybe once or twice when building world at -j2


----------



## mathuin (Apr 12, 2009)

trev said:
			
		

> Strange - my ASUS EEEPC 701 netbook doesn't have any issues with FreeBSD 7.1-STABLE i386.



My Asus EEE PC 701 has no problems with 7.1-STABLE either, but my 1000 with 8.0-CURRENT does.


----------



## Carpetsmoker (Jul 23, 2009)

> I set kern.hz="100", so far it *seems* to have solved the problem, but more extensive testing is required to be 100% sure.



It helped a bit, the system didn't freeze as often, but didn't fix the problem after all.
Reinstalling the system with i386 ``solved'' the problem though ...


----------



## chadbishop (Nov 23, 2009)

running freebsd 8 rc3 in microsoft hyperv. i had the same problems as described. setting the following worked for me.
`# sysctl kern.timecounter.hardware=TSC`


----------



## Juanitou (Feb 28, 2013)

Carpetsmoker said:
			
		

> Reinstalling the system with i386 ``solved'' the problem though ...



That's an old thread, but for what is worth, I started seeing those calcru messages when I upgraded from 9.0 to 9.1-RELEASE amd64. They appeared after suspend/restart cycles. I tried all the proposed solutions without success, then I reinstalled the system with i386 (trying to resolve issues with ATI drivers and/or Wine, but that's another story) and I've never seen them again.

I hope it gives an indication of where the problem can be.

Best regards,
Juan


----------



## haimat (May 24, 2013)

I have exactly the same problem on my 9.1 based machine running in a KVM environment. I tried all of the things mentioned in this thread:

`sysctl kern.timecounter.hardware=i8254`
`sysctl kern.timecounter.hardware=TSC` (not possible, not supported by my hardware)


```
kern.hz="100"
```
 in /boot/loader.conf


```
debug.acpi.disabled="timer"
```
 in /boot/loader.conf
Other NTP servers
None of these helped. Installing the whole server is not really an option. Any other ideas, maybe KVM-related? I am out of ideas here


----------



## oz42 (Jul 11, 2013)

I think it is KVM related. I am running 9.1 i386 on KVM and still see that every now and then.


----------

