Current Time in an interrupt handler?--continue

Accidentally,I find this topic.“Current Time in an interrupt handler?”
I am interested with this topic ,because my program needs “Current Time in
an interrupt handler” too.
So I want to continue discussing.

I see someone write:

“Brown, Richard” <brownr@aecl.ca> wrote in message
news:a4j4fs$59b$1@inn.qnx.com

Our policy is to timestamp data at the time of reception. So if we have
data
being gathered via an ISR we would like to timestamp that data as close to
the actual time it was obtained. If we wait until outside the ISR then we
could potentially be preempted and the accuracy of the timestamping would
be
lost.
Reading the safety notes on clock_gettime I see that its not interrupt
safe.
Could one wrap this function around calls to disable/enable interrupts to
make it interrupt safe? What exactly does interrupt safe mean for this
function?

“Mario Charest” <goto@nothingness.com>
wrote in message news:a4j5nj$5v4$1@inn.qnx.com

You could use ClockCycles() if processor is Pentium or above.
That 's VERY precise, down to the CPU clock frequency.
or
SYSPAGE_ENTRY(qtime)->nsec (resolution is the ticksize)

Up to now,I haven’t found a appropriate method to get current time in an
interrupt handler,

I have seen the doc about ClockCycles().As if it is not Current “time”,but
current value of a free-running 64-bit cycle counter.
To the SYSPAGE_ENTRY(qtime)->nsec (resolution is the ticksize),I don’t know
what the concept " ticksize".

In a word ,whether I need some convert the ClockCycles() or
SYSPAGE_ENTRY(qtime)->nsec to get current time.
The time accurate I wish is at least-“1us” .How could I do?
or is there other method to get

Thanks

Hongzhi Zhang

“zhz_zhang” <zhz_zhang@263.net> wrote in message
news:a6hrpk$3gf$1@inn.qnx.com

Accidentally,I find this topic.“Current Time in an interrupt handler?”
I am interested with this topic ,because my program needs “Current Time in
an interrupt handler” too.
So I want to continue discussing.

I see someone write:

“Brown, Richard” <> brownr@aecl.ca> > wrote in message
news:a4j4fs$59b$> 1@inn.qnx.com> …
Our policy is to timestamp data at the time of reception. So if we have
data
being gathered via an ISR we would like to timestamp that data as close
to
the actual time it was obtained. If we wait until outside the ISR then
we
could potentially be preempted and the accuracy of the timestamping
would
be
lost.
Reading the safety notes on clock_gettime I see that its not interrupt
safe.
Could one wrap this function around calls to disable/enable interrupts
to
make it interrupt safe? What exactly does interrupt safe mean for this
function?


“Mario Charest” <> goto@nothingness.com
wrote in message news:a4j5nj$5v4$> 1@inn.qnx.com> …

You could use ClockCycles() if processor is Pentium or above.
That 's VERY precise, down to the CPU clock frequency.
or
SYSPAGE_ENTRY(qtime)->nsec (resolution is the ticksize)

Up to now,I haven’t found a appropriate method to get current time in an
interrupt handler,

I have seen the doc about ClockCycles().As if it is not Current “time”,but
current value of a free-running 64-bit cycle counter.
To the SYSPAGE_ENTRY(qtime)->nsec (resolution is the ticksize),I don’t
know
what the concept " ticksize".

In a word ,whether I need some convert the ClockCycles() or
SYSPAGE_ENTRY(qtime)->nsec to get current time.
The time accurate I wish is at least-“1us” .How could I do?
or is there other method to get

Thanks

Hongzhi Zhang

Just read the TSC registers from pentium (latest MIPS, PPC has similar
regsiter too),
search RDTSC in google. It is fast, easy and give your very high
resolution timing info.

-Tony
Nokia Networks.

I have seen the doc about ClockCycles().As if it is not Current “time”,but
current value of a free-running 64-bit cycle counter.
To the SYSPAGE_ENTRY(qtime)->nsec (resolution is the ticksize),I don’t
know
what the concept " ticksize".

In a word ,whether I need some convert the ClockCycles() or
SYSPAGE_ENTRY(qtime)->nsec to get current time.
The time accurate I wish is at least-“1us” .How could I do?
or is there other method to get

Thanks

Hongzhi Zhang

Just read the TSC registers from pentium (latest MIPS, PPC has similar
regsiter too),
search RDTSC in google. It is fast, easy and give your very high
resolution timing info.

