high accuracy timing

[martijn_sipkema]

i want to write a midi subsystem for qnx providing a
interface for midi communication and ipc midi. is there
a way to get accurate time information needed for midi
with qnxrtp? it should be clearly submilisecond accurate
and i should be able to sleep on it accurately, not depen-
ding on the scheduler quantum.

beos provided two functions, “system_time()”, returning
the time in microseconds since boot and “snooze_until()”
that sleeps on the timebase returned by system_time()
accurately. these functions also work on smp machines
without having to lock a thread to one cpu.

are functions like these available with qnxrtp or possible
to implement using ClockCycles() e.g.?

– martijn

[Robert_Krten1]

martijn sipkema (m.j.w.sipkema@student.tudelft.nl) wrote:
: i want to write a midi subsystem for qnx providing a
: interface for midi communication and ipc midi. is there
: a way to get accurate time information needed for midi
: with qnxrtp? it should be clearly submilisecond accurate
: and i should be able to sleep on it accurately, not depen-
: ding on the scheduler quantum.

In order to sleep (i.e., and let other threads run), you need
to do a kernel call, and the kernel calls for sleeping are
all based off the input clock source rate. Take a look at
the ClockPeriod() call for tips on how to adjust this.

Just curious: could you simply use the UART to self-synchronize
the data stream? Granted, you’d have to be continuously sending
data (pick a bogus channel # )

Cheers,
-RK

: beos provided two functions, “system_time()”, returning
: the time in microseconds since boot and “snooze_until()”
: that sleeps on the timebase returned by system_time()
: accurately. these functions also work on smp machines
: without having to lock a thread to one cpu.

: are functions like these available with qnxrtp or possible
: to implement using ClockCycles() e.g.?

: – martijn

–

Robert Krten, PARSE Software Devices; email my initials at parse dot com
Consulting, Systems Architecture / Design, Drivers, Training, QNX 4 & Neutrino
Check out our new QNX 4 and Neutrino (QRTP) books at http://www.parse.com/
Wanted PDP-8/9/10/11/12 Systems/documentation/spare parts! Will trade books!

[martijn_sipkema]

In order to sleep (i.e., and let other threads run), you need
to do a kernel call, and the kernel calls for sleeping are
all based off the input clock source rate. Take a look at
the ClockPeriod() call for tips on how to adjust this.

hmm. i think beos dynamically programs the pc clock chip
to be interrupted and reschedule exactly when a
“snooze_until()” call requested. the beos “snooze()” works
exactly like the qnx functions, having a worst case lateness
of one scheduler quantum.

is there really no way to get more accurate timing? i don’t
think a midi jitter of one clockperiod is good enough. i know
some interfaces can do timing in the interface, but most don’t.
i read somewhere that macos x goals for their midi subsystem
were for it to have an in/out latency of 1 ms with a jitter of 200
microseconds. but with the qnx sleep() that could only be achieved
by setting the clockperiod to 200 microseconds, which seems a
bit too much for me.

– martijn

[Igor_Kovalenko2]

To ‘sleep’ very accurately without interference from scheduler you’d
need to busywait. QNX has nanosleep_xx() family of calls for that. It
appears to be quite effective in my experience and does not bring CPU to
knees either. I think it does something close to calls you’ve described.

Another thing to consider is, many (most?) audio chips have internal
programmable timers which are used to generate interrupts at desired
rate. You could just use those interrupts to implement your own
‘reliable and accurate sleep’. I believe ALSA drivers supporting midi
utilize that.

Note also, you’d have to do a resmgr from scratch, since io-audio does
not support midi right now. Which means device name conventions and API
are pretty much up to you. It probably would make sense to stick with
ALSA device name conventions and support their API to make it consistent
with the rest of audio stuff in QNX.

• igor

martijn sipkema wrote:

i want to write a midi subsystem for qnx providing a
interface for midi communication and ipc midi. is there
a way to get accurate time information needed for midi
with qnxrtp? it should be clearly submilisecond accurate
and i should be able to sleep on it accurately, not depen-
ding on the scheduler quantum.

beos provided two functions, “system_time()”, returning
the time in microseconds since boot and “snooze_until()”
that sleeps on the timebase returned by system_time()
accurately. these functions also work on smp machines
without having to lock a thread to one cpu.

are functions like these available with qnxrtp or possible
to implement using ClockCycles() e.g.?

– martijn

[Armin_Steinhoff1]

Hi Martijn,

you could use the RTC (IRQ8) of your PC.

Install a interrupt handler at the IRQ8, let them trigger a puls
with every timer interrupt and wait in a thread for that pulse.

The IRQ8 can be configured down to e.g. 128 us.

Please drop me a mail if don’t know how to do that …

Armin

http://www.steinhoff-automation.com



martijn sipkema wrote:

i want to write a midi subsystem for qnx providing a
interface for midi communication and ipc midi. is there
a way to get accurate time information needed for midi
with qnxrtp? it should be clearly submilisecond accurate
and i should be able to sleep on it accurately, not depen-
ding on the scheduler quantum.

beos provided two functions, “system_time()”, returning
the time in microseconds since boot and “snooze_until()”
that sleeps on the timebase returned by system_time()
accurately. these functions also work on smp machines
without having to lock a thread to one cpu.

are functions like these available with qnxrtp or possible
to implement using ClockCycles() e.g.?

– martijn

[martijn_sipkema]

i would prefer some portable method.

– martijn

Armin Steinhoff <a-steinhoff@web._de> wrote in message
news:3B8DF877.169BBF26@web._de…

Hi Martijn,

you could use the RTC (IRQ8) of your PC.

Install a interrupt handler at the IRQ8, let them trigger a puls
with every timer interrupt and wait in a thread for that pulse.

The IRQ8 can be configured down to e.g. 128 us.

Please drop me a mail if don’t know how to do that …

Armin

http://www.steinhoff-automation.com



martijn sipkema wrote:

i want to write a midi subsystem for qnx providing a
interface for midi communication and ipc midi. is there
a way to get accurate time information needed for midi
with qnxrtp? it should be clearly submilisecond accurate
and i should be able to sleep on it accurately, not depen-
ding on the scheduler quantum.

beos provided two functions, “system_time()”, returning
the time in microseconds since boot and “snooze_until()”
that sleeps on the timebase returned by system_time()
accurately. these functions also work on smp machines
without having to lock a thread to one cpu.

are functions like these available with qnxrtp or possible
to implement using ClockCycles() e.g.?

– martijn

[Chris_McKillop1]

martijn sipkema <m.j.w.sipkema@student.tudelft.nl> wrote:

i would prefer some portable method.

Portable between which? CPU versions of QNX? You could always just
make the timer a DLL that you load @ runtime. That way on new platforms
of any sort the timer could be tuned to the system.

chris

– martijn

Armin Steinhoff <a-steinhoff@web._de> wrote in message
news:3B8DF877.169BBF26@web._de…

Hi Martijn,

you could use the RTC (IRQ8) of your PC.

Install a interrupt handler at the IRQ8, let them trigger a puls
with every timer interrupt and wait in a thread for that pulse.

The IRQ8 can be configured down to e.g. 128 us.

Please drop me a mail if don’t know how to do that …

Armin

http://www.steinhoff-automation.com



martijn sipkema wrote:

i want to write a midi subsystem for qnx providing a
interface for midi communication and ipc midi. is there
a way to get accurate time information needed for midi
with qnxrtp? it should be clearly submilisecond accurate
and i should be able to sleep on it accurately, not depen-
ding on the scheduler quantum.

beos provided two functions, “system_time()”, returning
the time in microseconds since boot and “snooze_until()”
that sleeps on the timebase returned by system_time()
accurately. these functions also work on smp machines
without having to lock a thread to one cpu.

are functions like these available with qnxrtp or possible
to implement using ClockCycles() e.g.?

– martijn

–

cdm@qnx.com > “The faster I go, the behinder I get.”

Chris McKillop – Lewis Carroll –
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

[martijn_sipkema]

Portable between which? CPU versions of QNX? You could always just
make the timer a DLL that you load @ runtime. That way on new platforms
of any sort the timer could be tuned to the system.

easy to port for different cpu version of qnx at the least. that’s why i
find it hard
to believe that there is no function giving better than scheduler quantum
timing
on a sleep.

– martijn

[Rennie_Allen2]

What’s wrong with setting the clock period to 200us (just curious) ? I
have often run QNX4 with a timeslice of 100us.

-----Original Message-----
From: martijn sipkema [mailto:m.j.w.sipkema@student.tudelft.nl]
Posted At: Wednesday, August 29, 2001 7:56 AM
Posted To: os
Conversation: high accuracy timing
Subject: Re: high accuracy timing

In order to sleep (i.e., and let other threads run), you need
to do a kernel call, and the kernel calls for sleeping are
all based off the input clock source rate. Take a look at
the ClockPeriod() call for tips on how to adjust this.

hmm. i think beos dynamically programs the pc clock chip
to be interrupted and reschedule exactly when a
“snooze_until()” call requested. the beos “snooze()” works
exactly like the qnx functions, having a worst case lateness
of one scheduler quantum.

is there really no way to get more accurate timing? i don’t
think a midi jitter of one clockperiod is good enough. i know
some interfaces can do timing in the interface, but most don’t.
i read somewhere that macos x goals for their midi subsystem
were for it to have an in/out latency of 1 ms with a jitter of 200
microseconds. but with the qnx sleep() that could only be achieved
by setting the clockperiod to 200 microseconds, which seems a
bit too much for me.

– martijn

[martijn_sipkema]

What’s wrong with setting the clock period to 200us (just curious) ? I
have often run QNX4 with a timeslice of 100us.

it’s still not as accurate as a dynamically programmed clock chip. but for
midi this would suffice. i don’t think it very elegant. also how does this
affect performance?

– martijn

[ed1k2]

Hi,

I believe 500 usec is the lowest value Neutrino accepts.

Regards,
eduard.

Rennie Allen <RAllen@csical.com> wrote in article
<64F00D816A85D51198390050046F80C9A527@exchangecal.hq.csical.com>…

What’s wrong with setting the clock period to 200us (just curious) ? I
have often run QNX4 with a timeslice of 100us.

[ed1k2]

I mean QNX RTP, sorry…

ed1k <ed1k@yahoo.com> wrote in article 01c131ed$e82f2ae0$396fa8c0@ED1K…

Hi,

I believe 500 usec is the lowest value Neutrino accepts.

Regards,
eduard.

[Robert_Krten1]

ed1k (ed1k@yahoo.com) wrote:
: Hi,

: I believe 500 usec is the lowest value Neutrino accepts.

Yes, and there’s a bug there too that I’ve been meaning to report.

If you set it to 500 us, and then query it, it comes back with 498.xxxx us.
If you try to set that number, it says that it’s invalid – so it won’t
take its own values as input.

-RK

–

Robert Krten, PARSE Software Devices; email my initials at parse dot com
Consulting, Systems Architecture / Design, Drivers, Training, QNX 4 & Neutrino
Check out our new QNX 4 and Neutrino (QRTP) books at http://www.parse.com/
Wanted PDP-8/9/10/11/12 Systems/documentation/spare parts! Will trade books!

[Armin_Steinhoff1]

martijn sipkema wrote:

Portable between which? CPU versions of QNX? You could always just
make the timer a DLL that you load @ runtime. That way on new platforms
of any sort the timer could be tuned to the system.

easy to port for different cpu version of qnx at the least. that’s why i
find it hard to believe that there is no function giving better than scheduler quantum
timing on a sleep.

There is no ‘scheduler quantum’, but there is a time resolution
defined the timer tick.

Please see: http://qdn.qnx.com/articles/oct2300/quantization.html

The RTC approach is portable in the sense that every thing is
portable … but you mean
probably source code compatibility between differend CPUs.

IMHO … that’s not possible because the SW (e.g. BIOS, if there is
one) and HW resources (CHIP sets) are very different.

Armin

[martijn_sipkema]

what i would like is to be able to get some time that is microsecond
accurate
and to be able to sleep on such times without the quantising. this is what
beos does.

or what would be nice is to have a ust as irix has it for its media
libraries.

it is however necessary imho to have accurate timestamping and
scheduling of events for audio/video/midi. with a 1ms timer tick that
would still leave you with 500 microseconds jitter.

–martijn

Armin Steinhoff <a-steinhoff@web._de> wrote in message
news:3B954909.266B0CFB@web._de…

martijn sipkema wrote:

Portable between which? CPU versions of QNX? You could always just
make the timer a DLL that you load @ runtime. That way on new
platforms
of any sort the timer could be tuned to the system.

easy to port for different cpu version of qnx at the least. that’s why i
find it hard to believe that there is no function giving better than
scheduler quantum
timing on a sleep.

There is no ‘scheduler quantum’, but there is a time resolution
defined the timer tick.

Please see: > http://qdn.qnx.com/articles/oct2300/quantization.html

The RTC approach is portable in the sense that every thing is
portable > > … but you mean
probably source code compatibility between differend CPUs.

IMHO … that’s not possible because the SW (e.g. BIOS, if there is
one) and HW resources (CHIP sets) are very different.

Armin

[Rennie_Allen2]

What is quantising ? From a technical perspective that is. I did a
google on “quantising”, and I got a lot of MIDI/artsy stuff about having
a “groove” (I am a drummer so I know what they’re talking about, but I
want to know what you mean when you use this term - since we are
discussing timing functions not “grooving” .

Google also suggested that I search “quantizing” which I did, and I got
a bunch of hits the same as above, and some hits regarding quantizing
noise in analog sampling (which again appears to have no relevance to
timer functions - other than when they are used to schedule analog
sampling).

I completely agree that “high” (I believe we agree on the semantics of
“high” and “low” wrt this conversation) accuracy “low” jitter timing
functions are required, my problem is understanding why simply
decreasing the granularity of the timer interrupt does not achieve this,
in your opinion).

btw: dictionary.com has no entry for quantising, and 1 entry for
quantizing (the definition of which relates to the field of quantum
mechanics), so it appears that your usage is a MIDI colloquialism with
which I am not familiar.

-----Original Message-----
From: martijn sipkema [mailto:m.j.w.sipkema@student.tudelft.nl]
Posted At: Wednesday, September 05, 2001 12:06 AM
Posted To: os
Conversation: high accuracy timing
Subject: Re: high accuracy timing


what i would like is to be able to get some time that is microsecond
accurate
and to be able to sleep on such times without the quantising. this is
what
beos does.

or what would be nice is to have a ust as irix has it for its media
libraries.

it is however necessary imho to have accurate timestamping and
scheduling of events for audio/video/midi. with a 1ms timer tick that
would still leave you with 500 microseconds jitter.

–martijn

Armin Steinhoff <a-steinhoff@web._de> wrote in message
news:3B954909.266B0CFB@web._de…

martijn sipkema wrote:

Portable between which? CPU versions of QNX? You could always
just
make the timer a DLL that you load @ runtime. That way on new
platforms
of any sort the timer could be tuned to the system.

easy to port for different cpu version of qnx at the least. that’s
why i
find it hard to believe that there is no function giving better than
scheduler quantum
timing on a sleep.

There is no ‘scheduler quantum’, but there is a time resolution
defined the timer tick.

Please see: > http://qdn.qnx.com/articles/oct2300/quantization.html

The RTC approach is portable in the sense that every thing is
portable > > … but you mean
probably source code compatibility between differend CPUs.

IMHO … that’s not possible because the SW (e.g. BIOS, if there is
one) and HW resources (CHIP sets) are very different.

Armin

[martijn_sipkema]

i’m not a native english speaker so perhaps it’s quantising or
quantizing, i am not sure. what i meant with that is that the
value of time is rounded to some, in this case the clock tick,
value. in midi it also means rounding to some clock. i know
that every integer timer value is ‘discreet’ in that it rounds to
some value, but i believe that 1ms or even 500 microseconds
is a somewhat too large value. what qnx probably needs is
a media subsystem such as openml, with support for midi
added. a common timebase for all media applications that
is not adjusted, i.e. dependant on the utc time.
for accurate timestamping the clock tick is not accurate enough
imo and there isn’t a convenient accurate alternative that also
allows sleeping on and that doesn’t depend on the cpu.

i have been looking into openml and this seems to be a good
way to go. industry standard. supported by large companies.
openml for qnx would be a dream come true :^)

