SYSPAGE_ENTRY(qtime)->cycles_per_sec problem

bridged with qdn.public.qnxrtp.x86
David Gibbs

Re: SYSPAGE_ENTRY(qtime)->cycles_per_sec problem

Post by David Gibbs » Mon Sep 08, 2003 9:46 pm

ed1k <ed1k@humber.bay> wrote:
In article <bhu4ir$79q$1@nntp.qnx.com>, dagibbs@qnx.com says...

Hi David,

Could you share with us the algorithm of calculating that cycles_per_sec
entry during startup?
Its shipped with (at least) Momentics PE.

On a self-hosted system, take a look at:

/usr/src/bsp-6.2.1/libs/src/hardware/startup/lib/x86/set_cycles.c

If not self-hosted, prefix the above with $(QNX_TARGET), I think.

In fact, if you have a better algorithm for your system(s)... you could
just build yourself a new startup, using your version of set_cycles.c
rather than the standard one, and all your machines will now have a
better value for cycles_per_sec.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

John Halpenny

Re: SYSPAGE_ENTRY(qtime)->cycles_per_sec problem

Post by John Halpenny » Mon Sep 08, 2003 10:32 pm

David Gibbs wrote:
ed1k <ed1k@humber.bay> wrote:
In article <bhu4ir$79q$1@nntp.qnx.com>, dagibbs@qnx.com says...

Hi David,

Could you share with us the algorithm of calculating that cycles_per_sec
entry during startup?

Its shipped with (at least) Momentics PE.

On a self-hosted system, take a look at:

/usr/src/bsp-6.2.1/libs/src/hardware/startup/lib/x86/set_cycles.c

If not self-hosted, prefix the above with $(QNX_TARGET), I think.

In fact, if you have a better algorithm for your system(s)... you could
just build yourself a new startup, using your version of set_cycles.c
rather than the standard one, and all your machines will now have a
better value for cycles_per_sec.

-David
Could you have the option for a fixed value to be entered from something like
the sysinit file. Each computer should have a fairly stable value once you
calibrate it.

John Halpenny

ed1k

Re: SYSPAGE_ENTRY(qtime)->cycles_per_sec problem

Post by ed1k » Tue Sep 09, 2003 10:49 pm

In article <3F5D037D.58CDF89B@rogers.com>, j.halpenny@rogers.com says...

David Gibbs wrote:

ed1k <ed1k@humber.bay> wrote:
In article <bhu4ir$79q$1@nntp.qnx.com>, dagibbs@qnx.com says...

Hi David,

Could you share with us the algorithm of calculating that cycles_per_sec
entry during startup?

Its shipped with (at least) Momentics PE.

On a self-hosted system, take a look at:

/usr/src/bsp-6.2.1/libs/src/hardware/startup/lib/x86/set_cycles.c

If not self-hosted, prefix the above with $(QNX_TARGET), I think.

In fact, if you have a better algorithm for your system(s)... you could
just build yourself a new startup, using your version of set_cycles.c
rather than the standard one, and all your machines will now have a
better value for cycles_per_sec.

-David

Could you have the option for a fixed value to be entered from something like
the sysinit file. Each computer should have a fairly stable value once you
calibrate it.
Take a look at startup-bios -f. Once you have calibrated value you can build special image for your
computer :)

Eduard.

John Halpenny

ed1k

Re: SYSPAGE_ENTRY(qtime)->cycles_per_sec problem

Post by ed1k » Wed Sep 10, 2003 4:34 am

In article <bjitbk$i36$1@nntp.qnx.com>, dagibbs@qnx.com says...
ed1k <ed1k@humber.bay> wrote:
In article <bhu4ir$79q$1@nntp.qnx.com>, dagibbs@qnx.com says...

Hi David,

Could you share with us the algorithm of calculating that cycles_per_sec
entry during startup?

Its shipped with (at least) Momentics PE.

On a self-hosted system, take a look at:

/usr/src/bsp-6.2.1/libs/src/hardware/startup/lib/x86/set_cycles.c

If not self-hosted, prefix the above with $(QNX_TARGET), I think.
Thank you.
In fact, if you have a better algorithm for your system(s)...
No, I don't. My algorithm isn't better and definitely it isn't for start-up. And my goal was just
check out what's wrong with standard one (which is used now in QNX). Start-up time is better for
such a task as CPU speed measurement than the same measurement in working multi-task system, so your
algorithm should be better. But in fact, my algorithm gives me result much closer to result of other
benchmark tools...

