Timers and Barriers

[sebraa]

Hi,

in my current code, I use barriers for synchronization as well as the event counters to measure the clock cycles. The main idea is that at the beginning of the loop, I start the counter and at specific times inside the algorithm I only read the values into an array (to make sense of it later).

The approach works fine, but after the first barrier, some counters (depending on something, 3 to 6 cores) get stuck. Restarting them doesn't help. If I always stop/start the timers, they don't get stuck. All 16 cores run the exact same SREC file.

Is any interaction between barriers and event counters known? Why could a CLK-counter just stop counting?

Is there any information about barriers around? What is the overhead using them, I measured some 600 clocks when all cores are synchronous, but when running 5-6 barriers directly after each other, the timers only show zero differences (since reading a timer takes about 26 cycles, something is wrong there).

Best Regards,
Sebastian

[timpart]

The only documentation I'm aware of for the barrier functions is in the SDK manual. The source code is also .

The barrier code doesn't look as though it has anything to do with clocks.

For people to help you further you may need to post source code extracts, such as the declaration of the barrier array and how it is initialized and the barrier invoked. Also how you are setting up the clock(s) and using them.

Tim

[notzed]

The barriers don't use timers at all and neither should anything else in elib. Presumably the timer isn't just underflowing either. Unless it's changed since I last looked the barrier implementation in elib just uses shared memory so depends on cross-core latency. Relative to "on-core time" it's a bit expensive but nothing unreasonable.

I vaguely recall there were some bugs in the compiler at some point to do with the fpu mode switching ... which might affect the timers since they are configured using the same register. Short of some other major bug (like pointers going awry) that is all I can think of. Having the timers in the same config register wasn't ... wise.

To check it you'd have to look at a disassembly of the binary.

[sebraa]

[notzed]

[sebraa]

If I find the time, I will try to reproduce the problem. But thanks for the help.

I take much care in the few pointers I use (mostly just two memcpy()-calls to the shared memory plus array-passing), and I use -Wall to make sure they match, so the pointer usage should be fine. Interrupts are not used, neither is DMA or any other hardware-feature.

[sebraa]

[vanchiramani]

Dear Sebraa

Did you fix this problem?

Any help really appreciated!

- V Vanchinathan

[sebraa]

No. There is a problem somewhere, but instead of hunting it down, I work around the problem instead. Basically, I only measure smaller amounts of code, measure while developing and whenever I get unexpected values, I keep in mind that the measurement itself could be wrong.

[GreggChandler]

I believe that I have found a problem with the uniformity of mutex acquisition. If barriers use mutex's in their implementation, I would expect problems based upon what I have seen. viewtopic.php?f=13&t=3987