-Tony
Nokia Networks.

ClockCycles() gives you exactly that, i.e. the TSC content.

Hongzhi,

The tick size referred to is the CPU clock cycle length, i.e. on a 1GHz CPU you’ll
get 1ns tick size.

If relative time measuerments works for you, the ClockCycles() will do the trick.
You can not get absolute time measurements with 1us resolution inside
a interrupt handler, in fact you can not get that accurate time measurements at all
on a standard PC regardless the OS you run. You can get around 1ms resolution
from the OS clock, but of course you need to continuously synchronize the clock
to remain correct.
If you need absolute time measurement in the 1us order of accuracy you need
special hardware like GPS clocks which can give you the accuracy.
E.g. www.truetime.com have products.

Tom

“Tomas Högström” <tomas@scandicraft.se> wrote in message
news:3C8DF755.86ECFDBD@scandicraft.se

I have seen the doc about ClockCycles().As if it is not Current
“time”,but
current value of a free-running 64-bit cycle counter.
To the SYSPAGE_ENTRY(qtime)->nsec (resolution is the ticksize),I don’t
know
what the concept " ticksize".

In a word ,whether I need some convert the ClockCycles() or
SYSPAGE_ENTRY(qtime)->nsec to get current time.
The time accurate I wish is at least-“1us” .How could I do?
or is there other method to get

Thanks

Hongzhi Zhang

Just read the TSC registers from pentium (latest MIPS, PPC has similar
regsiter too),
search RDTSC in google. It is fast, easy and give your very high
resolution timing info.

-Tony
Nokia Networks.

ClockCycles() gives you exactly that, i.e. the TSC content.

Hongzhi,

The tick size referred to is the CPU clock cycle length, i.e. on a 1GHz
CPU you’ll
get 1ns tick size.

If relative time measuerments works for you, the ClockCycles() will do the
trick.
You can not get absolute time measurements with 1us resolution inside
a interrupt handler, in fact you can not get that accurate time
measurements at all
on a standard PC regardless the OS you run. You can get around 1ms
resolution
from the OS clock, but of course you need to continuously synchronize the
clock
to remain correct.
If you need absolute time measurement in the 1us order of accuracy you
need
special hardware like GPS clocks which can give you the accuracy.
E.g. > www.truetime.com > have products.

Could you simply record the current OS time and ClockCycles () values at
start up and then simply add the delta in time from ClockCycles () to the
starting OS time for an absolute current time in your ISR?

Dwayne Nelson wrote:

“Tomas Högström” <> tomas@scandicraft.se> > wrote in message
news:> 3C8DF755.86ECFDBD@scandicraft.se> …
I have seen the doc about ClockCycles().As if it is not Current
“time”,but
current value of a free-running 64-bit cycle counter.
To the SYSPAGE_ENTRY(qtime)->nsec (resolution is the ticksize),I don’t
know
what the concept " ticksize".

In a word ,whether I need some convert the ClockCycles() or
SYSPAGE_ENTRY(qtime)->nsec to get current time.
The time accurate I wish is at least-“1us” .How could I do?
or is there other method to get

Thanks

Hongzhi Zhang

Just read the TSC registers from pentium (latest MIPS, PPC has similar
regsiter too),
search RDTSC in google. It is fast, easy and give your very high
resolution timing info.

-Tony
Nokia Networks.

ClockCycles() gives you exactly that, i.e. the TSC content.

Hongzhi,

The tick size referred to is the CPU clock cycle length, i.e. on a 1GHz
CPU you’ll
get 1ns tick size.

If relative time measuerments works for you, the ClockCycles() will do the
trick.
You can not get absolute time measurements with 1us resolution inside
a interrupt handler, in fact you can not get that accurate time
measurements at all
on a standard PC regardless the OS you run. You can get around 1ms
resolution
from the OS clock, but of course you need to continuously synchronize the
clock
to remain correct.
If you need absolute time measurement in the 1us order of accuracy you
need
special hardware like GPS clocks which can give you the accuracy.
E.g. > www.truetime.com > have products.

Could you simply record the current OS time and ClockCycles () values at
start up and then simply add the delta in time from ClockCycles () to the
starting OS time for an absolute current time in your ISR?