Algorithm which I used has some advantages: it takes long time in order to get 100 (it could be
extended) measurements and make some statistical processing of result. Also it has a lot of
disanvatnages:
1) it takes long time;
2) it uses float point arithmetic;
3) it has precission limitation of method. I use periodical interrupts to get state of CPU free-
running counter. That means, after RTC chip rise up an interrupt request, there is some time before
rdtsc instruction executed in ISR - interrupt latency. RTC interrupt isn't high priority interrupt,
and generally speaking, interrupt latency could vary from time to time. That fact that I have so
small dispersion of results, indirectly says that interrupt latency in QNX doesn't vary much (it's
also good to know, though it doesn't say this latency is small or big :))
you could
just build yourself a new startup, using your version of set_cycles.c
rather than the standard one, and all your machines will now have a
better value for cycles_per_sec.
Yes, I could. Why QSSL doesn't want it too? Then all our machines (x86 at least) will have a better
value for cycles_per_sec. In file init_qtime.c, there is defined period of 8254 clock:
#define PC_CLOCK_RATE 838095345UL
And this is used to calculated another PC related constant, in set_cycles.c, when we need to know
how many ticks of 8254 are in 0.01s period. The problem is it's calculated by integer arithmetic,
and result is 11933. I don't understand why you need to calculate it rather than just
#define PC_TICKS_IN_10MS 11932
It looks like not a big error, big deal 11933 instead of 11932, but
11933 * 0.838095345 us = 10000.992 us, i.e. error is almost 1 us.
My slow CPU makes extra 347 cycles in that extra 0.992 us, and because we have to multiply result by
100 (we took 0.01s period but need cycles_per_sec) it is 34700 Hz difference. This is exactly what I
saw as offset error in my experiments.

For now,
systematic error (Hz) = Fcpu (MHz) * 99.2
so, the faster CPU the bigger error.
And it isn't error because of hardware limitation.

Cheers,
Eduard

John A. Murphy

Re: SYSPAGE_ENTRY(qtime)->cycles_per_sec problem

Post by John A. Murphy » Wed Sep 10, 2003 2:51 pm

ed1k wrote:
In article <bjitbk$i36$1@nntp.qnx.com>, dagibbs@qnx.com says...
ed1k <ed1k@humber.bay> wrote:
In article <bhu4ir$79q$1@nntp.qnx.com>, dagibbs@qnx.com says...

Hi David,

Could you share with us the algorithm of calculating that cycles_per_sec
entry during startup?

Its shipped with (at least) Momentics PE.

On a self-hosted system, take a look at:

/usr/src/bsp-6.2.1/libs/src/hardware/startup/lib/x86/set_cycles.c

If not self-hosted, prefix the above with $(QNX_TARGET), I think.


Thank you.

In fact, if you have a better algorithm for your system(s)...

No, I don't. My algorithm isn't better and definitely it isn't for start-up. And my goal was just
check out what's wrong with standard one (which is used now in QNX). Start-up time is better for
such a task as CPU speed measurement than the same measurement in working multi-task system, so your
algorithm should be better. But in fact, my algorithm gives me result much closer to result of other
benchmark tools...

Algorithm which I used has some advantages: it takes long time in order to get 100 (it could be
extended) measurements and make some statistical processing of result. Also it has a lot of
disanvatnages:
1) it takes long time;
2) it uses float point arithmetic;
3) it has precission limitation of method. I use periodical interrupts to get state of CPU free-
running counter. That means, after RTC chip rise up an interrupt request, there is some time before
rdtsc instruction executed in ISR - interrupt latency. RTC interrupt isn't high priority interrupt,
and generally speaking, interrupt latency could vary from time to time. That fact that I have so
small dispersion of results, indirectly says that interrupt latency in QNX doesn't vary much (it's
also good to know, though it doesn't say this latency is small or big :))

you could
just build yourself a new startup, using your version of set_cycles.c
rather than the standard one, and all your machines will now have a
better value for cycles_per_sec.

Yes, I could. Why QSSL doesn't want it too? Then all our machines (x86 at least) will have a better
value for cycles_per_sec. In file init_qtime.c, there is defined period of 8254 clock:
#define PC_CLOCK_RATE 838095345UL
And this is used to calculated another PC related constant, in set_cycles.c, when we need to know
how many ticks of 8254 are in 0.01s period. The problem is it's calculated by integer arithmetic,
and result is 11933. I don't understand why you need to calculate it rather than just
#define PC_TICKS_IN_10MS 11932
It looks like not a big error, big deal 11933 instead of 11932, but
11933 * 0.838095345 us = 10000.992 us, i.e. error is almost 1 us.
My slow CPU makes extra 347 cycles in that extra 0.992 us, and because we have to multiply result by
100 (we took 0.01s period but need cycles_per_sec) it is 34700 Hz difference. This is exactly what I
saw as offset error in my experiments.

