We have a few machines running 6.1. Two of them, which are both
DigitalLogic 700MHz PIII single board computers, have system
clocks which are 1% slow, i.e. looses one second approx. every 100 seconds.
But in the BIOS-setup menu (entered during boot) the displayed clock seems accurate.
What might be he reason for the slow clocks? Should I look for OS or hardware problems?
Cheers / Tom
“Tomas Högström” <tomas@applied-sensorfusion.com> wrote in message
news:3D908C3A.C5A4F2F6@applied-sensorfusion.com…
We have a few machines running 6.1. Two of them, which are both
DigitalLogic 700MHz PIII single board computers, have system
clocks which are 1% slow, i.e. looses one second approx. every 100
seconds.
But in the BIOS-setup menu (entered during boot) the displayed clock seems
accurate.
What might be he reason for the slow clocks? Should I look for OS or
hardware problems?
Could be hardware problem as clock management is done via a interrupted
generated by a hardware timer.
Could also be software if something is disabling interrupt for longer then
two timer interrupts.
Cheers / Tom
I have killed most processes, and the problem remains. Now only running:
tinit, slogger, pci-bios, devb-eide, devc-con, fs-pkg, pipe, random, devc-pty,
dumper and login.
I booted Dynabolic Linux from CD, and there the clock is correct.
Cheers / Tom
Mario Charest wrote:
“Tomas Högström” <> tomas@applied-sensorfusion.com> > wrote in message
news:> 3D908C3A.C5A4F2F6@applied-sensorfusion.com> …
We have a few machines running 6.1. Two of them, which are both
DigitalLogic 700MHz PIII single board computers, have system
clocks which are 1% slow, i.e. looses one second approx. every 100
seconds.
But in the BIOS-setup menu (entered during boot) the displayed clock seems
accurate.
What might be he reason for the slow clocks? Should I look for OS or
hardware problems?Could be hardware problem as clock management is done via a interrupted
generated by a hardware timer.Could also be software if something is disabling interrupt for longer then
two timer interrupts.Cheers / Tom
postmaster@127.0.0.1 sed in <amqik8$ivk$1@inn.qnx.com>
Could be hardware problem as clock management is done via a interrupted
generated by a hardware timer.
Is there any adjustment available when the crystal is inherently off?
You may want to adjust the nanosec increment per interrupt
(“tick” kernel variable in other OS; tinkerable by tickadj NTP tool)
but Neutrino seems to assume that the crystal is correct.
(i.e the default tick rate is 999847 nsecs and nothing else)
Adjusting by ClockPeriod() adjusts tickrate AND tick simultaneously;
thus still assuming crystal is correct.
kabe
I can second that. We have PIII SBCs made by Motorola and time is
consistently slow by about 10-15 min per 24 hours. Solaris running on same
box does not have this issue.
– igor
“Tomas Högström” <tomas@applied-sensorfusion.com> wrote in message
news:3D91AA78.96119676@applied-sensorfusion.com…
I have killed most processes, and the problem remains. Now only running:
tinit, slogger, pci-bios, devb-eide, devc-con, fs-pkg, pipe, random,
devc-pty,
dumper and login.I booted Dynabolic Linux from CD, and there the clock is correct.
Cheers / Tom
Mario Charest wrote:
“Tomas Högström” <> tomas@applied-sensorfusion.com> > wrote in message
news:> 3D908C3A.C5A4F2F6@applied-sensorfusion.com> …
We have a few machines running 6.1. Two of them, which are both
DigitalLogic 700MHz PIII single board computers, have system
clocks which are 1% slow, i.e. looses one second approx. every 100
seconds.
But in the BIOS-setup menu (entered during boot) the displayed clock
seems
accurate.
What might be he reason for the slow clocks? Should I look for OS or
hardware problems?Could be hardware problem as clock management is done via a interrupted
generated by a hardware timer.Could also be software if something is disabling interrupt for longer
then
two timer interrupts.Cheers / Tom
kabe@sra-tohoku.co.jp wrote:
postmaster@127.0.0.1 sed in <amqik8$ivk$> 1@inn.qnx.com
Could be hardware problem as clock management is done via a interrupted
generated by a hardware timer.
Is there any adjustment available when the crystal is inherently off?You may want to adjust the nanosec increment per interrupt
(“tick” kernel variable in other OS; tinkerable by tickadj NTP tool)
but Neutrino seems to assume that the crystal is correct.
(i.e the default tick rate is 999847 nsecs and nothing else)Adjusting by ClockPeriod() adjusts tickrate AND tick simultaneously;
thus still assuming crystal is correct.And you can’t dig /dev/kmem to modify the “tick” cuz it’s microkernel.
Just a casual observation, but can’t you adjust the clock divisor with
the -f option to the startup-* program?
Rick Duff Internet: rick@astranetwork.com
Astra Network QUICS: rgduff
QNX Consulting and Custom Programming URL: http://www.astranetwork.com
+1 (204) 987-7475 Fax: +1 (204) 987-7479
Perhaps we can. The question is, why do we have to? Why Linux & Solaris
handle it fine?
“Rick Duff” <rick@astranetwork.com> wrote in message
news:3D931977.7060006@astranetwork.com…
kabe@sra-tohoku.co.jp > wrote:
postmaster@127.0.0.1 sed in <amqik8$ivk$> 1@inn.qnx.com
Could be hardware problem as clock management is done via a interrupted
generated by a hardware timer.
Is there any adjustment available when the crystal is inherently off?You may want to adjust the nanosec increment per interrupt
(“tick” kernel variable in other OS; tinkerable by tickadj NTP tool)
but Neutrino seems to assume that the crystal is correct.
(i.e the default tick rate is 999847 nsecs and nothing else)Adjusting by ClockPeriod() adjusts tickrate AND tick simultaneously;
thus still assuming crystal is correct.And you can’t dig /dev/kmem to modify the “tick” cuz it’s microkernel.
Just a casual observation, but can’t you adjust the clock divisor with
the -f option to the startup-* program?Rick…
Rick Duff Internet: > rick@astranetwork.com
Astra Network QUICS: rgduff
QNX Consulting and Custom Programming URL:
http://www.astranetwork.com
+1 (204) 987-7475 Fax: +1 (204) 987-7479
kovalenko@attbi.com sed in <amvl7j$ce9$1@inn.qnx.com>
“Rick Duff” <> rick@astranetwork.com> > wrote in message
Just a casual observation, but can’t you adjust the clock divisor with
the -f option to the startup-* program?Perhaps we can. The question is, why do we have to? Why Linux & Solaris
handle it fine?
Somebody who installed them may have tinkered with the
“tick” kernel variable so it’ll run better.
I didn’t know about startup-bios -f, so now I adjusted it to test
whether it’ll have any effect
(wait for least an hour to observe what ntpd says about it)
but getting the correct value for -f seems really obscure.
Is the default value -f 0,0,1193181.666 ?
kabe
Nobody did anything with kernel variables in our case. I did the
installation so I know.
kabe@sra-tohoku.co.jp wrote:
kovalenko@attbi.com > sed in <amvl7j$ce9$> 1@inn.qnx.com
“Rick Duff” <> rick@astranetwork.com> > wrote in message
Just a casual observation, but can’t you adjust the clock divisor with
the -f option to the startup-* program?Perhaps we can. The question is, why do we have to? Why Linux & Solaris
handle it fine?
Somebody who installed them may have tinkered with the
“tick” kernel variable so it’ll run better.I didn’t know about startup-bios -f, so now I adjusted it to test
whether it’ll have any effect
(wait for least an hour to observe what ntpd says about it)
but getting the correct value for -f seems really obscure.Is the default value -f 0,0,1193181.666 ?
If it’s settable only from startup-bios (not runtime configurable)
you have to prepare different /.boot for every installation having
different clock drift (bad)
Ditto. I didn’t even install Linux, I just ran it (Dynebolic Linux)
directly from the CD.
Igor Kovalenko wrote:
Nobody did anything with kernel variables in our case. I did the
installation so I know.
…
Somebody who installed them may have tinkered with the
“tick” kernel variable so it’ll run better.
…
Igor Kovalenko wrote:
Perhaps we can. The question is, why do we have to? Why Linux & Solaris
handle it fine?
If that is even the problem, the obvious answer is both Linux and
Solaris take the kitchen sink approach and have lots of code in them to
adjust for all sorts of occational problems. If what I suggested is the
solution (which I don’t know), it only forces the exception on the ppl
who need it, instead of everyone.
Rick…
–
Rick Duff Internet: rick@astranetwork.com
Astra Network QUICS: rgduff
QNX Consulting and Custom Programming URL: http://www.astranetwork.com
+1 (204) 987-7475 Fax: +1 (204) 987-7479
kabe@sra-tohoku.co.jp wrote:
kovalenko@attbi.com > sed in <amvl7j$ce9$> 1@inn.qnx.com
“Rick Duff” <> rick@astranetwork.com> > wrote in message
Just a casual observation, but can’t you adjust the clock divisor with
the -f option to the startup-* program?Perhaps we can. The question is, why do we have to? Why Linux & Solaris
handle it fine?
Somebody who installed them may have tinkered with the
“tick” kernel variable so it’ll run better.I didn’t know about startup-bios -f, so now I adjusted it to test
whether it’ll have any effect
(wait for least an hour to observe what ntpd says about it)
but getting the correct value for -f seems really obscure.Is the default value -f 0,0,1193181.666 ?
If it’s settable only from startup-bios (not runtime configurable)
you have to prepare different /.boot for every installation having
different clock drift (bad)
As I mentioned in my reply to igor, it was just pointing in a possible
direction. On the other hand, if you hardware has that much drift, get
new hardware (if it is an issue). The intention of this value is for
embedded board that chose a different crystal, not for correcting bad
hardware.
Rick Duff Internet: rick@astranetwork.com
Astra Network QUICS: rgduff
QNX Consulting and Custom Programming URL: http://www.astranetwork.com
+1 (204) 987-7475 Fax: +1 (204) 987-7479
Yes, that’s a good question. Based on that, I have tried both
“-f 0,0,1182323” and “-f 0,0,1182323.713” (0.9909*1193181.666)
which should hopefully set my clock rate right since it has 0.9909 of the correct speed,
but nothing much seems to happen.
SYSPAGE_ENTRY(qtime) is:
clock_cycles_per_second = 698653400, 698605100 (seems to vary for each boot)
timer_rate = 838095345
timer_load = 1193
Specifying “-f 0,0,1193182” I got
clock_cycles_per_second = 698645000
timer_rate = 838095345
timer_load = 1193
i.e. no 1% changes anywhere as I would expect. And clock is approx 1% too slow in both cases.
Am I missing something here?
Cheers / Tom
…
Is the default value -f 0,0,1193181.666 ?
…kabe
tomas@applied-sensorfusion.com sed in <3D9851CB.7FB426C1@applied-sensorfusion.com>
“-f 0,0,1182323” and “-f 0,0,1182323.713” (0.9909*1193181.666)
i.e. no 1% changes anywhere as I would expect. And clock is approx 1% too slow in both cases.
As Igor said (and I confirmed it also) that setting “setup-bios -f”
doesn’t seem to change SYSPAGE(qtime) at all.
In case the SYSPAGE is an illusion, I spent some time running ntpd on
different -f settings… doesn’t have much effect,
so at least -f doesn’t have any meaning on x86.
(it may have something useful on other platforms)
kabe
“Rick Duff” <rick@astranetwork.com> wrote in message
Igor Kovalenko wrote:
Perhaps we can. The question is, why do we have to? Why Linux & Solaris
handle it fine?If that is even the problem, the obvious answer is both Linux and
Solaris take the kitchen sink approach and have lots of code in them to
adjust for all sorts of occational problems. If what I suggested is the
I beg to differ. With nothing but crystal to get timer interrupt, the kernel
does not (and can not) know that the time is off or wrong. Thus, it cannot
make any on-the-fly or automatic corrections.
The problem here is something else… specific to QNX !
Regards
The OS could use the hardware RTC clock, couldn’t it?
But then, I don’t know how accurate that clock is.
I guess you’d to poll it to get good tick resolution?
Tom
Akhilesh Mritunjai wrote:
“Rick Duff” <> rick@astranetwork.com> > wrote in message
Igor Kovalenko wrote:Perhaps we can. The question is, why do we have to? Why Linux & Solaris
handle it fine?If that is even the problem, the obvious answer is both Linux and
Solaris take the kitchen sink approach and have lots of code in them to
adjust for all sorts of occational problems. If what I suggested is theI beg to differ. With nothing but crystal to get timer interrupt, the kernel
does not (and can not) know that the time is off or wrong. Thus, it cannot
make any on-the-fly or automatic corrections.
The problem here is something else… specific to QNX !Regards
- Akhilesh Mritunjai
We got it working finally. We gave the arguments -f 700,700,0 to
startup-bios (it’s 700MHz machines) and now the clock works fine.
Cheers / Tom
Tomas Högström wrote:
We got it working finally. We gave the arguments -f 700,700,0 to
startup-bios (it’s 700MHz machines) and now the clock works fine.
Rick Duff Internet: rick@astranetwork.com
Astra Network QUICS: rgduff
QNX Consulting and Custom Programming URL: http://www.astranetwork.com
+1 (204) 987-7475 Fax: +1 (204) 987-7479