Performance von Pro/e bei großen Baugruppen / Pro ENGINEER
By colonel 24. August 2000, 12:02

Hallo Pro/E- Experten,
ich habe eine Frage zu euren Erfahrungen mit der Performance von Pro/e bei großen Baugruppen.

Folgender Sachverhalt liegt bei uns vor.

Das laden großer Assemblies dauert ca. 2 Stunden (SGI, HP, SNI, no-Name). Der Netzwerkstrang ist mit 100MBit ziemlich schnell. Andere Applikationen laufen im selben Strang sehr schnell. Seach.pro sind optimiert. Kennst Ihr ein solches Problem.

Wichtig ist noch zu sagen, daß auf einer Acer-Workstation, die am gleichen Hub hängt, das ganze nur ca. 10 Minuten.

Ich und die Fa. Rand sind ratlos.
Kann flexlm die Ursache sein ? (Hier unterscheidet sich die Acer von den anderen Maschinen.


By zwatz 24. August 2000, 12:16

hallo,

wo liegen die Daten bzw. wo kommen sie her ?

Pro/PDM ?
Pro/INTRALINK ?
nur über NFS ?
Wieviele cuncurrent User ?

Ich hab nur wenig Erfahrung mit dem Thema, aber PDM ist bei uns _extrem_ langsam und 2 Stunden sind keine Seltenheit, wenn auch nicht üblich.

Was mir sonst noch einfällt:
Kanns mit dem lockd zusammenhängen ?
Die HPs und SGIs dürften ja unter UX laufen, die Acer wohl unter NT (Samba ?)

Gruss
Thomas

By colonel 24. August 2000, 12:50

Hallo Zwatz,

die Daten liegen als NT-Freigabe auf einem NT-Server, der auf dem gleichen HUB liegt wie die Workstations. Bei allen Workstations handelt es sich um NT-Workstations. Als Netzwerkprotokoll ist nur TCP/IP einegstellt.
Was sind lockd ?

By eis 24. August 2000, 15:09

Hallo Colonel,

wir hatten einmal ein ähnliches Phänomen. Pro/E war langsam, andere Applikationen normal schnell. Trat von 10 baugleichen Dell 410 nur bei 4 auf.
Die Lösung war damals die Konfiguration des Netzwerkadapters. Wir haben beide Seiten von Autosense auf 100Mb Halfduplex gestellt.

In der config.pro könnte man noch mit NT_CACHE_DIRS spielen. Ist aber gefährlich.

Hannes

By zwatz 24. August 2000, 15:43

Zitat:Original erstellt von colonel:

Was sind lockd ?

hi,
betrifft nur Unix; das ist ein Daemon, der im Hintergrund darüber wacht, dass dasselbe File nicht zur gleichen Zeit von unterschiedlichen Usern gegenseitig ungewollt modifiziert wird.
Trifft in dem Fall sicher nicht zu.

Der Tip mit den NICs dürfte aber recht gut sein ...

Gruss
Thomas

By candrian 24. August 2000, 17:04

Hallo colonel,
man kann die Physik m.E. nur z.T. überlisten. Fakt ist:
Durch die Referenzierung in Pro/E wird halt nunmal durch den Aufruf einer Baugruppenzeichnung die Baugruppe selbst, die Unterbaugruppen, alle Teile und der Rahmen in den Speicher geladen.
Durch Tunen an den Systemumgebung kann man einige Prozente an Performance herausholen. Oder man macht den Hardwarelieferanten (noch) glücklicher :-)
Wo man mehr herausholt, ist das Problem an der Wurzel zu packen: am Aufbau der Baugruppe selber.
Stichworte hierbei sind: Methodisches Konstruieren mit Firmenrichtlinien, Baugruppensystematiken (Aufbau nach Bottom-Up oder Top-Down, Externe Kopien, etc.).
Auch stecken innerhalb von Pro/E viele Möglichleiten: Vereinfachte Darstellung, Shrinkwrpap, etc.
Es ist vielleicht etwas mühsam, es allen Anwendern beizubringen und immer wieder vorzubeten - wenn aber am Anfang die Konstruktion sauber ist, wird automatisch die Performance besser und andere nachgeschaltete Prozesse sowieso.
Mein Credo: vorher Hirn reinstecken und nicht hinterher versuchen den Baugruppenaufruf zu optimieren. ;-)
Früher dachte ich, dass es noch einen Weg gibt - die Baugruppe nachträglich aufzuräumen! Aber mein (damals) jugendlicher Leichtsinn hat sich nach Tagen und Nächten im Fehlerbehebungsmodus gelegt.

Also noch einmal: es geht nichts über eine gut strukturiert und durchdachte Kontruktion.

Bin auf Eure Meinung gespannt!

candrian

By colonel 24. August 2000, 17:16

Toller Tip,

daß ist mir natürlich klar. Und was vereinfachte Darstellungen sind weiß ich auch. Aber warum läuft es auf der ACER sauschnell und auf den anderen langsam. Alle laden das gleiche Modell.