–martijn

Rennie Allen <RAllen@csical.com> wrote in message
news:64F00D816A85D51198390050046F80C9AC96@exchangecal.hq.csical.com…

What is quantising ? From a technical perspective that is. I did a
google on “quantising”, and I got a lot of MIDI/artsy stuff about having
a “groove” (I am a drummer so I know what they’re talking about, but I
want to know what you mean when you use this term - since we are
discussing timing functions not “grooving” > > .

Google also suggested that I search “quantizing” which I did, and I got
a bunch of hits the same as above, and some hits regarding quantizing
noise in analog sampling (which again appears to have no relevance to
timer functions - other than when they are used to schedule analog
sampling).

I completely agree that “high” (I believe we agree on the semantics of
“high” and “low” wrt this conversation) accuracy “low” jitter timing
functions are required, my problem is understanding why simply
decreasing the granularity of the timer interrupt does not achieve this,
in your opinion).

btw: dictionary.com has no entry for quantising, and 1 entry for
quantizing (the definition of which relates to the field of quantum
mechanics), so it appears that your usage is a MIDI colloquialism with
which I am not familiar.

-----Original Message-----
From: martijn sipkema [mailto:> m.j.w.sipkema@student.tudelft.nl> ]
Posted At: Wednesday, September 05, 2001 12:06 AM
Posted To: os
Conversation: high accuracy timing
Subject: Re: high accuracy timing


