Please note: We are aware of an issue affecting replies on the Arm Community forums, which may not be loading as expected.

We apologize for any inconvenience and appreciate your patience while we investigate and work to resolve the issue.

Thank you for your understanding.

  • State Accepted Answer
  • Locked Locked
  • Replies 10 replies
  • Subscribers 119 subscribers
  • Views 7200 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Streamline : Lag in capture

Omkar2895

Streamline was running smoothly but now there is a lag in the streaming timeline (To complete 10 sec in the timeline of capture, it takes 20-25 seconds) even if I'm monitoring one counter. It is capturing data very slowly.

My System Specs : 

RAM: 16 GB

Processor : i5 10th gen

Free Space: 100 GB

and No other application is running in parallel.

Parents
  • +1 Arm Employee Badge in reply to Omkar2895

    Thanks.

    If I run your capture through our replayer, it renders correctly (no lag), so I don't think there is some bug being triggered in the U/I that is causing the slow down. Looking at the log, as you say, looks like a pretty typical device with small number of cores / counters, so not particularly anything that would cause some processing bottleneck.

    I wonder, if you run gator in headless mode, if it captures as expected, or if you still see some lag. You can make a local capture (to disk on the target) with something like:

    time sudo ./gatord -c configuration.xml -o capture.apc -t 25


    which will make a ~25-second long capture using the configuration.xml that gatord would have made from your last counter configuration in the U/I. The file will be written to capture.apc on the target. By running it with `time` it should tell you roughly how long the command actually took, which will be a bit over 25 seconds due to setup/tear down time (and time to authenticate with sudo). If the time to make a local capture is similar, then i'd suggest there has been some change in the target or network since it previously worked (possibly result of "but all of a sudden board got rebooted, " ?)

Reply
  • +1 Arm Employee Badge in reply to Omkar2895

    Thanks.

    If I run your capture through our replayer, it renders correctly (no lag), so I don't think there is some bug being triggered in the U/I that is causing the slow down. Looking at the log, as you say, looks like a pretty typical device with small number of cores / counters, so not particularly anything that would cause some processing bottleneck.

    I wonder, if you run gator in headless mode, if it captures as expected, or if you still see some lag. You can make a local capture (to disk on the target) with something like:

    time sudo ./gatord -c configuration.xml -o capture.apc -t 25


    which will make a ~25-second long capture using the configuration.xml that gatord would have made from your last counter configuration in the U/I. The file will be written to capture.apc on the target. By running it with `time` it should tell you roughly how long the command actually took, which will be a bit over 25 seconds due to setup/tear down time (and time to authenticate with sudo). If the time to make a local capture is similar, then i'd suggest there has been some change in the target or network since it previously worked (possibly result of "but all of a sudden board got rebooted, " ?)

Children