ifort.exe is slow on windows

[Michel]

We are migrating to XE2016 at the moment and found that ifort.exe takes 2 a 3 times longer to compile a .f file than the XE2015 compiler.

After some investigation we see that ifort.exe tries to connect to http://169.254.169.254 before closing
This seems to be a google cloud metadata server IP, but this is not available on a normal Windows workstation.
both versions (XE2015 and XE2016) try to connect, but the timeout on XE2016 is much longer.

Has anyone else experienced this slow performance with the new compiler?
I do not remember seeing this delay in the beta version.

[Kevin_D_Intel]

I know one other customer who experiences slowness with XE2016 and not XE2015. There has not been any conclusion or explanation found in that case. Maybe your findings are related.

Do you experience the slowness under the VS IDE only or under both the IDE and command-prompt?
How were you able to detect the connection attempt to that ip address?
When you said ifort tries to connect “before closing”, are you seeing the attempt at the end of the compilation or the beginning?

[Michel]

We experience the slowness on the command prompt.
I used procmon to monitor what the executable was doing and it is the last thing ifort.exe does before exiting.

[Kevin_D_Intel]

Thank you. I'll discuss your findings with Development and let you know what I learn.

[Kevin_D_Intel]

Are you using a floating license?      That final connection attempt may be related to returning the license check-out. We don't believe that ip address is associated with our compiler.

The Beta used a named-user (non-floating) license so that would avoid any delay associated with a floating license.

[Michel]

It seems to be related to the floating license.

We have a central license file with the following content:

SERVER <host> <MAC> 28518
VENDOR INTEL
USE_SERVER

The USE_SERVER causes a significant delay.
I use this with other flexnet systems and there I do not have this delay.

[Michel]

setting INTEL_LICENSE_FILE=28518@ncg-dev.ncg.nl gives the same delay.

[Kevin_D_Intel]

Thank you for the update. I would like to request some additional information from you to help our Developers analyze the issue.

First, from Section 5 of the Intel Software License Manager User’s guide, https://software.intel.com/en-us/articles/license-manager-for-flexlm-users-guide,  there are steps described for obtaining some logs from both the client-side and server-side.

I would appreciate if you can follow the suggestions in section 5.2 to set the INTEL_LMD_DEBUG environment variable to a temporary file under an Intel compiler command-prompt window on the client and then invoke the compilation on the client. I would appreciate if you do this twice and create separate logs; once when using the PSXE 2015 (15.0 compiler), and again for the PSXE 2016 (16.0) compiler. In both cases, please ensure you are also using the USE_SERVER method you mentioned earlier.

Next, from your license server, I would like to request receiving some information as outlined in section 5.3. Please collect this log after conducting the compilations above. To start with, I would like to request obtaining a copy the license file and the license server log (as noted in section 5.3) from your server system.

Due to sensitivity of details contained in the material requested, please be sure so use a private reply to me (Send Author A Message) and attach the material only to that private reply.

Thank you

[Michel]

Dear Kevin,

The licensing delay was on my workstation and I traced it down to a combination of a VirtualBox Host-Only Network adapter and messed up DNS resolving.

The problem of connecting to http://169.254.169.254 only happens on the workstation I used to test the 2016XE compiler.
I will investigate what is happening there.

[Johannes_Rieke]

Dear Michel,

I have the same problem you observed. I also use floating licenses on a central server and I also have VirtualBox installed (but not running ifort within). If you figure out how the delay can be avoided it would be grate if you can share it. I had no success so far. Writing the license server name into the hosts file (windows\system32\drivers\etc\) makes no difference. Also deactivating the VirtualBox network adapter makes no difference.

Best regards,

Johannes

[Johannes_Rieke]

Dear all,

I installed 16.0 update 1. Unfortunaly, it performs not better than 16.0. I still have a timout of two times 0.5 sec every time ifort is invoked. Still not nice in projects with many small subroutines in different files depending on a module you have to edit. A quick solution would be nice.

If the engineering teem needs detailed information, I will try to provide that.

Best regards,

Johannes

[Steven_L_Intel1]

These delays are almost always caused by a problem on the local network accessing the license server for floating licenses. Often there is a misconfigured DNS server. Johannes, are you using the compiler with a floating license (and license server) or with a "named user" license?

[Johannes_Rieke]

Hi Steve,

yes, I use a floating license. I tried to figure out whether our DNS is misconfigured, but that means to ask our global IT service. That's the point where it gets difficult. I don't believe they we tell me, that their DNS is misconfigured...

However, we use flexlm based licenses for other software tools like ANSYS and do not have a problem. For sure there a delay of 1 sec means nothing compared to calculation time...

If you can give me hints how to proof/ figure out that DNS is the problem, it would be great. The trick with putting the license server ip into the C:\Windows\System32\drivers\etc\hosts file makes no difference in license server response/ delay during compiling.

The 15 compiler family behaves very different due to different concept of aksing for licenses.

Regrads, Johannes

[Steven_L_Intel1]

Please do the following:

• Open a Fortran build environment command prompt window
• Set directory (CD) to a folder that has some Fortran file you can compile (a simple one would be best)
• Type the command SET INTEL_LMD_DEBUG=LMDLOG.TXT
• Compile the source using ifort/c
• Using Send Author a Message (for my reply), send me a private message and attach the LMDLOG.TXT file that got created

[Johannes_Rieke]

Dear all,

Steve analyzed the diag log files, which I generated the way Steve wrote above. He found out that I had a second 'USE_SERVER.lic' file in C:\Program Files (x86)\Common Files\Intel\Licenses. This second file, named  'USE_SERVER - COPY.lic', contained a reference to a server not used anymore but which is still online (legacy 32 bit OS system). In the diag log it could be seen, that this second file was also used, although it has a different name.

Good news, removing the 'USE_SERVER - COPY.lic' from the folder did the trick. Compiling is fast as used to be. :-)

It seems to be not related to the 16.0 compiler version in my case. It was a user error...

Many thanks for your help Steve. I'm a very happy user now!

Best regards, Johannes

[Michel]

Sorry Johannes that I did not reply anymore had to work on another project.
Great that your problem is solved.

The delay on my workstation went away after a few reboots, other developers do not have a delay problem.
Only the one which I first reported still tries to connect to http://169.254.169.254 before closing but it seems to be some hidden thing that is causing this. Still did not find it.

I now am looking into intermittent failures for a few developers who are connected trough a slow VPN.
They have everything local and connect to our license server. Sometimes they get "Failed to enable trusted storage check for licensing"

I have already set things like use TCP and fixed ports and enabled TCP_NO_DELAY.
I tried to change a timeout setting but changing is not enabled in the vendor deamon.
I did set DAEMON_SELECT_TIMEOUT=5 in intel.opt but is remains at the default of 1 sec.

This is from the manual:

Important • You can define the DAEMON_SELECT_TIMEOUT option only when the publisher has enabled it (that is, set the vendor variable ls_support_custom_daemon_select_timeout to 1). Best practice is for publishers to enable DAEMON_SELECT_TIMEOUT only for environments that have limited bandwidth. If this option is not enabled, the timeout value for the vendor-daemon connection is 1 second, by default.