18 Sep
2003
18 Sep
'03
3:42 p.m.
Paul Davis wrote:
I hope this is not true:
"Embedded systems often need to poll hardware or do other tasks on a
fixed schedule. POSIX timers make it easy to arrange any task to get
scheduled periodically. The clock that the timer uses can be set to
tick at a rate a fine as one kilohertz, so that software engineers can
control the scheduling of tasks with precision."
The promise of the high-res timer patch was usec
resolution, not msec.
This would be a great loss. Does anybody know any more?
Yes unfortunately it is true what they say in the article.
The current timer resolution is 1msec (HZ = 1024, so to be precise
the resolution is (1/1024) sec).
In short the story is as follows: Linus accepted the
POSIX 1003.1b Section 14 (Clocks and Timers) API in kernel 2.6
but not yet it's implementation
(patches available here http://high-res-timers.sourceforge.net/ ).
This means that applications using the POSIX 1003.1b timer API can
specify timing values nanosecond resolution but for now only
msec resolution is provided.
But when the Linus & co will let in the kernel the high-res
timer implementation, those apps will instantly be able to achieve
higher resolution without recompilation etc.
Yes usec resolution would be handy for some audio apps but I for
now I am happy of being able to achieve msec resolution in MIDI playback
without resorting to the RTC device which cannot easily be shared.
PS: in the article they talk about 4500usec worst case scheduling
latency (= 4.5msec), seems a bit disappointing.
I'm curious what they mean with worst case,
which kind of test suites they used etc.
2.4 + some LL patches let you reliably work with sub 3msec BTW.
Benno
-------------------------------------------------
This mail sent through http://www.gardena.net
18 Sep
18 Sep
6:20 p.m.
New subject: [linux-audio-dev] lowlatency test at linuxdevices
An interesting historical sidenote on this came from of our programmers,
who was deep in the BeOS. He told me that their timeslice was 3 msecs
once everyone had 500 MHz machines. It was down to 1 msec for the never
released R6 version... back in, what 1999? 2000?
Open source is a bit slower to move, but at least it sticks around!
- mo
On Thu, 2003-09-18 at 10:27, Benno Senoner wrote:
Paul Davis wrote:
I hope this is not true:
"Embedded systems often need to poll hardware or do other tasks on a
fixed schedule. POSIX timers make it easy to arrange any task to get
scheduled periodically. The clock that the timer uses can be set to
tick at a rate a fine as one kilohertz, so that software engineers can
control the scheduling of tasks with precision."
The promise of the high-res timer patch was usec
resolution, not msec.
This would be a great loss. Does anybody know any more?
Yes unfortunately it is true what they say in the article.
The current timer resolution is 1msec (HZ = 1024, so to be precise
the resolution is (1/1024) sec).
In short the story is as follows: Linus accepted the
POSIX 1003.1b Section 14 (Clocks and Timers) API in kernel 2.6
but not yet it's implementation
(patches available here http://high-res-timers.sourceforge.net/ ).
This means that applications using the POSIX 1003.1b timer API can
specify timing values nanosecond resolution but for now only
msec resolution is provided.
But when the Linus & co will let in the kernel the high-res
timer implementation, those apps will instantly be able to achieve
higher resolution without recompilation etc.
Yes usec resolution would be handy for some audio apps but I for
now I am happy of being able to achieve msec resolution in MIDI playback
without resorting to the RTC device which cannot easily be shared.
PS: in the article they talk about 4500usec worst case scheduling
latency (= 4.5msec), seems a bit disappointing.
I'm curious what they mean with worst case,
which kind of test suites they used etc.
2.4 + some LL patches let you reliably work with sub 3msec BTW.
Benno
-------------------------------------------------
This mail sent through http://www.gardena.net 
19 Sep
19 Sep
9:26 a.m.
New subject: [linux-audio-dev] lowlatency test at linuxdevices
An interesting historical sidenote on this came from of
our programmers,
who was deep in the BeOS. He told me that their timeslice was 3 msecs
once everyone had 500 MHz machines. It was down to 1 msec for the never
released R6 version... back in, what 1999? 2000?
the sad part is that the HRT patch completely removes *any* dependency
on the timeslice or timer interrupt frequency. you get timing by
reprogramming the APIC so that it interrupts the CPU at exactly the
right time. the APIC has usec resolution for this. its a much better
design than just cranking up HZ, and in fact, I would probably leave
HZ at 100 with this patch in place.
Open source is a bit slower to move, but at least it
sticks around!
So true. Anyway, at least there will be a patch; the most recent one
for 2.4.20 just came out.
--p
10:35 a.m.
New subject: [linux-audio-dev] lowlatency test at linuxdevices
On Fri, Sep 19, 2003 at 07:23:47AM -0400, Paul Davis wrote:
You mean: http://sourceforge.net/projects/high-res-timers/ ?
I just stumbled on this while searching for "high resolution timers" on
google: http://www.cs.wisc.edu/paradyn/libhrtime/
It seems old though (and probably unmaintained ?), latest patch was for
2.4.0, so I don't know if it is of more interest than the
high-res-timers patches (probably not).
vini
Open source is
a bit slower to move, but at least it sticks around!
So true. Anyway, at least there will be a patch; the most recent one
for 2.4.20 just came out.
12:51 p.m.
New subject: [linux-audio-dev] lowlatency test at linuxdevices
You mean:
http://sourceforge.net/projects/high-res-timers/ ?
I just stumbled on this while searching for "high resolution timers" on
google: http://www.cs.wisc.edu/paradyn/libhrtime/
It seems old though (and probably unmaintained ?), latest patch was for
2.4.0, so I don't know if it is of more interest than the
high-res-timers patches (probably not).
its of less interest. perhaps zero. george anzinger's project at
sf.net is definitely the one. read recent messages in the mailing list
archive for an overview of what's going to be involved in using this
stuff.
--p
2:19 p.m.
New subject: [linux-audio-dev] lowlatency test at linuxdevices
On Fri, Sep 19, 2003 at 10:48:38AM -0400, Paul Davis wrote:
its of less interest. perhaps zero. george
anzinger's project at
sf.net is definitely the one. read recent messages in the mailing list
archive for an overview of what's going to be involved in using this
stuff.
Will do !
vini
7732
days inactive
7733
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
4 participants
participants (4)
-
Benno Senoner -
Michael Ost -
Paul Davis -
Vincent Touquet