[Fuego] [PATCH 2/3] cyclictest: modify specs

Daniel Sangorrin daniel.sangorrin at toshiba.co.jp
Tue Nov 7 07:27:28 UTC 2017



> -----Original Message-----
> From: Bird, Timothy [mailto:Tim.Bird at sony.com]
> Sent: Thursday, November 02, 2017 2:53 AM
> To: Daniel Sangorrin; fuego at lists.linuxfoundation.org
> Subject: RE: [Fuego] [PATCH 2/3] cyclictest: modify specs
> 
> > -----Original Message-----
> > From: Daniel Sangorrin on Tuesday, October 31, 2017 5:29 PM
> > > -----Original Message-----
> > > From: Bird, Timothy [mailto:Tim.Bird at sony.com]
> ...
> > > Here is my testlog for a beablebone black, running cyclictest
> > > with spec 'twothreads'.  That is, the result of running
> > > job bbb.twothreads.Benchmark.cyclictest.
> > >
> > > # /dev/cpu_dma_latency set to 0us
> > > T: 0 (27542) P: 0 I:1000 C:  10000 Min:     22 Act: -885 Avg:2147483647 Max:    -
> > 126
> > > T: 1 (27543) P: 0 I:1500 C:   6690 Min:     23 Act: 3114 Avg:2147483647 Max:    -
> > 413
> > >
> > > This doesn't look right.  Did it find a bug with the Beaglebone kernel,
> > > or is something wrong with cyclictest, or are the params not right for this
> > > board?
> >
> > This is a bug in cyclictest. It seems a patch was sent after that tarball was
> > released:
> > http://www.spinics.net/lists/linux-rt-users/msg15372.html
> >
> > So let's use the git repository as you mentioned.
> 
> These results are from the test using the source from the git repository.
> So, maybe the patch is not in the stable/v1.0 release, or never made
> it in.  The code looks different enough that the patch on the mail list
> doesn't look like it would apply.  Can you check into this?
> If we need to, we can carry the patch in Fuego, but we should probably
> push the issue again if the patch didn't make it upstream.

Yes, you are right. I was able to reproduce the negative latencies on beaglebone
and noticed they were gone on the latest development branch so I have
upgraded the test to that branch.

> > # Btw, I think there was a discussion about making a new cyclictest.. Maybe it
> > would be
> > good to influence in the outputformat?
> Right now I think the output format is OK.  There are some guidelines for test
> output that we should probably provide to the authors of these kinds of test
> (not just the rt-test developers) for future reference.  This includes
> things like making them machine-parsable, and using
> markers that can be turned into unique identifiers for the test cases.
> 
> I won't personally have time to work with the rt-test upstream, but I think
> it would be good if we could influence them and at least report our needs.

Ok, if the new format was hard to parse I will let them know.

Thanks,
Daniel




More information about the Fuego mailing list