That bring several questions to me :
- does RCCE_set_frequency_divider() changes the frequency of the bus ?
it changes the frequency of the tile, which includes the core including L1 and the L2 cache.
- just to be sure: the caches are on chip, so their frequency is the same as the core, right ? (So for samll data that fits in cache I understand that the cycles remain the same...)
the caches are in the tile, so the cycles will remain the same for the significant amount of data in L2 (256KB). Are you certain you are missing the cache significantly?
Thank you for you reply.
I am using two vectors of 700KB, I believe this is more than enough, I even tried to allocate memory with RCCE_shmalloc, which returns (by default) a non-cacheable address.
Try checking the performance counters to check the # of cache misses (search for discussion on accessing them, see the Pentium Processor manual for the specific counters).
Which mesh and memory clock frequencies are you using / have you checked that the core clock frequency actually changes? In my experiments, I found that frequency switching for the tiles would not work if I use any pre-defined intitialization setting other than Tile533_Mesh800_DDR800, see http://marcbug.scc-dc.com/bugzilla3/show_bug.cgi?id=110 .
Hi Philipp ... welcome back!
Is there a problem with RCCE_set_frequency divider() for other initializations?
RCCE_set_frequency divider() ==> RC_set_frequency_divider() ==> FID_word(), which returns a RC_frequency_change_words[Fdiv] and this array appears to have the values from Table 4 in the EAS. If you initialize with Mesh1600, do you think we need values from Table 5?
I put more detail in that bug 110.
I haven't looked into that topic recently, however I can't remember that I was able to successfully use frequency switching for any initialization setting other than Tile533_Mesh800_DDR800 (I might be wrong, maybe I didn't test all settings). I might be able to run tests on that in a few days, it can be checked rather quickly.