For now,
systematic error (Hz) = Fcpu (MHz) * 99.2
so, the faster CPU the bigger error.
And it isn't error because of hardware limitation.

Cheers,
Eduard
Don't forget that the magic number of 838095345UL assumes a crystal
that's exactly on frequency. The "error" introduced by the integer
arithmetic is on the order of 84 parts per million; the crystal
frequency can easily be off by several times that amount. So the
"error" you attribute to the OS is still small with respect to the
hardware limitation.

Murf

David Gibbs

Re: SYSPAGE_ENTRY(qtime)->cycles_per_sec problem

Post by David Gibbs » Wed Sep 10, 2003 4:15 pm

ed1k <ed1k@humber.bay> wrote:
Yes, I could. Why QSSL doesn't want it too?
The reason I didn't say we wanted it, was because I noticed (and you
noted as well) that your method took a lot longer to get the right
value. I was suggesting that if you wanted to make the time spent
vs accuracy trade-off in your startups, you might want to, but that
it wasn't neccessarily a general trade-off that we wanted to ship
as default.
Then all our machines (x86 at least) will have a better
value for cycles_per_sec. In file init_qtime.c, there is defined period
of 8254 clock: #define PC_CLOCK_RATE 838095345UL
And this is used to calculated another PC related constant,
in set_cycles.c, when we need to know how many ticks of 8254 are
in 0.01s period. The problem is it's calculated by integer arithmetic,
and result is 11933. I don't understand why you need to calculate it
rather than just #define PC_TICKS_IN_10MS 11932
It is probably calculated to make that general-purpose code, so that
it can be re-used on other platforms as well -- where the result will
not be 11933 (11932).
It looks like not a big error, big deal 11933 instead of 11932, but
11933 * 0.838095345 us = 10000.992 us, i.e. error is almost 1 us.
Hm... I thought we would have calculated 11932 -- I thought we chose
the value just under what we needed, not just over. I may have to
wander over and talk to someone about this.
My slow CPU makes extra 347 cycles in that extra 0.992 us, and
because we have to multiply result by
100 (we took 0.01s period but need cycles_per_sec) it is 34700 Hz difference.
This is exactly what I saw as offset error in my experiments.
Hm...even if we use 11933 (instead of 11932), we may want to update this
algorithm to properly account for the actual value, rather than the
assumed value.
For now,
systematic error (Hz) = Fcpu (MHz) * 99.2
so, the faster CPU the bigger error.
And it isn't error because of hardware limitation.
Apparently not.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

ed1k

Re: SYSPAGE_ENTRY(qtime)->cycles_per_sec problem

Post by ed1k » Wed Sep 10, 2003 6:36 pm

In article <3F5F3A8A.CEF1B37F@perftech.com>, murf@perftech.com says...
Don't forget that the magic number of 838095345UL assumes a crystal
that's exactly on frequency.
Yes, it's period of frequency 1.1931816(6) MHz
The "error" introduced by the integer
arithmetic is on the order of 84 parts per million; the crystal
frequency can easily be off by several times that amount.
If I got you right, you're saying the quartz oscillator gives frequency stability worse than 10**(-
4)? Fortunately, it's not the case. If you connect frequency meter to quartz oscillator you have to
see 1.19318xxxx(xxxx - any digits here). If you see any of the first 6 digits changing that means
your quartz is not in resonance, in other words your engineers built a LC oscillator (it's even
possible with using quartz resonator too) and pose it as quartz oscillator.

To make that 8254 frequency more precise, many modern computers use quartz oscillator with few times
higher frequency. For example, 82371AB (PIIX4) chip uses 14.31818 MHz quartz oscillator and divide
this frequency by 12. Keep in mind, quartz resonators in this frequency range are usually resonators
of first harmonica, it is not hundreds megahertz where resonators are 3rd-, 5th-, 9th- harmonica
solutions with a litle bit worse stability of frequncy.

And by putting quartz oscillator into thermostat you're able to get frequency stability yet more
better, but this is comletely off-topic here :)
So the
"error" you attribute to the OS is still small with respect to the
hardware limitation.
Nope, sorry. I'd love work for you as an electronic engineer, BTW. You're so easy on "hardware
limitation" :)

Eduard
Murf

ed1k

Re: SYSPAGE_ENTRY(qtime)->cycles_per_sec problem

Post by ed1k » Wed Sep 10, 2003 8:06 pm

In article <bjnini$9a2$1@nntp.qnx.com>, dagibbs@qnx.com says...
It is probably calculated to make that general-purpose code, so that
it can be re-used on other platforms as well -- where the result will
not be 11933 (11932).
That code is used on x86 platforms and only if x86 is pentium, i.e. supports rdtsc instruction :)
It looks like not a big error, big deal 11933 instead of 11932, but
11933 * 0.838095345 us = 10000.992 us, i.e. error is almost 1 us.

Hm... I thought we would have calculated 11932 -- I thought we chose
the value just under what we needed, not just over. I may have to
wander over and talk to someone about this.

My slow CPU makes extra 347 cycles in that extra 0.992 us, and
because we have to multiply result by
100 (we took 0.01s period but need cycles_per_sec) it is 34700 Hz difference.
This is exactly what I saw as offset error in my experiments.

Hm...even if we use 11933 (instead of 11932), we may want to update this
algorithm to properly account for the actual value, rather than the
assumed value.
You might consider other method. Instead of reading free-running counter between 0.01s time period,
you could read that counter between 1000 ticks of 8254. Than

cycles_per_sec = (RDTSCstart - RDTSCend) * 1000000000 / timer_ticks2ns(1000)

timer_ticks2ns(1) returns 838 and I guess in current design timer_tick2ns(1000) will return 838000
instead of 838095, so

cycles_per_sec = (RDTSCstart - RDTSCend) * 1000000 / timer_ticks2ns(1)

I believe it will give more precision result even now. But might be not, because timer_ticks2ns() is
really tricky now :)

Eduard

John A. Murphy

Re: SYSPAGE_ENTRY(qtime)->cycles_per_sec problem

Post by John A. Murphy » Wed Sep 10, 2003 8:57 pm

ed1k wrote:
In article <3F5F3A8A.CEF1B37F@perftech.com>, murf@perftech.com says...

Don't forget that the magic number of 838095345UL assumes a crystal
that's exactly on frequency.

Yes, it's period of frequency 1.1931816(6) MHz

The "error" introduced by the integer
arithmetic is on the order of 84 parts per million; the crystal
frequency can easily be off by several times that amount.

If I got you right, you're saying the quartz oscillator gives frequency stability worse than 10**(-
4)? Fortunately, it's not the case. If you connect frequency meter to quartz oscillator you have to
see 1.19318xxxx(xxxx - any digits here). If you see any of the first 6 digits changing that means
your quartz is not in resonance, in other words your engineers built a LC oscillator (it's even
possible with using quartz resonator too) and pose it as quartz oscillator.

To make that 8254 frequency more precise, many modern computers use quartz oscillator with few times
higher frequency. For example, 82371AB (PIIX4) chip uses 14.31818 MHz quartz oscillator and divide
this frequency by 12. Keep in mind, quartz resonators in this frequency range are usually resonators
of first harmonica, it is not hundreds megahertz where resonators are 3rd-, 5th-, 9th- harmonica
solutions with a litle bit worse stability of frequncy.

And by putting quartz oscillator into thermostat you're able to get frequency stability yet more
better, but this is comletely off-topic here :)

So the
"error" you attribute to the OS is still small with respect to the
hardware limitation.

Nope, sorry. I'd love work for you as an electronic engineer, BTW. You're so easy on "hardware
limitation" :)

Eduard

Murf


Well, I've spent many years as both an electronic engineer and a
software engineer, and I can guarantee you that you're dreaming if you
think you're going to find 10 ppm oscillators in PC's. And of course
dividing a higher frequency down to a lower one has absolutely no effect
on accuracy - that's the kind of reasoning you hear on the commercials
for digital watches. The last time I tried to get a PC manufacturer to
guarantee a clock tolerance, ANY tolerance, I was bluntly informed that
that simply isn't part of anybody's specification for what constitutes a
personal computer; no matter how far off from 1.1931816 MHz it may be,
it's not a reason to complain to the manufacturer.

Being off frequency in no way suggests that the oscillator isn't being
controlled by the crystal; it simply means (in most cases) that the
crystal was never ground to the correct frequency in the first place.
Controlling a computer's clock frequency is not considered a high
precision application, and high quality, temperature compensated
oscillators, trimmed to the exact frequency, would be a waste of money.
Likewise, to assume that such hardware was commonly available and design
software to make the most of it would be a waste of effort on the part
of operating system suppliers.

