> > 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
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 any kernel
* 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
> 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
* 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
> > 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
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
* 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 is
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
* 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
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
> 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
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
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 my
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 *interrupt handler*
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 publish
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 with
18 matches
Mail list logo
