linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* Re: Query regarding 2.6.335 RT[Ingo's] and Non-RT performance
@ 2010-08-17  5:26 Manikandan Ramachandran
  0 siblings, 0 replies; 4+ messages in thread
From: Manikandan Ramachandran @ 2010-08-17  5:26 UTC (permalink / raw)
  To: linuxppc-dev

> ------------------------------------------------------
> > Date: Thu, 12 Aug 2010 13:53:51 -0400
> > From: Jeff Angielski <jeff@theptrgroup.com>
> > To: linuxppc-dev@lists.ozlabs.org
> > Subject: Re: Query regarding 2.6.335 RT[Ingo's] and Non-RT performance
> > Message-ID: <4C64352F.4090005@theptrgroup.com>
> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
> >
> > On 08/11/2010 06:18 PM, Manikandan Ramachandran wrote:
> > > Hello All,
> > > =A0 =A0 =A0I created a very simple program which has higher priority =
than
> > > normal tasks and runs a tight loop. Under same test environment I ran
> > > this program on both non-rt and rt 2.6.33.5 kernel. =A0To my suprise =
I see
> > > that performance of non-RT kernel is better than RT. non-RT kernel to=
ok
> > > 3 sec and 366156 usec while RT kernel took about 3 sec and 418011
> > > usec.Can someone please explain why the performance of non-rt kernel =
is
> > > better than rt kernel? From the face of the test result, I feel RT ha=
s
> > > more overhead,Is there any configuration that I could do to bring dow=
n
> > > the overhead?
> >
> > Your "surprise" is due to your definition of "performance".
> >
> > The purpose of the -rt kernels is to reduce the kernel latency. =A0This=
 is
> > important for servicing hardware. =A0Normal users find the -rt useful f=
or
> > audio/video applications. =A0Engineering and scientific users find the =
-rt
> > beneficially for servicing hardware like sensors or control systems.
> >
> > If you are just trying to run calculations as fast as you can in user
> > space, you'd be better off using the non-rt variants.
> >
> >
> > --
> > Jeff Angielski
> > The PTR Group
> > www.theptrgroup.com



 Thanks for your response.

On one hand I hear that RT-kernel is meant for reducing kernel latency on
other hand I see that there is RT-kernel overhead. So what really RT-kernel
brings to system performance?

Actually I see that latency for higher priority is more or less same for
non-rt system.

One more thing, since irqs being threaded in RT, and with CFS scheduler in
2.6.33, wouldn't we bring down system performance as CFS is O(log(n)) =A0in
nature?
 --
 Thanks,
 Manik

^ permalink raw reply	[flat|nested] 4+ messages in thread
* Query regarding 2.6.335 RT[Ingo's] and Non-RT performance
@ 2010-08-11 22:18 Manikandan Ramachandran
  2010-08-12 17:53 ` Jeff Angielski
  0 siblings, 1 reply; 4+ messages in thread
From: Manikandan Ramachandran @ 2010-08-11 22:18 UTC (permalink / raw)
  To: linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 3340 bytes --]

Hello All,

    I created a very simple program which has higher priority than normal
tasks and runs a tight loop. Under same test environment I ran this
program on both non-rt and rt 2.6.33.5 kernel.  To my suprise I see that
performance of non-RT kernel is better than RT. non-RT kernel took 3 sec and
366156 usec while RT kernel took about 3 sec and 418011 usec.Can someone
please explain why the performance of non-rt kernel is better than rt
kernel? From the face of the test result, I feel RT has more overhead,Is
there any configuration that I could do to bring down the overhead?

Processor:
----------------
processor       : 0
cpu             : 7448
clock           : 996.000000MHz
revision        : 2.2 (pvr 8004 0202)
bogomips        : 83.10
processor       : 1
cpu             : 7448
clock           : 996.000000MHz
revision        : 2.2 (pvr 8004 0202)
bogomips        : 83.10

CFS optimization:
--------------------------
# cat /proc/sys/kernel/sched_rt_runtime_us
1000000
# cat /proc/sys/kernel/sched_rt_period_us
1000000
# cat /proc/sys/kernel/sched_compat_yield
1

Test Program:
---------------------

main()
{

    int sched_rr_min,sched_rr_max;
    struct sched_param scheduling_parameters;
    struct timeval tv,late_tv;
    suseconds_t usec_diff,avg_usec = 0;
    time_t sec_diff, avg_sec = 0;
    int i;
    long count = 1;

    sched_rr_min = sched_get_priority_min(SCHED_RR);
    sched_rr_max = sched_get_priority_max(SCHED_RR);
    scheduling_parameters.sched_priority = sched_rr_min+4;
    sched_setscheduler(0, SCHED_RR, &scheduling_parameters);// Run the
process with the given priority


    for(i = 0 ; i < 150 ; i++) {
       gettimeofday(&tv, NULL);
       while(count > 0){
        //printf(".");
        count++;
       }
       gettimeofday(&late_tv, NULL);
       count = 1;
       sec_diff = (late_tv.tv_sec - tv.tv_sec);
       avg_sec += sec_diff;
       usec_diff = ( (late_tv.tv_usec > tv.tv_usec) ? (late_tv.tv_usec -
tv.tv_usec) : ( tv.tv_usec - late_tv.tv_usec));
       avg_usec += usec_diff;
       printf("Iteration #%d sec %x usec %x\n",i,(sec_diff),(usec_diff));
    }
       printf("Average of #%d sec %x usec %x\n",i,(avg_sec/i),(avg_usec)/i);
}

Partial Result of non-rt kernel:
-------------------------------------------

Iteration #140 sec 3 usec 3aef8
Iteration #141 sec 3 usec 3aefe
Iteration #142 sec 3 usec 3aee4
*Iteration #143 sec 4 usec b935b  [Why there is this periodic bump ??]
[Scheduler at work??]*
Iteration #144 sec 3 usec 3aef2
Iteration #145 sec 3 usec 3aef0
Iteration #146 sec 3 usec 3aef4
*Iteration #147 sec 4 usec b934b*
Iteration #148 sec 3 usec 3aeed
Iteration #149 sec 3 usec 3aef9

 Partial Result of rt kernel:
-------------------------------------------
Iteration #135 sec 3 usec 47328
*Iteration #136 sec 4 usec ac4fd
*Iteration #137 sec 3 usec 48b0b
Iteration #138 sec 3 usec 4738c
Iteration #139 sec 4 usec ac4d5
Iteration #140 sec 3 usec 483cb
Iteration #141 sec 3 usec 48500
*Iteration #142 sec 4 usec acc49
*Iteration #143 sec 3 usec 47c1f
Iteration #144 sec 3 usec 478c2
Iteration #145 sec 3 usec 47e48
Iteration #146 sec 4 usec ac9b5
Iteration #147 sec 3 usec 48de4
Iteration #148 sec 3 usec 46fbe
Iteration #149 sec 4 usec ac52e
Average of #150 sec 3 usec 660db

Thanks,
Mani


-- 
Thanks,
Manik

Think twice about a tree before you take a printout

[-- Attachment #2: Type: text/html, Size: 6395 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-08-17  5:26 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-08-17  5:26 Query regarding 2.6.335 RT[Ingo's] and Non-RT performance Manikandan Ramachandran
  -- strict thread matches above, loose matches on Subject: below --
2010-08-11 22:18 Manikandan Ramachandran
2010-08-12 17:53 ` Jeff Angielski
2010-08-13  2:18   ` Xianghua Xiao

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).