• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 102 subscribers
  • Views 646 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: Arm A72 performance

Cherry Zhou
Mastermind 22235 points
Part Number: TDA4VM

Hi team,

Here's an issue from the customer may need your help:

As per the docs, the ARM A72 frequency is up to 2GHz. While as shown in the figure below, it can actually be set to 2.7GHz:

1) And the customer has a program running on ARM A72 that executes 20% faster at 1.2 GHz than 2 GHz. So they would like to know how to make the program execute as fast as possible on the ARM?

2) Dev_A72SS0_MSMC_CLK, dev_A72SS0_MSMC_CLK, dev_A72SS0_arm_CLK_CLK, regarding the above frequencies, how to perform the program best through configuration?

Could you help check this case? Thanks.

Best Regards,

Cherry

  • 0
    TI__Expert 3845 points

    Hi, 

    Add some more information about customers' test, please refer to attached doc.

    Thanks.

    TDA4 Performance.docx

  • 0
    TI__Mastermind 22235 points

    Hi,

    Please see the attached doc from Zhang, and is there any update?

    Thanks and regards,

    Cherry

  • 0 in reply to Cherry Zhou
    TI__Mastermind 20235 points
    Hello Cherry,
    It is not safe to set the A72 or other clocks beyond their data manual limits.  The CPU is only rated for 2GHz.  Chances are good that the CPU's will fail to preform some operations properly at overclocked speeds and over a long term its reliability can be compromised.
    As to your benchmarking question.  It appears the test has been run atop Linux on the dual-core A72.   The values captured do not logically follow expectations as this code should execute faster in proportion to the CPU speed.  This execution proportionality to speed is something we consistently measure in valid tests.   I suspect your tests are not being run over a long enough time and iterations to produce a statistically correct output.  The captured differences are likely just execution time jitter.  
    Linux execution times can have a lot of jitter depending on contention with background activity.   A task can be preempted off a CPU (and losing its warm cache) disturbing its execution time, it also under some circumstances can bounce (migrating) between CPUs.  You should run some monitor program in the background to understand what is all running on your system.   I ran some quick 'dhrystone' tests and from run to run with periodic back ground disturbances I could see a 30% variation for small runs, this value drop to ~10% when averaged over a longer period.
    In the past for this kind of test I have found it useful to capture the processor hardware trace using something like Lauterbach's TRACE32.  In doing this one can clearly seen the reasons for execution disturbances.  When things like IO log prints show up its not uncommon to see a process be migrated to another core.
    Regards,
    Richard W.