• State Accepted Answer
  • Locked Locked
  • Replies 10 replies
  • Subscribers 120 subscribers
  • Views 6001 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
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
  • 0 Arm Employee Badge in reply to Omkar2895

    I see. So it gets slower / increasingly laggy over time.

    Typically, lag like that happens when the connection to the target is saturated, or where the target is configured to produce a significant amount of data (usually, SPE is enabled).

    To check, you haven't recently made any changes (updated version of Streamline, changed board or different configuration on target) ?

    It looks like you are connected to a remote target over TCP/IP...

    * What is the target you are running on? (OS, hardware type, number and type of cpu cores)
    * Have you tried restarting the target device?
    * What sort of counter configuration have you requested?
    * Since you are running gatord on the remote target, what command line options did you pass to launch?

    Can you launch gatord with the debug flag and capture its output during a short capture, then send it here. To do so:

    gatord -d ...your other arguments... 1> gatord.log 2>&1


    The `-d` flag triggers debug output, and the trailing `1> gatord.log 2>&1` writes to a file called gatord.log in the current directory. (If you are using android you may wish to specify `/data/local/tmp/gatord.log` instead.)

Reply
  • 0 Arm Employee Badge in reply to Omkar2895

    I see. So it gets slower / increasingly laggy over time.

    Typically, lag like that happens when the connection to the target is saturated, or where the target is configured to produce a significant amount of data (usually, SPE is enabled).

    To check, you haven't recently made any changes (updated version of Streamline, changed board or different configuration on target) ?

    It looks like you are connected to a remote target over TCP/IP...

    * What is the target you are running on? (OS, hardware type, number and type of cpu cores)
    * Have you tried restarting the target device?
    * What sort of counter configuration have you requested?
    * Since you are running gatord on the remote target, what command line options did you pass to launch?

    Can you launch gatord with the debug flag and capture its output during a short capture, then send it here. To do so:

    gatord -d ...your other arguments... 1> gatord.log 2>&1


    The `-d` flag triggers debug output, and the trailing `1> gatord.log 2>&1` writes to a file called gatord.log in the current directory. (If you are using android you may wish to specify `/data/local/tmp/gatord.log` instead.)

Children
  • 0 Arm Employee Badge in reply to Ben Gainey

    Actually, i missed your first reply, so missing some of the information that answers some of above, but if you could still answer:

    * What sort of counter configuration have you requested?
    * Since you are running gatord on the remote target, what command line options did you pass to launch?
    * Can you launch gatord with the debug flag and capture its output during a short capture, then send it here.

    Additionally, if you are happy, can you "Export" one of the capture files that show this lag and send it to us, so I can examine it.

    Thanks

  • 0 in reply to Ben Gainey

    * What sort of counter configuration have you requested?

     For CPU-Big(A73) and CPU-Little(A53) -- L1/L2 cache, CPU stall cycles, For Mali GPU counters for external reads and L2 stalls
    * Since you are running gatord on the remote target, what command line options did you pass to launch?

    I use "sudo ./gatord"

    6457.gatord.log

    I have attached the gatord log. For some reason, I am not able to upload the capture file so I have uploaded to  gdrive : drive.google.com/.../view

  • +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, " ?)

  • 0 in reply to Ben Gainey

    I have reinstalled gator and ARM Streamline it still shows the message "Session already in progress
    Failed to set up Annotations UDS parent listener. Is the socket already in use?
    " but capture is working fine now.

    I think some files might got corrupted/changed due to the reboot. Thank you for the help and support 

  • 0 Arm Employee Badge in reply to Omkar2895

    No worries. Glad it was fixed!

    That message can be ignored, it is just informative, we should really suppress or change the wording of it...