By colonel 25. August 2000, 07:34

Weitere Infos zu diesem Thema.

Übrigens die Tips mit den NIC's haben wirklich etwas gebracht. Aber nun noch ein paar Details. Die Acer ist die einzige Machine mit einem Intel 82558 Chipsatz onboard. Wenn man den NT-Server Netzwerkmonitor am Server startet liegt die Netzlast weit unter 10%. lädt jetzt die Acer eine große Baugruppe werden fantastische Werte erzielt. Die Acer steht auf Autosense bei der Geschwindigkeit und bei Autosense bei Halb-oder Fullduplex.

By snessler 25. August 2000, 08:02

Eine kleine Gemeinheit kann die PATH-Variable bei Windows-NT sein. 2 Gründe können hier die Performance oder Funktionalität einschränken.
1. die PATH-Variable ist länger als erlaubt und wird irgendwo abgeschnitten.
2. Pro/E ist empfindlich, wenn in den Pfadangaben DOS-Konventionen stehen (also irgendwo dieses Zeichen ~).

By ukappler 25. August 2000, 11:08

Hallo Colonell,

Nach Ihrer Beschreibung liegts wohl kaum an Pro/E, da es ja mit anderen Maschinen deutlich schneller geht.

Ich hatte auch schon schlechte Erfahrungen mit der Autosense-Einstellung an den NIC's. Trotz Normung und Standards funktionierts manchmal nicht richtig. Auf Nummer sicher geht mit einer expliziten Einstellung: 100MBit/s und Half-Duplex. So geschehen bei einer 600 Alpha unter DUX mit einer DE500. Interessanterweise gings nach einem DUX-Patch auch mit Autosense flott.

cu, Uli

By ukappler 25. August 2000, 11:12

Sehr gute Erfahrungen habe ich (gerade in einer heterogenen Umgebung) mit einem Fileserver auf Unix mit Samba gemacht. Der Sambaserver ist IMHO deutlich schneller als ein NT-Server.

Ich kenne jetzt schon zwei Firmen, die bei einer reinen NT-Umgebung, den Fileserver auf UNIX mit Samba umgestellt haben.

By colonel 18. September 2000, 08:22

Performance Problem gelöst !!!!

Hallo Pro/e-Anwender,

in Zusammenarbeit mit der Fa. Rand haben wir unser Performance-Problem gelöst.
Folgendes war Ursache für die sehr langen Ladezeiten.

Einige Workstation hatten NT-Service-Pack 5 und einige Workstation hatten Service-pack 6.

Beim Service-Pack 6 treten Probleme mit der search.pro auf. Lange Verzeichnisnamen werden hier nicht sauber erkannt. Nach Installation von SP6 ist dieses Problem behoben. Die Ladezeiten verbessern sich enorm.

Desweiteren hatten wir ein Problem in der config.pro. Hier mussten einige überflüssige Einstellungen gelöscht werden.


By Günther Weber 18. September 2000, 18:27

>> Beim Service-Pack 6 treten Probleme mit der search.pro auf.

>> Nach Installation von SP6 ist dieses Problem behoben.

Was denn jetzt ?

SP5 -> Problem, SP6 -> ok, oder umgekehrt ?

By colonel 19. September 2000, 07:07

Beim Servicepack 5 treten Probleme auf.
Das Problem ist mit Servicepack 6 behoben.

By colonel 21. September 2000, 10:26

Achtung !!!!!

Bitte verwendet Service-Pack 6a wenn ihr ähnliche Probleme habt.

Bitte nicht Service-Pack 6 verwenden

By Siegfried 20. Oktober 2000, 07:23

Zitat:Original erstellt von colonel:

SP6a ist im großen und ganzen OK.
Mit früheren Servicepacks (3...5) haben teilweise auch andere Programme Probleme.


Bitte verwendet Service-Pack 6a wenn ihr ähnliche Probleme habt.

Bitte nicht Service-Pack 6 verwenden[/B]

By sbode 03. November 2000, 17:50

Service Pack hin oder her, es geht auch wesentlich einfacher ***grins***

Es liegt an einem Fehler in der TCP/IP Implementierung von NT. Hier wird der Aufruf von Baugruppen so langsam, wenn NT in der Search.pro über Netzwerklaufwerke zugreifen muß, die auf einem NT-Rechner liegen. NT_CACHE_DIRS bringt da gar nichts, aber....

Folgender Eintrag in der registry des Servers, der die Laufwerke freigibt und dann den Serverdienst beenden und neu starten oder die ganze Machiene neu booten (tuts auch).

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

Neuen Parameter erzeugen:
Name SizReqBuf
Typ dword
Wert 00003904 hex

Schöne Grüße, die DENC AG.

P.S.: Wir können noch viel mehr...

[Diese Nachricht wurde von sbode am 03. November 2000 editiert.]

(c) 2003 www.CAD.de