I think a fundamental problem in this whole thread is a mixing of the
terms accuracy and stability. Even the cheap crystals used in PC's may
have reasonable stability (depending on how you define "reasonable"),
but their accuracy isn't likely to be anywhere near 10 ppm; in other
words, they may continue to oscillate for long periods of time at the
same wrong frequency. The good folks at QSSL have provided us with
software that is more than adequate for the hardware it is designed to
support. If you really need more accuracy, you should be looking for
specialized hardware and supplying your own software for it.

Murf

ed1k

Re: SYSPAGE_ENTRY(qtime)->cycles_per_sec problem

Post by ed1k » Fri Sep 12, 2003 1:39 am

In article <3F5F9027.5D3C66DE@perftech.com>, murf@perftech.com says...
Well, I've spent many years as both an electronic engineer and a
software engineer, and I can guarantee you that you're dreaming if you
think you're going to find 10 ppm oscillators in PC's. And of course
dividing a higher frequency down to a lower one has absolutely no effect
on accuracy - that's the kind of reasoning you hear on the commercials
for digital watches. The last time I tried to get a PC manufacturer to
guarantee a clock tolerance, ANY tolerance, I was bluntly informed that
that simply isn't part of anybody's specification for what constitutes a
personal computer; no matter how far off from 1.1931816 MHz it may be,
it's not a reason to complain to the manufacturer.

Being off frequency in no way suggests that the oscillator isn't being
controlled by the crystal; it simply means (in most cases) that the
crystal was never ground to the correct frequency in the first place.
Controlling a computer's clock frequency is not considered a high
precision application, and high quality, temperature compensated
oscillators, trimmed to the exact frequency, would be a waste of money.
Likewise, to assume that such hardware was commonly available and design
software to make the most of it would be a waste of effort on the part
of operating system suppliers.

I think a fundamental problem in this whole thread is a mixing of the
terms accuracy and stability. Even the cheap crystals used in PC's may
have reasonable stability (depending on how you define "reasonable"),
but their accuracy isn't likely to be anywhere near 10 ppm; in other
words, they may continue to oscillate for long periods of time at the
same wrong frequency. The good folks at QSSL have provided us with
software that is more than adequate for the hardware it is designed to
support. If you really need more accuracy, you should be looking for
specialized hardware and supplying your own software for it.

Murf

OK, I've also spent couple of years working as electronic and software engineer simultaneously. I'm
sorry, I don't know what commercial you are speaking about, my education and experience isn't based
on commercials. In addition to heartbeats for digital electronics I also dealt with oscillators and
frequency synthesizers for receivers. Thank you for bringing clearness into this thread, I mean
terms accuracy and stability. Dividing a higher frequency down to a lower one has absolutely no
effect on *stability*, i.e. relative error
err = (Freal - Fnom)/Fnom
will be the same. But it affects absolute error (accuracy).
Let's take a look at oscillator with a quartz that was not ground accurately to nominal frequency.
Let's say we can trust only to 3 digits after point, i.e. f=14.318 MHz. Now, after dividing, it's
obviously, we can trust to 4 digits after point, i.e. we have f=1.1931 MHz.
Returning to original subject of the thread, even if we have 8254 chip clocked with f=1.1931000 MHz,
the error isn't more than 1 us in 0.01 s interval.

Speaking about x86 hardware, being in Ukraine, I measured frequencies on few suspicious NONAME
boards manufactured somewhere in Pacific-Asian region. They provide quite accurate and stable
frequencies. Yesterday I spent some time to measure frequency on my old IBM 300 GL, as you see it is
not special computer, I bought refurbished one in some junk store here, in Toronto. It has perfectly
accurate frequency. Generally speaking, there is no monopoly in x86 field. If you are not satisfied
with some board you can choose another manufacturer.

I never said folks at QSSL did a bad job. If they did a bad job and created a bad OS, I wouldn't be
here, at QNX newsgroups. But if there is something that can be done to increase accuracy even on
theoreticaly accurate system I don't see any harm to do so. It won't give worse result on real
(inaccurate) system. Quite the contrary, returning to the subject of the thread, if you have
absolute accurate system and assigned there are 11933 ticks in 0.01 s, it gives you error 0.992us.
If you have real system with real frequency of 8254 chip, say f=1.19310 MHz, you will get error
1.676us. Chance that inaccuracy of oscillator (a little higher frequency) will compensate error of
chosen constant is not big at all. In real life, thing are going to compose in such a way to give
you a worst case.

Cheers,
Eduard.

Post Reply

Return to “qdn.public.qnxrtp.x86”