thread profiler - Linux remote agent

[amir_hallajpour]

I have installed the Thread Profiler on my windows machine and the remote agent on the target Linux machine. When I try to create an activity and provide an application, once I click "finish", the Thread profiler on Windows machine hangs and after several mintues, I get the following error on the remote Linux machine:

000 01/18/10 18:51:51 [ERROR] receive timeout from :1532

I've been able to successfully run the "sampling data collector" and collect data from the remote agent but I've been having trouble with the thread profiler instrumentation. Any help is appreciated.

Thanks

[TimP]

Quoting tim18

Curse this behavior of the forum setup of the day.

I've been given the recommendation by a person on the TP team to avoid the remote agent. Run the data collection locally on linux, then import the collection file into the Windows VTune. Apparently, TP won't be supported on Windows 7, even though the current VTune is updated to support event sampling on that OS.

[amir_hallajpour]

Quoting tim18

Quoting tim18

Curse this behavior of the forum setup of the day.

I've been given the recommendation by a person on the TP team to avoid the remote agent. Run the data collection locally on linux, then import the collection file into the Windows VTune. Apparently, TP won't be supported on Windows 7, even though the current VTune is updated to support event sampling on that OS.

tim18,

Thanks for the tip. I'm totally new to the Vtune, so please bear with me.

In order to run data collection locally on linux, do I need to install the Vtune for Linux on the target or there is an agent I can install to just collect data? I'm running Linux on an embedded platform so there is no GUI and I'm running Linux with minimal set of services. Is there any article explaining the process?

Thanks

[TimP]

Quoting amir.hallajpour

Quoting tim18

Quoting tim18

Curse this behavior of the forum setup of the day.

I've been given the recommendation by a person on the TP team to avoid the remote agent. Run the data collection locally on linux, then import the collection file into the Windows VTune. Apparently, TP won't be supported on Windows 7, even though the current VTune is updated to support event sampling on that OS.

tim18,

Thanks for the tip. I'm totally new to the Vtune, so please bear with me.

In order to run data collection locally on linux, do I need to install the Vtune for Linux on the target or there is an agent I can install to just collect data? I'm running Linux on an embedded platform so there is no GUI and I'm running Linux with minimal set of services. Is there any article explaining the process?

Thanks

You can bypass the remote agent, but accomplish the same steps on the linux side, by running

tprofile_cl yourapp

which instruments and puts the data collection under the /threadprofiler/ subdirectory in your current directory.

tprofile_cl is installed (by default) under /opt/intel/itt/tprofile/bin, with both the versions for 32-bit and for x86_64 "32e" linux, and corresponding tprofilevars scripts in case you want to source them to set paths.

You should be able to read the data collection and your executable into Windows VTune (not on win7). Good luck.

For myself, I prefer to use the libiompprof5.so for Intel OpenMP profiling, using LD_PRELOAD to cause a default linked executable to run with the profiling library. That has the same effect as re-linking with -openmp-profile. The data file guide.gvs is easily understood with a text viewer, or read into Windows VTune to make plots. But this usage will not be supported in the future unless there is a huge customer demand in spite of lack of documentation.

[David_A_Intel1]

Here is a trick that has worked for me in the past:

1. Restart ittserver
2. Create an activity to profile /bin/ls using the thread profiling collector and run the activity - it should work
3. Now, reconfigure the activity by removing the /bin/ls app and adding your app ("New"):
   
   
   
4. Press OK and OK and now re-run the activity.

Sometimes this makes this unsupported usage model work! ;-)