Re: cyclictest result variations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Saw latency spikes on the NXP LS1043 ARM. Single core isolation. Reported it and they fixed the spikes in their NXP BSP. Not sure if it was pushed to the community. May want to check the NXP LS1043 community pages and the cyclictest closed ticket.  I don’t recall the bug or fix, but it may have been in the cyclictest itself.



> On Mar 29, 2018, at 9:26 AM, Phil Edworthy <phil.edworthy@xxxxxxxxxxx> wrote:
> 
> Hi Luis,
> 
>> On 29 March 2018 14:54, Luis Claudio R. Goncalves wrote:
>>> On Thu, Mar 29, 2018 at 07:30:27AM +0000, Phil Edworthy wrote:
>>> Hi John, Clark,
>>> 
>>>> On 28 March 2018 16:32, Clark Williams wrote:
>>>> On Wed, 28 Mar 2018 16:56:27 +0200
>>>> John Ogness <john.ogness@xxxxxxxxxxxxx> wrote:
>>>> 
>>>>> On 2018-03-28, Phil Edworthy <phil.edworthy@xxxxxxxxxxx> wrote:
>>>>>>>> I found that cyclictest results vary from one run to another.
> [...]
>>> I did some overnight tests with 100 runs of cyclictest running for 1 minute.
>>> Stats below were calculated using stats package from
>>> http://web.cs.wpi.edu/~claypool/misc/stats/stats.html
>>> 
>>> 1. Interval fixed to 400us, not using --secalign
>>> Min: 20  Avg: 37  Max: 187  (avg of 100xMax is 134)
>>> 
>>> 2. Interval fixed to 400us, using --secalign
>>> Min: 20  Avg: 37  Max: 177  (avg of 100xMax is 150)
>>> 
>>> 3. Interval increases from 400 to 499, not using --secalign
>>> Min: 20  Avg: 37  Max: 211  (avg of 100xMax is 157)
>>> 
>>> 4. Interval increases from 400 to 499, using --secalign
>>> Min: 20  Avg: 37  Max: 202  (avg of 100xMax is 157)
>>> 
>>> While --secalign may provide more consistent results, it appears that
>>> it is not as good at identifying the worst case latency.
>>> It appears that testing different intervals is much better at
>>> identifying the worst case latency.
>> 
>> Have you used the hwlat ftrace tracer or hwlatdetector.py from rt-tests in
>> order to verify if your system have SMI-induced latency spikes? That may not
>> be part of the problem described here, but spurious SMI spikes could
>> account to some of the discrepancies.
> This is on ARM, so no SMI. There's no BIOS, nothing like that.
> 
> Thanks
> Phil
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux