Profiling a remote machine behind a firewall

Profiling a remote machine behind a firewall

asenjo's picture

Hi,

Hope someone can help. I'm running vtserver -p 50000 on a remote machine (bambu) which is behind a firewall (ssh.ac.uma.es). Locally I've create a tunnel with ssh: ssh -L 50000:bambu.ac.uma.es:50000 ssh.ac.uma.es. Then, locally I've my vtlec configured to use localhost as the remote machine.

So, when running the activity it's connect and run at the beginning, but then, in the remote machine I can see that the vtserver tries to open two other ports (different from the 50000 one) but it can not due to the firewall. I can not create a tunnel for these two other ports because they change from one run to the next.

Thank you very much in advance for any help.

Rafa.

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
MrAnderson (Intel)'s picture

Here are some details that might help:

VTServer listens on port 50000 for incoming requests from the client (e.g., VTune analyzer GUI).

The callgraph component on client side has special callback port 50001 that listens for status information provided from callgraph collector on vtserver side.

Other ports opened on client side are used for notifications from vtserver (e.g., VTune analyzer client opens up ephemeral ports to listen for incoming callbacks from vtserver, e.g., that sampling has finished). These ephemeral ports are dynamically generated on the fly (i.e., can range anywhere from port 1025 to 65K), and are passed from client to vtserver through messages.

Regards,

Regards, MrAnderson
asenjo's picture

Thank you Mr.Anderson, but correct me if i'm wrong: this means that even if I open a tunnel for both 50000 and 50001 ports the communication between the client and the vtserver is not going to be complete due to the firewall blocking the ephemeral ports. Besides, the ephemeral ports are dynamic so I can not set a tunnel for them in advance. So there is no solution for my problem?

asenjo's picture

Ok... for those of you with the same problem here is the workaround I'm using. Since the server is not able to notify the client that collecting has ended, you can set your vtlec client with an activity duration limit acording with what you stimate your aplication is going to need. You can also set: "Stop collection when application terminates". So, after the time out, the vtlec notifies the vtserver to send the collected data to the client. It seams it's working.

Anyway I'm still thinking in the hiden reason behind the ephemeral ports beeing dynamic (???). If they were static and known in advance a simple tunnel would do...

Thomas Willhalm (Intel)'s picture

Asenjo,
Would it work for you to start the GUI on the remote machine and only tunnel the display through the firewall? (Either by forwarding the X display or by using vnc.)
Alternatively, I found it also acceptable to collect the performance data with the command line tools and then copy the experiment data to the local machine for analysis.
Kind regards
Thomas

asenjo's picture

Thank you Thomas, but the remote GUI is tooooo slow :-(. I also wanted to avoid the manually copy solution which is kind of a pain if it has to be done for every run-check-improve-compile cycle. Thank you again.

Peter Wang (Intel)'s picture

Have you checked "SELINUX=disabled" in /etc/sysconfig/selinux? I think that you don't need do anything in client side (vtlec), but you can try "vtserver -p 80" on server again.

If you install whole product in server end, you feel vtlec slowly on GUI by using vnc - can you use vtl command to do data collection and analyze the data on local machine?

For example,

vtl activity -c sampling -d 60 -app your_program run

vtl pack pack_name

Regards, Peter

Login to leave a comment.