SYSPAGE_ENTRY(qtime)->cycles_per_sec problem

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.

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 :slight_smile:

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” :slight_smile:

Eduard

Murf

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 :slight_smile:

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 :slight_smile:

Eduard

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 > :slight_smile:

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” > :slight_smile:

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

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.