what i would like is to be able to get some time that is microsecond
accurate
and to be able to sleep on such times without the quantising. this is
what
beos does.

or what would be nice is to have a ust as irix has it for its media
libraries.

it is however necessary imho to have accurate timestamping and
scheduling of events for audio/video/midi. with a 1ms timer tick that
would still leave you with 500 microseconds jitter.

–martijn

Armin Steinhoff <a-steinhoff@web._de> wrote in message
news:3B954909.266B0CFB@web._de…


martijn sipkema wrote:

Portable between which? CPU versions of QNX? You could always
just
make the timer a DLL that you load @ runtime. That way on new
platforms
of any sort the timer could be tuned to the system.

easy to port for different cpu version of qnx at the least. that’s
why i
find it hard to believe that there is no function giving better than
scheduler quantum
timing on a sleep.

There is no ‘scheduler quantum’, but there is a time resolution
defined the timer tick.

Please see: > http://qdn.qnx.com/articles/oct2300/quantization.html

The RTC approach is portable in the sense that every thing is
portable > > … but you mean
probably source code compatibility between differend CPUs.

IMHO … that’s not possible because the SW (e.g. BIOS, if there is
one) and HW resources (CHIP sets) are very different.

Armin

[Rennie_Allen2]

I agree that 500usec is too coarse for many applications, but I think we
agree that simply having a finer resolution would be sufficient. I find
it annoying that QNX6 has a more coarse resolution than QNX4.

