I encountered this and other performance issues when testing 3.4 M011. (We are not deployed yet.) This is the first I've heard that dual processors were part of the problem. My test server has only one CPU. So much for that excuse.
The good news is that M020 fixes the problems. However, we are still using Pro/E 2001. According to PTC's compatibility matrix, M020 does not support any build of Pro/E 2001, (M011 does). However, M020 is not a new build. It's a patch to M011. How can a patch reduce capability?
I asked PTC to explain this, and am still waiting for a response. I also told PTC that I would be willing to deploy M011 if the performance issues could be addressed. Still waiting.
Gerry Champoux Williams International Lead Engineer 2280 E. West Maple Road Information Technology Walled Lake, MI 48390 (248) 624-5200, x1216 (248) 960-2607 (fax) - http://www.williams-int.com Pro/E 2001, build 2004290 Intralink 3.2, build 2002270 (soon to be 3.4 M020) ProductView 7.0, build M010
-> wrote: > gurus, > > we are running intralink 3.4 cut m011 > > we have been runningit for a while and not using locate because it takes > 15 min to find one single part. > ptc says that it is a dual processor problem or something like that. > does anyone have any other ideas why locate is so slow. > > tia > > matt riggle > siemens power generation
I would answer the compatibility question by saying that M020 isn't necessarily reducing capability by dropping support for Pro/E 2001. Supporting older versions is a QA and testing issue rather than a software functionality issue. PTC (and other software companies) has to draw a line in the sand somewhere when it comes to testing different combinations of software.
I haven't heard of a dual processor problem, but 3.4 m011 runs much faster than any previous release. I have a script to check out 7 of our complete motorcycle and engine assemblies. These range in size from about 400 objects per assembly to nearly 5000. The complete process took on average 19:45 m:s on 3.3 2003290 and averages about 6:19 m:s on 3.4 m011.
Now for the important information, we had to change a few things out of the box to get good performance. I'd bet that when Gerry and Matt were searching they were using a wildcard in the search string like 123*. Straight out of the box, m011 was terrible at this kind of search. See TAN 128919, NOTE 2 for the fixes. We had to complete all 3 changes; Rule, Exact and calculate statistics, to get the optimal performance.
Kevin Holle CAD Engineer, Senior Harley-Davidson Motor Company
It's a bit self-serving to draw the line in the sand so that half of your customers are on the wrong side! That decision was made by PTC long ago, well before hardly any companies had moved to Wildfire. However, it's not like this strategy is news to any PTC customer who has dealt with them for any length of time...
There is a bug with dual Xeon processors running Server 2003 in F000 and M011 that causes the customisation part of the dataserver install to randomly hang (and the DSMU as well apparently). You have to apply to PTC for the patch see TAN129653.