For a while I guess you can do this. But of course your absolute time
accuracy will be no better than the synchronization accuracy of your OS
clock, i.e. if you synchronize your OS clock down to 1ms accuracy, the
OS clock + ClockCycles will have around 1ms absolute accuracy.
You should repeat this procedure now and then since I think the OS clock
and the ClockCycles() readings (converted to time) may drift apart with time.

Tom

I have understand the idea.
Thank everybody.
By the way ,whether when the PC boot,the value of ClockCycles() is ZERO?
or arbitrary value?

“Tomas Högström” <tomas@scandicraft.se> wrote in message
news:3C8E492F.60468CA4@scandicraft.se

Dwayne Nelson wrote:

“Tomas Högström” <> tomas@scandicraft.se> > wrote in message
news:> 3C8DF755.86ECFDBD@scandicraft.se> …
I have seen the doc about ClockCycles().As if it is not Current
“time”,but
current value of a free-running 64-bit cycle counter.
To the SYSPAGE_ENTRY(qtime)->nsec (resolution is the ticksize),I
don’t
know
what the concept " ticksize".

In a word ,whether I need some convert the ClockCycles() or
SYSPAGE_ENTRY(qtime)->nsec to get current time.
The time accurate I wish is at least-“1us” .How could I do?
or is there other method to get

Thanks

Hongzhi Zhang

Just read the TSC registers from pentium (latest MIPS, PPC has
similar
regsiter too),
search RDTSC in google. It is fast, easy and give your very high
resolution timing info.

-Tony
Nokia Networks.

ClockCycles() gives you exactly that, i.e. the TSC content.

Hongzhi,

The tick size referred to is the CPU clock cycle length, i.e. on a
1GHz
CPU you’ll
get 1ns tick size.

If relative time measuerments works for you, the ClockCycles() will do
the
trick.
You can not get absolute time measurements with 1us resolution inside
a interrupt handler, in fact you can not get that accurate time
measurements at all
on a standard PC regardless the OS you run. You can get around 1ms
resolution
from the OS clock, but of course you need to continuously synchronize
the
clock
to remain correct.
If you need absolute time measurement in the 1us order of accuracy you

need
special hardware like GPS clocks which can give you the accuracy.
E.g. > www.truetime.com > have products.

Could you simply record the current OS time and ClockCycles () values at
start up and then simply add the delta in time from ClockCycles () to
the
starting OS time for an absolute current time in your ISR?

For a while I guess you can do this. But of course your absolute time
accuracy will be no better than the synchronization accuracy of your OS
clock, i.e. if you synchronize your OS clock down to 1ms accuracy, the
OS clock + ClockCycles will have around 1ms absolute accuracy.
You should repeat this procedure now and then since I think the OS clock
and the ClockCycles() readings (converted to time) may drift apart with
time.

Tom

I’m newbie on ClockCycles(), but

Could you simply record the current OS time and ClockCycles () values at
start up and then simply add the delta in time from ClockCycles () to the
starting OS time for an absolute current time in your ISR?

Modern x86 CPUs (and perhaps other over-20Watt MPUs too) adjusts
clockrate dynamically according to the CPU load.
RDTSC could be no longer ticking constantly
(bash me if twas wrong)

kabe

kabe@sra-tohoku.co.jp wrote:

I’m newbie on ClockCycles(), but

Could you simply record the current OS time and ClockCycles () values at
start up and then simply add the delta in time from ClockCycles () to the
starting OS time for an absolute current time in your ISR?

Modern x86 CPUs (and perhaps other over-20Watt MPUs too) adjusts
clockrate dynamically according to the CPU load.
RDTSC could be no longer ticking constantly
(bash me if twas wrong)

I thought that was configurable – and generally only happened if they
went into a power-conservation mode or something like that?

I know my laptop will do it to conserve power, but there it seems
configurable.

-David

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

<kabe@sra-tohoku.co.jp> wrote in message news:a6r6vh$qn8$1@inn.qnx.com

I’m newbie on ClockCycles(), but

Could you simply record the current OS time and ClockCycles () values
at
start up and then simply add the delta in time from ClockCycles () to
the
starting OS time for an absolute current time in your ISR?

Modern x86 CPUs (and perhaps other over-20Watt MPUs too) adjusts
clockrate dynamically according to the CPU load.

No they don’t (x86), certain Mobile version of the CPU will though.

RDTSC could be no longer ticking constantly
(bash me if twas wrong)

kabe