All of lore.kernel.org
 help / color / mirror / Atom feed
* How to investigate different timings of 2 HW with same kernel ?
@ 2018-05-17 14:41 Ran Shalit
  2018-05-18  6:53 ` Daniel Wagner
  0 siblings, 1 reply; 4+ messages in thread
From: Ran Shalit @ 2018-05-17 14:41 UTC (permalink / raw)
  To: linux-rt-users

Hello,

We are using same BSP , Gentoo 3.18.11 rt7, with 2 different hadrwares:
1. kontron board
2. portwell board.

Both use came cpu intel i7.
Yet, the results are totally different with the same testing.

In kontron the error is 11usec, while in portwell it is 2000usec .

Testing is done using:
https://github.com/nma/preempt-rt/blob/master/test-rt.c

Is there any idea, how to start investigating such issue ?

Thank you,
Ranran

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

* Re: How to investigate different timings of 2 HW with same kernel ?
  2018-05-17 14:41 How to investigate different timings of 2 HW with same kernel ? Ran Shalit
@ 2018-05-18  6:53 ` Daniel Wagner
  2018-05-18  9:42   ` Ran Shalit
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Wagner @ 2018-05-18  6:53 UTC (permalink / raw)
  To: Ran Shalit; +Cc: linux-rt-users

Hi Ran,

> Testing is done using:
> https://github.com/nma/preempt-rt/blob/master/test-rt.c

I just noticed this:

#define MY_PRIORITY (49) /* we use 49 as the PRREMPT_RT use 50
                             as the priority of kernel tasklets
                             and interrupt handler by default */

...
         param.sched_priority = MY_PRIORITY;
         if(sched_setscheduler(0, SCHED_FIFO, &param) == -1) {
                 perror("sched_setscheduler failed");
                 exit(-1);
         }
...

The man page on sched_setscheduler:

        SCHED_FIFO    a first-in, first-out policy; and
        SCHED_RR      a round-robin policy.

        For each of the above policies, param->sched_priority specifies
        a scheduling priority for the thread.  This is a number in the
        range  returned  by calling  sched_get_priority_min(2)  and
        sched_get_priority_max(2) with the specified policy.  On Linux,
        these system calls return, respectively, 1 and 99.

Thus you should pick a priority higher then the default IRQ thread
priorities, e.g. 51 should do the trick.

Thanks,
Daniel

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

* Re: How to investigate different timings of 2 HW with same kernel ?
  2018-05-18  6:53 ` Daniel Wagner
@ 2018-05-18  9:42   ` Ran Shalit
  2018-05-23 10:40     ` Daniel Wagner
  0 siblings, 1 reply; 4+ messages in thread
From: Ran Shalit @ 2018-05-18  9:42 UTC (permalink / raw)
  To: Daniel Wagner; +Cc: linux-rt-users

On Fri, May 18, 2018 at 9:53 AM, Daniel Wagner <wagi@monom.org> wrote:
> Hi Ran,
>
>> Testing is done using:
>> https://github.com/nma/preempt-rt/blob/master/test-rt.c
>
>
> I just noticed this:
>
> #define MY_PRIORITY (49) /* we use 49 as the PRREMPT_RT use 50
>                             as the priority of kernel tasklets
>                             and interrupt handler by default */
>
> ...
>         param.sched_priority = MY_PRIORITY;
>         if(sched_setscheduler(0, SCHED_FIFO, &param) == -1) {
>                 perror("sched_setscheduler failed");
>                 exit(-1);
>         }
> ...
>
> The man page on sched_setscheduler:
>
>        SCHED_FIFO    a first-in, first-out policy; and
>        SCHED_RR      a round-robin policy.
>
>        For each of the above policies, param->sched_priority specifies
>        a scheduling priority for the thread.  This is a number in the
>        range  returned  by calling  sched_get_priority_min(2)  and
>        sched_get_priority_max(2) with the specified policy.  On Linux,
>        these system calls return, respectively, 1 and 99.
>
> Thus you should pick a priority higher then the default IRQ thread
> priorities, e.g. 51 should do the trick.


That's interesting.
I've assumed that the test founded in git is a good tool for testing
the real-time.
If this is the case, it probably means that is using a more standard
tool for rt-test like  cyclictest, would have been better.
Anyway, I will try your suggestion.
If it shows improvement than it probably mean that in that board
(portwell) there is some high IRQ inputs from some input device.
Anyway, after checking as you suggested, I'll have more information.

Thank you,
Ran

>
> Thanks,
> Daniel

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

* Re: How to investigate different timings of 2 HW with same kernel ?
  2018-05-18  9:42   ` Ran Shalit
@ 2018-05-23 10:40     ` Daniel Wagner
  0 siblings, 0 replies; 4+ messages in thread
From: Daniel Wagner @ 2018-05-23 10:40 UTC (permalink / raw)
  To: Ran Shalit; +Cc: linux-rt-users

Hi Ran,

> If this is the case, it probably means that is using a more standard
> tool for rt-test like  cyclictest, would have been better.

Yes, it rules out one of the variables in the equation. Though
cyclictest has a lot of option which is also source of confusion.

Thanks,
Daniel

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

end of thread, other threads:[~2018-05-23 10:40 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-05-17 14:41 How to investigate different timings of 2 HW with same kernel ? Ran Shalit
2018-05-18  6:53 ` Daniel Wagner
2018-05-18  9:42   ` Ran Shalit
2018-05-23 10:40     ` Daniel Wagner

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.