-----Original Message-----
From: martijn sipkema [mailto:m.j.w.sipkema@student.tudelft.nl]
Posted At: Wednesday, September 05, 2001 1:10 PM
Posted To: os
Conversation: high accuracy timing
Subject: Re: high accuracy timing


i’m not a native english speaker so perhaps it’s quantising or
quantizing, i am not sure. what i meant with that is that the
value of time is rounded to some, in this case the clock tick,
value. in midi it also means rounding to some clock. i know
that every integer timer value is ‘discreet’ in that it rounds to
some value, but i believe that 1ms or even 500 microseconds
is a somewhat too large value. what qnx probably needs is
a media subsystem such as openml, with support for midi
added. a common timebase for all media applications that
is not adjusted, i.e. dependant on the utc time.
for accurate timestamping the clock tick is not accurate enough
imo and there isn’t a convenient accurate alternative that also
allows sleeping on and that doesn’t depend on the cpu.

i have been looking into openml and this seems to be a good
way to go. industry standard. supported by large companies.
openml for qnx would be a dream come true :^)

–martijn

Rennie Allen <RAllen@csical.com> wrote in message
news:64F00D816A85D51198390050046F80C9AC96@exchangecal.hq.csical.com…

What is quantising ? From a technical perspective that is. I did a
google on “quantising”, and I got a lot of MIDI/artsy stuff about
having
a “groove” (I am a drummer so I know what they’re talking about, but I
want to know what you mean when you use this term - since we are
discussing timing functions not “grooving” > > .

Google also suggested that I search “quantizing” which I did, and I
got
a bunch of hits the same as above, and some hits regarding quantizing
noise in analog sampling (which again appears to have no relevance to
timer functions - other than when they are used to schedule analog
sampling).

I completely agree that “high” (I believe we agree on the semantics of
“high” and “low” wrt this conversation) accuracy “low” jitter timing
functions are required, my problem is understanding why simply
decreasing the granularity of the timer interrupt does not achieve
this,
in your opinion).

