Unexpected Mesh Traffic?

[GreggChandler]

I am attempting to measure "mesh distance" from each of the 16 Epiphany III cores to external memory. The application makes 300 measurements for each core using the hardware timers. A ten second sleep based upon e_wait() executes on the core before the test. While any individual core is being tested, all of the other cores are "Idling" (that is, they have executed the "idle" instruction). While the measurements are executing on the core, the single threaded ARM application is sleeping, although I have mapped core memory, register memory, and external memory into the ARM address space. No DMA is active during the tests, and no interrupts appear to be executing. The test itself executes out of core memory.

When I measure internal memory, the standard deviation is 0, which is expected. The mesh should not be used. When I time a read after write to external memory (counting cycles until the read value matches the written value), I see a standard deviation which is up to 12 percent of the measured time, but is at times less than 1 percent of the measured value. I imagine that the read responses are contending with the read requests for mesh bandwidth. Is there a source of mesh traffic that I have not considered, or is the mesh traffic just that variable?

[sebraa]

Read requests and read replies use different meshes, so they shouldn't clash.

However, external accesses (especially reads) are much slower, so you might just see the difference between "the N'th read succeeds" vs. "the (N+1)'th read succeeds". Try to check this. Also, you can fire off multiple writes to external memory, and only then read back the results. This should be more consistent.

[GreggChandler]

[sebraa]

[GreggChandler]

[sebraa]

[GreggChandler]

[sebraa]