Meaning of an "expired" license

[Georgia_P_]

We have several licenses (covering 3 separate networks) for Intel C/C++ and Fortran; we generally support multiple versions, although the exact suite will vary across different compute clusters. This week, following up on user reports of extremely slow compilation on one network, we were able to characterize the situation as version-related, and can reproduce on another network as well. All three versions are accessing the same license keys on the same license server. The license logs do not show any license denials, i.e., it isn't a huge coincidence related to usage. We have checked for error conditions in the subnets, and on the mounted filesystems.In the simplest case, even a version check takes substantially more time for the newer releases than the older one:

Intel C/C++ 9.1.043 and Fortran 9.1.037:

> time icc -v

Version 9.1

0.000u 0.000s 0:00.09 0.0% 0+0k 0+0io 0pf+0w

> time ifort -v

Version 9.1

0.000u 0.010s 0:00.08 12.5% 0+0k 0+0io 0pf+0w

Intel C/C++ and Fortran 10.0.023:

> time icc -v

Version 10.0

0.010u 0.010s 0:10.11 0.1% 0+0k 0+0io 0pf+0w

> time ifort -v

Version 10.0

0.010u 0.000s 0:10.11 0.0% 0+0k 0+0io 0pf+0w

Intel C/C++ and Fortran 11.1.046:

> time icc -v

Version 11.1

0.010u 0.000s 0:10.18 0.0% 0+0k 0+0io 0pf+0w

> time ifort -v

Version 11.1

0.000u 0.010s 0:10.14 0.0% 0+0k 0+0io 0pf+0w

We have permanent licenses. The current license files contain the string "2009.1130" which appears to be our maintenance expiration date; due to a highly controlled scheduled for machine maintenance, there is often a delay before our renewals are actually installed and uploaded into the license manager.

Is this normal?? If not related to the maintenance expiration, can you suggest other things to trouble-shoot between versions?

[Shamla_P_Intel]

Greetings,

Are you using combined licenses? Do you have multiple expired licenses in the path? Are you using the maximum number of seats? Can you send us the log file, corresponding to the timings you have listed here?

I will need to involve the Flexlm licensing team to understand and investigate this report.

Anytime you want this thread to be marked private, let us know.

Thanks
Shamla

[Georgia_P_]

Greetings,

Are you using combined licenses?Do you have multiple expired licenses in the path?

Only in the sense that both the current (recently expired) C/C++ and Fortran license keys are in the same file, managed by the same FLEXlm daemon.

Are you using the maximum number of seats?

Nope. That's what I mean by there being no license denials in the log.

Can you send us the log file, corresponding to the timings you have listed here?

All 17 million lines? ;-)

I can extract the relevant lines for the exact timings I reported, but as that was a really simple call, it doesn't really show much. Possibly more useful, I can work on extracting blocks of info for a user doing a large Make (building a library, e.g.), showing timing from a couple of weeks ago, and this week. That will take me some time. General pattern is that a large build typically checks out a license 2-4 times per second over several minutes; this week, we see up to a 10 second gap between EACH checkout.

I will need to involve the Flexlm licensing team to understand and investigate this report.

Anytime you want this thread to be marked private, let us know.

Thanks
Shamla

[Shamla_P_Intel]

Hi,

Which OS and Architecture are you using? Which package of 11.1 compiler are you using?

Can you please set environment variable INTEL_LMD_DEBUG=1 then run icc v and send us the output.

You can also send us a new log by setting

lmutil lmswitch

Thanks
Shamla

[Georgia_P_]

Quoting - Shamla (Intel)

Hi,

Which OS and Architecture are you using? Which package of 11.1 compiler are you using?

Can you please set environment variable INTEL_LMD_DEBUG=1 then run icc v and send us the output.

You can also send us a new log by setting

lmutil lmswitch

Thanks
Shamla

Linux, RHEL 4/5 and Fedora 9

l_cproc_p_11.1.046_intel64.tar andl_cprof_p_11.1.046_intel64.tar

I can't really kick over the logfile in the environment we have here.

Good news, though, settingINTEL_LMD_DEBUG and running a variety of tests led us to a probable solution.

Turns out that 2 of us in the support team have been involved in Intel installations, which left residual

~/intel subdirectories that included spurious license information. When we deleted the entire ~/intel

subdirectory, poof! Performance returned to normal! At least for the two of us; we're waiting for

feedback from the user who originally reported it.

We are not entirely sure why our ~/intel subdirectoryinterferes cluster-wide - and are also checking

whether the user may havetheir own ~/intel, perhaps from an evaluationdownload. And we don't

understand why the slow performance showed up suddenly, and intermittently.However,I'm inclined

to consider the original question answered.

Do we have an option to tune any of the parameters revealed by that debug output?

[Shamla_P_Intel]

Hi,

Here is the reply i got from the Flexlm team

"Regarding the tuning of any parameters revealed by the debug output No, that is not possible.

The best option here is to remove unwanted license files - it seems they already tried it on some systems and it gave them desired results.

"

Thank You
Shamla