btw: dictionary.com has no entry for quantising, and 1 entry for
quantizing (the definition of which relates to the field of quantum
mechanics), so it appears that your usage is a MIDI colloquialism with
which I am not familiar.

-----Original Message-----
From: martijn sipkema [mailto:> m.j.w.sipkema@student.tudelft.nl> ]
Posted At: Wednesday, September 05, 2001 12:06 AM
Posted To: os
Conversation: high accuracy timing
Subject: Re: high accuracy timing


what i would like is to be able to get some time that is microsecond
accurate
and to be able to sleep on such times without the quantising. this is
what
beos does.

or what would be nice is to have a ust as irix has it for its media
libraries.

it is however necessary imho to have accurate timestamping and
scheduling of events for audio/video/midi. with a 1ms timer tick that
would still leave you with 500 microseconds jitter.

–martijn

Armin Steinhoff <a-steinhoff@web._de> wrote in message
news:3B954909.266B0CFB@web._de…


martijn sipkema wrote:

Portable between which? CPU versions of QNX? You could always
just
make the timer a DLL that you load @ runtime. That way on new
platforms
of any sort the timer could be tuned to the system.

easy to port for different cpu version of qnx at the least. that’s
why i
find it hard to believe that there is no function giving better
than
scheduler quantum
timing on a sleep.

There is no ‘scheduler quantum’, but there is a time resolution
defined the timer tick.

Please see: > http://qdn.qnx.com/articles/oct2300/quantization.html

The RTC approach is portable in the sense that every thing is
portable > > … but you mean
probably source code compatibility between differend CPUs.

IMHO … that’s not possible because the SW (e.g. BIOS, if there is
one) and HW resources (CHIP sets) are very different.

Armin