Ingo Molnar wrote:
> So why do your "ping flood" results show such difference? It really is
> just another type of interrupt workload and has nothing special in it.
...
> are you suggesting this is not really a benchmark but a way to test how
> well a particular system withholds against extreme
* Karim Yaghmour <[EMAIL PROTECTED]> wrote:
> With ping floods, as with other things, there is room for improvement,
> but keep in mind that these are standard tests [...]
the problem is that ping -f isnt what it used to be. If you are using a
recent distribution with an updated ping utility,
* Kristian Benoit <[EMAIL PROTECTED]> wrote:
[...]
> "plain" run:
>
> Measurements | Vanilla | preempt_rt| ipipe
> ---+-++-
> fork | 97us | 91us (-6%) | 101us (+4%)
> mmap | 776us | 629us (-19
On Sat, Jul 09, 2005 at 10:22:07AM -0700, Daniel Walker wrote:
> PREEMPT_RT is not pre-tuned for every situation , but the bests
> performance is achieved when the system is tuned. If any of these tests
> rely on a low priority thread, then we just raise the priority and you
> have better performan
On Sat, 2005-07-09 at 09:19 +0200, Ingo Molnar wrote:
> (if your goal was to check how heavily external interrupts can influence
> a PREEMPT_RT box, you should chrt the network IRQ thread to SCHED_OTHER
> and renice it and softirq-net-rx and softirq-net-tx to nice +19.)
>
This is interesting.
Can't type right anymore ...
Karim Yaghmour wrote:
> BTW, we've also released the latest very of the LRTBF we used to
version
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.oper
Karim Yaghmour wrote:
> I would usually like very much to entertain this further, but we've
> really busted all the time slots I had allocated to this work. So at
> this time, we really think others should start publishing results.
> After all, our results are no more authoritative than those
> pu
Ingo Molnar wrote:
> yeah, they definitely have helped, and thanks for this round of testing
> too! I'll explain the recent changes to PREEMPT_RT that resulted in
> these speedups in another mail.
Great, I'm very much looking forward to it.
> Looking at your numbers i realized that the area wh
* Paul Rolland <[EMAIL PROTECTED]> wrote:
> > "IRQ & hd" run:
> > Measurements | Vanilla | preempt_rt| ipipe
> > ---+-++-
> > fork | 101us | 94us (-7%) | 103us (+2%)
> > open/close | 2.9us | 2.9us (~)
Paul Rolland wrote:
>>mmap | 794us | 654us (+18%) | 822us (+4%)
>
> You mean -18%, not +18% I think.
Doh ... too many numbers flying around ... yes, -18% :)
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Rea
Hello,
> "IRQ & hd" run:
> Measurements | Vanilla | preempt_rt| ipipe
> ---+-++-
> fork | 101us | 94us (-7%) | 103us (+2%)
> open/close | 2.9us | 2.9us (~) | 3.0us (+3%)
> execve | 366
* Kristian Benoit <[EMAIL PROTECTED]> wrote:
> The numbers for PREEMPT_RT, however, have dramatically improved. All
> the 50%+ overhead we saw earlier has now gone away completely. The
> improvement is in fact nothing short of amazing. We were actually so
> surprised that we went around lookin
Missing attachment herein included.
Karim
--
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546
L M B E N C H 2 . 0 S U M M A R Y
13 matches
Mail list logo
