---

Wir haben mit unseren SD Arbeitsplätzen (SD 11.x) unter W2K folgendes Problem : Im Laufe des "normalen" Arbeitens hängt der SD Prozeß für den Zeitraum von 241,6 (!) Sekunden und erlangt erst danach wieder eine Freigabe der SD Lizenz. (Man kann erst danach weiterarbeiten- erfolgt mehrmals täglich. Die Maschine selbst läuft weiter) Die Anfrage an den support brachte nach vielen Telefonaten leider auch kein befiediegendes Ergebnis (soll Netzwerkproblem sein). Ich denke aber nein, weil die ME10Žs und die Unix Arbeitsplätze überhaupt keine Probleme melden.
Folgendes ist geprüpft :
- Zeitdifferenz zwischen Maschine & License  Server = ok
- Netzwerkantwort (PING) = ok
- TCP_NODELAY = 0 (1 brachte auch keine Besserung)
Das Ablegen der Daten erfolgt in einer SAMBA Freigabe auf einen LINUX Server mit einer samba version 2.2.1a

Was mich sehr verwundert, ist das bei jeder der windows Maschinen die identische Zeit für diesen "black-out" läuft.
Kennt jemand diese Erscheinung / oder kann mir einen Tipp geben ?

Danke

Tommy

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Tommy:
Wir haben mit unseren SD Arbeitsplätzen (SD 11.x) unter W2K folgendes Problem : Im Laufe des "normalen" Arbeitens hängt der SD Prozeß für den Zeitraum von 241,6 (!) Sekunden und erlangt erst danach wieder eine Freigabe der SD Lizenz,.

---

Alle solchen Faelle, von denen ich weiss, hatten tatsaechlich etwas mit der Netzwerkkonfiguration und -topologie zu tun und konnten durch Setzen von TCP_NODELAY behoben werden. Dass "ping" vernuenftige Zeiten liefert, ist leider kein Indiz dafuer, dass alles in Ordnung ist, weil der Lizenzserver anders mit TCP/IP umgeht als "ping".

Wie genau hast Du die Environmentvariable gesetzt?

Claus

[Diese Nachricht wurde von clausb am 20. Mai 2003 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Die eigentlichen Probleme bekannen damit, daß an einem Arbeitsplatz Dateien (*.pkg) nach dem Speichern nicht mehr lesbar waren , also wurde dann das paket gesplittet, um wenigstens einen Teil der Teile zu retten.
Danach wurde uns seitens des support empfohlen, die TCP_NO_DELAY auf 1 zu setzen.
Dies führte genau zu den vorher beschriebenen Effekten. Da dieser Vorgang die einzige relevante Aktion am Netz der letzten Tage vor dem auftreten des black-out war, habe ich heute früh das TCP_NO_DELAY wieder auf 0 gesetzt. Ergabnis war, daß keine black-outŽs mehr auftraten, dafür wir aber nach jedem speichern den Bildschirm löschen und die Datei neu (zum Test) laden [Tipp von ..]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Tommy,
hast Du schon mal bei den Netzwerkern nachgehakt, ob ein Router haengt? Kommt gelegentlich vor. Oder wurde einer wegen eines Defektes ausgetauscht? Aus eigener Erfahrung kann ich sagen, dass sich z.T. auch verschiedene Routerfabrikate nicht gruen sind.
Kann man den betroffenen Rechner mal in ein anderes Netzsegment haengen? Sind die DNS-Eintraege auch korrekt (Primaery und Sekundary)?
Werden Short-/Longname verwendet? Stimmen die Aliases, so dass der Lizenzserver die Antwort auf eine Lizenzanfrage auch wieder zurücksenden kann?

KJW

------------------
kjw

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Die Environmentvariable heisst TCP_NODELAY, nicht TCP_NO_DELAY. Wenn Du die letztere Schreibweise verwendet hast, dann hast Du (zumindest in OSDM) gar keine Aenderung bewirkt, denn OSDM fragt eine  Environmentvariable mit Namen TCP_NO_DELAY gar nicht ab, kann also auch nicht darauf reagieren. Ich wuesste auch nicht, wer sonst TCP_NO_DELAY abfragt.

Im uebrigen ist mir nicht klar, was TCP_NO_DELAY oder TCP_NODELAY mit dem fehlerhaften Abspeichern (oder Laden) von Dateien zu tun haben sollten. Wenn ueberhaupt, haetten solche Optionen hoechstens fuer Samba einen Sinn (wenn Samba sowas kennt) und muessten dann auf dem Sambaserver gesetzt werden.

Claus

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

@klausb,

sorry, die Antwort habe ich gestern abend zu Hause geschrieben und dabei nicht nachgeschaut, wie die Variable korrekt lautet. TCP_NODELAY ist eingetragen und steht jetzt auf 0.

@karl-josef_wernet,
unsere Anbindnung der CAD Maschinen läuft über einen Hub, der Server ist mit einem  1GBit uplink auf diesen Hub verbunden und die CAD Maschinen sind direkt mit dem Hub verbunden. Wir werden diesen noch mal unter die Lupe nehmen.
Danke für den Hinweis.

Ralf

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP