ctimer test - random failures

[cmcconnell]

[ralphmcardell]

Hello Colin,

This is an interesting observation to me because I have a mini-cluster of 4 Parallellas (3 A101040s from the 4 supplied as Kickstarter rewards and 1 P1601-DK02 - the 4th KS reward board has real problems using the Epiphany so has been placed on other duties!).

The main access method for the mini-cluster is remote access via SSH - I have only connected a monitor to the HDMI output to check what is going on while (not) booting. All boards exhibit problems occasionally when running the matmul-16 example in that some executions never finish (the host in constantly in the busy loop waiting for the Epiphany to signal it is done). Do not think I have tried the ctimer example - I should probably give it a go some time.

Although I have not been able to verify or quantify it I have had the suspicion when running repeated matmul-16 executions that the failure rate seemed to increase the more 'things' a board was doing over the network.

Other occurrences of this problem seem to have been fixed by changing PSU but so far I have tried (with various boards and collections of boards) 3 PSUs - including running the latest arrival P1601-DK02 board from one of the adapters supplied by Adapteva with no joy.

Your post has therefore made me wonder if there is in fact more to my suspicion of network activity / Epiphany problems than mere suspicion!

Regards Ralph
ps: more on my problems can be found in this thread: viewtopic.php?f=50&t=1438

[cmcconnell]

Hi Ralph,

Well, at present I'm hoping there is not a problem with my board, but rather with the ctimer test program. (For what it's worth, I have no issues with matmul, including over ssh.)

Looking at the code, The ctimer test reports a failure if any result is more than 5% different from the expected value. I'm surprised by that, as I would have thought this was an entirely deterministic test (i.e. the results should always be identical) ??

That being the case, if there is a logical reason for the results to vary, the only issue may be that the 5% tolerance that was chosen for the test is not sufficient.

So I'd be grateful for a clarification of the intended behaviour of the ctimer test, plus whether or not other people see the same variability in the results that I do.

Thanks,

[cmcconnell]

[notzed]

I haven't looked at it but I think it could only provide meaningful results for an idle system unless it had other metrics from the other memory accessing subsystems. The memory has a fixed bandwidth and it is shared amongst several systems (cpu, framebuffer, i/o dma, epiphany) many of which can saturate its capacity on their own. If its already busy then someone has to wait.

(in short, either it's only intended for an idle system, or it just isn't a very good test).

Even on-chip timing isn't completely deterministic because the round robin scheduling of the mesh - but it shouldn't vary much.

Those numbers don't look very far from expectations so I would only be worried if they failed to execute at all or were some multiple out.

[cmcconnell]

Looking more closely, the code under test does not in fact use any libraries, but it's being built with legacy.ldf, so everything will be in SDRAM.

When I get the chance I may experiment to see how it behaves with internal.ldf.