Machine performance

Pro Engineer Performance

We have a situation here that needs input from other users. The issue
is machine performance.

The machine in question is a brand X type machine and not sold by any
current vendors like (DELL), (SUN). It is a Pentium 1.7 Processor with
an NVIDIA graphic card with Windows XP. We use Pro Engineer 2001 with
Pro Intralink 3.2. The project this machine is used with requires no
Intralink connection. They just launch Pro-E with no workspace.

The problem occurs when they are retrieving files across the network.
According to the user it was much faster in the past. The issue
started when they replaced the mapped drive, because of failure and
now the download across the network work is really slow on just two
machines.

I have benchmarked the machine off line to get some performance data.
It still works
quite well for an older machine. I also have tried some file transfers
using another network and the file transfer was adequate and I didn't
see performance issues.

I checked with PTC and found a tan on NT_CACHED_DIRS as a config
option. It looks like this is not the issue at this time.

So I need your help, if anyone has experienced this in the past please
enlighten me.



Cmoore/Admin

 

<snip>
: The problem occurs when they are retrieving files across the network.

Can't tell, from what you've said, if it's Pro/e or the network. Does the same
performance degradation exist when simply using Explorer to copy files from the
mapped drive to a local directory? When the files have been copied across, does
Pro/e exhibit the same sluggish performance? It'd help if you could narrow it
down.

David Janes

 

We had the same problem a couple of years back. What is the speed of
your host machine storing your pro-e models? We finally determined our
host was the slow link and upgraded it to a faster pc and now the whole
system runs better. Hope this helps...

Robert L. Alexander
Sauder Woodworking Co.
Ph. 419.446.3221
Fx. 419.446.4978


-----Original Message-----
From: David Janes [mailto:.2emove]
Posted At: Wednesday, June 02, 2004 10:47 AM
Posted To: comp.cad.pro-engineer
Conversation: Machine performance
Subject: Re: Machine performance

<snip>
: The problem occurs when they are retrieving files across the network.

Can't tell, from what you've said, if it's Pro/e or the network. Does
the same
performance degradation exist when simply using Explorer to copy files
from the
mapped drive to a local directory? When the files have been copied
across, does
Pro/e exhibit the same sluggish performance? It'd help if you could
narrow it
down.

David Janes

 

David:

When we open up certain folders, in explore, the flashlight comes on
and it hunts for the files. If you setup a shortcut to the folder in
question they come up ok in explore. If we swap out machines at this
connection and a different user logs on they come across ok. IT has
two machine that act this way on the network. You can move the
machines to other connections and have that user log in and the same
problem exists. All of the other users are not seeing this issue. I
think it's a profile issue, because it follows this user. I have bench
tested this machine off the network and on the network under my
profile and it works ok. IT seems to think it is a Proe issue and I am
having a difficult time in convincing them otherwise.


Clyde...

 

You might want to consider using samba 3.0 for windows networking:

from http://www.itweek.co.uk/news/1144289
(notice the microsoft ad)
" Samba 3's scalability is as impressive as its performance. While
Windows performance scales up well initially, it then drops off quickly
as more clients access the server. In contrast, Samba 3 offered
excellent throughput up to the limit of our test, conducted on a
low-spec Intel server."


wzzl

 

: David:
:
: When we open up certain folders, in explore, the flashlight comes on
: and it hunts for the files. If you setup a shortcut to the folder in
: question they come up ok in explore. If we swap out machines at this
: connection and a different user logs on they come across ok. IT has
: two machine that act this way on the network. You can move the
: machines to other connections and have that user log in and the same
: problem exists. All of the other users are not seeing this issue. I
: think it's a profile issue, because it follows this user. I have bench
: tested this machine off the network and on the network under my
: profile and it works ok. IT seems to think it is a Proe issue and I am
: having a difficult time in convincing them otherwise.
:
:
The thing that will convince IT that it is *not* Pro/e is two things you've
already mentioned. I behaves this way for the system, without Pro/e running or
intervening in any fashion. It behaves differently for different users and for
simple system things like opening folders and copying files which, again, has
nothing whatever to do with Pro/e.

Another thing that might convince IT is to take the Pro/e, running under the
misbehaving configuration, and restore it to its default, virgin condition ~
pretty simple to do, actually. Just rename any local config.pro files, located in
or off of the shortcut's 'Start in' directory, to config.bak. This will force it
to load all the defaults which is probably how it loaded when first installed. You
can do no more with Pro/e.

More likely source of the problem is that some system service got shut off when
the first drive was failing. System Restore and restoring to a point before some
trouble started, has saved me more than once when something got inadvertently
changed that caused some misbehavior. Or you could start poking around in
Services. It's risky and I'm not even sure how configurable it is by user. But you
could at least compare your set up with that of the user who's system is acting
strangely. Then you could start checking things like are the files systems
compatible (FAT32 vs NTFS) and other stuff which is basically the job that your IT
department is reluctant to do. I guess that the most dramatic thing you could to
to convince them it's not Pro/e is to fix the problem for them. Then write a nice
report about it to one of the VPs.

David Janes

David Janes

 

Recently had a similar situation with us. What solved it for me was re-writing my search.pro file, and pointing the search paths
to a fully resolved network location, and NOT to a mapped drive. The result are day and night. If your users are searching
inside mapped drives, then give this a spin.

Regards
Jan