> > The following tests are made with 'IRQ 8' at 95, rtc_wakeup
> at 89(99):
> > * Heavy mmap load, no oom: max jitter: 42.1% ( 51 usec)
> > * Heavy mmap load, oom:max jitter: 11989.2% (14635 usec)
> > (but still "missed irqs: 0", so IRQ 8 was also blocked for 14 ms)
>
> did you get
* kus Kusche Klaus <[EMAIL PROTECTED]> wrote:
> The following tests are made with 'IRQ 8' at 95, rtc_wakeup at 89(99):
> * Heavy mmap load, no oom: max jitter: 42.1% ( 51 usec)
> * Heavy mmap load, oom:max jitter: 11989.2% (14635 usec)
> (but still "missed irqs: 0", so IRQ 8 was also
> getting /dev/rtc handling right for latency measurement is
> ... tricky.
> The method i'm using under PREEMPT_RT is:
>
> chrt -f 84 -p `pidof 'IRQ 0'`
> chrt -f 95 -p `pidof 'IRQ 8'`
> ./rtc_wakeup -f 1024 -t 10
I tried it your way.
First impressions with realtime-preempt-2.6.12-rc1-
* kus Kusche Klaus <[EMAIL PROTECTED]> wrote:
> I've written a small test program which enables periodic RTC
> interrupts at 8192 Hz and then goes into a loop reading /dev/rtc and
> collecting timing statistics (using the rdtscl macro).
getting /dev/rtc handling right for latency measurement i
> > The test system runs a 2.6.11 kernel (no SMP) on a Pentium3 500 MHz
> > embedded hardware.
>
> which probably has memory bandwidth of at most a couple hundred MB/s,
> which is really horrible by modern standards.
It's my job to find out if linux can be used for control systems
on this (and
On Wed, 2005-03-30 at 09:41 -0500, Mark Hahn wrote:
> >> The test system runs a 2.6.11 kernel (no SMP) on a Pentium3 500 MHz
> > embedded hardware.
>
> which probably has memory bandwidth of at most a couple hundred MB/s,
> which is really horrible by modern standards.
What does that have to do
> I've written a small test program which enables periodic RTC interrupts
> at 8192 Hz and then goes into a loop reading /dev/rtc and collecting
> timing statistics (using the rdtscl macro).
straightforward test, used for many years in the linux community
(I claim to have been the first to publi
> From: Bartlomiej Zolnierkiewicz [mailto:[EMAIL PROTECTED]
>
> On Wed, 30 Mar 2005 13:52:05 +0200, kus Kusche Klaus
> <[EMAIL PROTECTED]> wrote:
> > However, things break seriously when exercising the CF card
> in parallel
> > (e.g. with a dd if=/dev/hda of=/dev/null):
> >
> > * The rtc *inter
On Wed, 30 Mar 2005 13:52:05 +0200, kus Kusche Klaus <[EMAIL PROTECTED]> wrote:
> However, things break seriously when exercising the CF card in parallel
> (e.g. with a dd if=/dev/hda of=/dev/null):
>
> * The rtc *interrupt handler* is delayed for up to 250 *micro*seconds.
> This is very bad for
I've written a small test program which enables periodic RTC interrupts
at 8192 Hz and then goes into a loop reading /dev/rtc and collecting
timing statistics (using the rdtscl macro).
The program runs at highest realtime scheduling priority (99) with
memory
locked. In the loop, it doesn't do a
10 matches
Mail list logo
