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.

DM385 Cpu时常突然飙到很高



各位,DM385的板子、rdk3.8,Cpu偶尔突然飙到很高,视频会卡顿进1到2秒,在link里面打印日志,整个link会卡1800毫秒左右,本以为是程序的问题,后做了一个测验,将文件系统所有相关的程序都删掉,只跑了一个测试网络的小程序,问题依然存在。我已经解决了很多天,依然无进展。求帮助!!!

  • 你好;

           你是link模块在工作的时候,延时1.8s,还是网络在发送接收数据的时候延时;

            link 的卡是在什么link 中测试的呢?

           是否有对内核系统相关的地方做修改呢?

           有没有测试过demo板?

  • link工作的时候延迟,我在裸的操作系统上测试过,cpu依然会有高的时候,demo板也测试过,也存在这样的问题。

  • cpu 的资源占用率很高,你是说的arm的cpu还是m3或者是dsp的? 

    link是测试的哪个link呢?

    你现在的问题是平台上面只要运行程序,arm的cpu就特别的高吗?

  • cpu的占用率会高,我在多个link都测试过,cemera、iss、包括上层一点儿的编码等。cpu不是一直高,会偶尔的升高,只要cpu升高,视频流就会卡顿一下。

  • 我们目前看到的是arm的cpu会高,没有m3的。

  • 你好;

           camera iss 都是工作在m3 内部,arm 不应当会cpu 过高的,基本不会有什么影响,会不会你的测试方法有问题?

  • 1、m3的使用率多少,目前不知道,m3的使用率我不会看,是不是要在代码里查看,您是否可以指导我来查看一下?

    2、我们在裸地操作系统上跑一个测试网络的程序(这个程序我们在其他的平台上测试过,没有问题),cpu还是会升高。

    2、我们有多个工程师同时在测试,都发现了这个问题, 但视频卡顿和cpu升高是否有必然的联系,现在不知道,只是这两种现象肯定会同时出现。

    3、我们在demo板上也进行了测试,nand上烧写的是rdk3.5自带的程序,包括ubl、uboot、kernel、filesys等,依然会出现卡顿及cpu升高问题。

    以上就是我们目前所发现的情况,测试方法应该没问题。

  • guiliang chen 说:
    1、m3的使用率多少,目前不知道,m3的使用率我不会看,是不是要在代码里查看,您是否可以指导我来查看一下?

    m3的负载可以通过 MultiCh_prfLoadPrint 来查看;

    guiliang chen 说:
    2、我们在裸地操作系统上跑一个测试网络的程序(这个程序我们在其他的平台上测试过,没有问题),cpu还是会升高。

    只在a8端运行程序,cpu会突然升高? 测试程序是怎么写的?在其他平台上面测试,什么平台 ?

    demo 板, 是TI官方的板子吗?

  • 1、测试程序在8168的平台上用过,代码的实现是我们公司另一位同事写的,我还没具体看过代码。

    2、demo板是我们公司购买的,应该是官方的。

  • 您这方便通过qq或者邮件联系吗?我这真是研究这个问题好久了,进展很小!

  • 你可以把你的测试程序晒出来,可以在我的平台上面帮你测试;

    我感觉你们的测试是有问题的;或者是你们的内核修改过导致的;

  • issdrv_algVstabApi.c

    Void IssAlg_captTskUpdate(UArg arg1, UArg arg2)


    /* wait from trigger from CLM callback, i.e when timer expires */
    old_ms = Utils_getCurTimeInMsec();
    status = Semaphore_pend(gIss_captCommonObj.semUpdate,
    BIOS_WAIT_FOREVER);
    current_ms=Utils_getCurTimeInMsec();
    if((current_ms - old_ms) >50)
    Vps_rprintf(" %s:%d time %d",__FUNCTION__,__LINE__,(current_ms - old_ms));

    视频卡顿时Semaphore_pend(gIss_captCommonObj.semUpdate, BIOS_WAIT_FOREVER);大约1800ms

    cpu高只是我们在定位卡顿时发现的,我们主要想解决的是卡顿的问题。那个测试代码,在我同事那,今天可能拿不到。您是在385上从来没发现过这样的问题是吗?

  • 我们用的是iperf测试工具,我把这个测试工具放在附件了,我们测试平台式385及385的demo板,多谢。

    1. ubuntu端作为server端
        iperf -s
    2.  相机端作为client端
        iperf -c ubuntu_ip  -t 3600 -i 1
        iperf -c 192.168.3.18 -t  3600 -i 1
        测试相机与ubuntu服务器192.168.3.18之间的网络传输带宽和稳定性,连续测试1小时,每1秒统计一次带宽。
    iperf.zip
  • 各位高人,谁能帮我在385的平台上试一下,是否存在我说的问题,我想弄清楚到底是我们自己修改源码导致的,还是385芯片本身存在这样的问题,有人发现过吗???