[FreeBSD] Tijd loopt achterstevoren?

[Verwijderd]

Ik heb net FreeBSD 5.3 geinstalleerd op 2 wat oudere PC's omdat ik wel eens proberen hoe ik nou met rsync een Load-Balacing setup kan maken. Nou geeft alleen één van de twee pc's een hele vreemde fout:

code:

calcru: negative runtime of -67812 usec for pid 8064 (awk)

en dit dan voor bijna alle processen die hij uitvoert (en bij het builden van een kernel zijn dat heel wat ), dus alsof de tijd achterstevoren loopt. (Dit doet hij overigens al sinds de eerste boot na de installatie)

Het systeem waar dit op gebeurt heeft een Intel Celeron 466 Mhz, het andere systeem dat geen problemen heeft, heeft een Intel Pentium III 450 Mhz. Ze hebben allebei 192 MB geheugen. Voor de rest zijn het 2 kale systemen. (Minimal installation, met alleen compat4x, man, src->sys, ports geinstalleerd). Nou heb ik eerder al FreeBSD 4.10/4.11 erop geinstalleerd zonder problemen, maar ik zou toch graag willen weten of dit op te lossen is, en waar dit aan ligt. Iemand een idee?

[M-ThijZ]

Sorry, ik heb geen enkel idee hoe ik je probleem moet oplossen, maar na het zien van je topictitel kwam dit toch als eerste bij me op:

[Soultaker]

Misschien biedt de manual soelaas?

Why does my machine print ``calcru: negative time...''?

This can be caused by various hardware or software ailments relating to interrupts. It may be due to bugs but can also happen by nature of certain devices. Running TCP/IP over the parallel port using a large MTU is one good way to provoke this problem. Graphics accelerators can also get you here, in which case you should check the interrupt setting of the card first.

A side effect of this problem are dying processes with the message ``SIGXCPU exceeded cpu time limit''.

For FreeBSD 3.0 and later from Nov 29, 1998 forward: If the problem cannot be fixed otherwise the solution is to set this sysctl variable:

code:

# sysctl -w kern.timecounter.method=1

Note: The -w option of sysctl( is deprecated and silently ignored in FreeBSD 4.4-RELEASE and all newer versions. You can safely ommit it when setting options with sysctl as shown above.

This means a performance impact, but considering the cause of this problem, you probably will not notice. If the problem persists, keep the sysctl set to one and set the NTIMECOUNTER option in your kernel to increasingly large values. If by the time you have reached NTIMECOUNTER=20 the problem is not solved, interrupts are too hosed on your machine for reliable time keeping.

[Verwijderd]

Ook zou je op beide systemen een ntp daemon kunnen installen, die beide dezelfde stratum 1 masters hebben en peer van mekaar zijn. Da's ook een mooie manier om de tijd synchroon te houden op beide systemen.

[Verwijderd]

Ik heb even de dmesg.boot nog eens goed afgezocht en zag dat er een ACPI error bij stond, toen ik ACPI helemaal had uitgeschakeld (dmv hint.acpi.0.disabled=1 in /boot/loader.conf) werkte het prima maar bedankt voor jullie tips (en erg vreemd dat het aan de ACPI ligt imo, dit zou toch niks met de tijd te maken moeten hebben?)

[GrooV]

This can be caused by various hardware or software ailments relating to interrupts. It may be due to bugs but can also happen by nature of certain devices