Easy Cluster DLL - Verteiltes Rechnen & mehr

[coder]

Ist schon für die nächste Version geplant.
Es gibt kein maximales Limit, theroretisch ist die Anzahl der Jobs nur durch den Arbeitsspeicher + SwapDatei begrenzt. Der Slave arbeitet immer nur mit so vielen Threads wie du vorher eingestellt hast, alle anderen Jobs warten solange in einer Queue. (siehe JobQueue)

Ich meinte eigentlich das man genau das abfragen kann, was bei ECluster_Slave_Init() als Parameter mitübergeben wird...
Ansonster freu ich mich schon aufs neue Release..

Das mit der Authentifizierung hab ich mir schon überlegt, aber hab mir dann gesagt das man das ja auch in den Service-Proceduren intern lösen kann. Also das man zuerst z.B. "MyService_Authentificate" aufrufen muss, und nur wenn der Job die gesendeten User-Daten akzeptiert kriegt man ein Handle mit dem man weiterarbeiten kann usw.... .
Gruß, Alex

So kann man das natürlich auch machen, hab ich noch gar nicht dran gedacht...

//Edit: Eine Funktion zum entfernen von Clients wär noch ganz nützlich/ergänzend (natürlich Masterseitig, Clientseitig gibs das ja schon...)

[cxAlex]

> Ich meinte eigentlich das man genau das abfragen kann, was bei ECluster_Slave_Init() als Parameter mitübergeben wird...
Hat zwar meiner Meinung nach nicht allzu viel Sinn, aber mal schauen ...

> //Edit: Eine Funktion zum entfernen von Clients wär noch ganz nützlich/ergänzend (natürlich Masterseitig, Clientseitig gibs das ja schon...
Jo, Werd ich machen. Ich werds allerdings so machen das man den Client nur Disconnecten kann und nicht Remote beenden.

Freut mich das dir mein Programm gefällt und das du es testest .

[Max_der_Held]

wow, sauber!
sehr interessantes Projekt.

Werds bei Zeit Testen.. wär schön, wenn man sowas in nen Raytracer einbauen würde, zur Leistungssteigerung.. (wie in Cinema4d)


gn8 und viel ERfolg

[coder]

>>Jo, Werd ich machen. Ich werds allerdings so machen das man den
>>Client nur Disconnecten kann und nicht Remote beenden.
So dacht ich mir das auch!

>>Werds bei Zeit Testen.. wär schön, wenn man sowas in nen Raytracer
>>einbauen würde, zur Leistungssteigerung..
Wollt ich eigentlich als kleinen Test machen, aber wie ich sehe ist ziemlich kompliziert...

[cxAlex]

Update:

• ECluster_Master_RemoveSlave(): Slave entfernen
• ECluster_Master_SetReceiveBlockSize(): Empfangspuffer-Blockgröße setzen
• ECluster_Slave_SetReceiveBlockSize(): Empfangspuffer-Blockgröße setzen
• Fehler Ausgleichs/Melderoutinen

Details:

ECluster_Master/Slave_SetReceiveBlockSize():
Setzt die Blockgröße mit welcher der Empfangspuffer resized werden soll (Standard: 64 Kb). Bei größeren Dateien vlt. sinnvoll, wenn nur ein paar Parameter übergeben werden reicht das.

Fehler - Routinen:
Wenn man einige Zehntausend sehr kleiner Jobs gleichzeitig/schnell hintereinander an den Server sendet kann es passieren das er ein Job - Packet nur teilweise läd. Um den entgegenzuwirken habe ich nun einige Überprüfungsroutinen eingebaut die versuchen den fehlenden Speicher nachzuladen. Geht das nicht weil die Daten irgentwo versumpft sind wird ein #Event_Slave_BufferUnderrun an den Slave und an den Master gesendet. Ist noch genug vom Header des Packets vorhanden sendet der Slave außerdem ein #Event_Job_Error an den Master, damit dieser den Job gegebenenfalls nochmal senden kann. Weitere Korrekturmaßnahmen sind in Planung.

Abfrage der Slave Einstellungen wird noch eingebaut, will damit noch warten weil ich eventuell noch sowas wie nen Leistungs - Index einbaue damit der Master einen idealen Slave auswählen kann, usw ... .

Download 1. Post oder:

http://www.paladiumx.forgesoft.net/publ ... r_Beta.zip

//Edit:

>>Werds bei Zeit Testen.. wär schön, wenn man sowas in nen Raytracer
>>einbauen würde, zur Leistungssteigerung..
Wollt ich eigentlich als kleinen Test machen, aber wie ich sehe ist ziemlich kompliziert...

Hoffe doch nicht das es an Easy Cluster liegt ...

[cxAlex]

Update:

• Fehler - Ausgleichsroutinen verbessert, Fehlererkennung verbessert
• Source x64 kompatibel gemacht (ende der Woche sollte mal ne x64 Version fertig sein)
• x86/x64 können nun (theoretisch ) ohne Probleme miteinander kommunizieren
• Senden/Empfangen nun speicherschonender
• Kleinen Bug behoben der die Erstellung mehrerer Slaves verhinderte
• Gleichzeitiges Senden mehrer Worker an den selben Master syncronisiert

So, allesamt Optimierungen unter der Haube.
Mit der Stabilität bin ich sehr zufrieden (Eher überlastet die Windows-Anzeige als das sich der Slave aufhängt )

Download im 1. Post oder:

http://www.paladiumx.forgesoft.net/publ ... r_Beta.zip

[coder]

>>Hoffe doch nicht das es an Easy Cluster liegt ...
Nein, überhaupt nicht...
Es fehlt nur eine Routine die ein 3D-Bild verzerrt aber ohne GPU (also TransformSprite3D() scheidet schonmal aus...)

Werd wohl was mit Bildern machen (invertieren, Greyscale, spiegeln usw.)
Mal sehen...

[cxAlex]

Puh, bin ich ja beruhigt . Einfach nur posten falls es irgentwo an Funktionalität usw. mangelt, ich mach das schon .

Mal sehen ob ich ne Linux - Version hinkriege *VM anschmeißt* ....

[cxAlex]

So. Bin grade am weiterentwickeln und hab mich auch ein wenig mehr in die Materie eingelesen. Nun frage ich mich ob eine Art Registry - Server anklang finden würde.

Konzept:

Register - Server:
Der Registry - Server ist so einfach zu benutzen wie der Rest von Easy Cluster. Einfach ECluster_Registry_Init(Port) und der alles Andere wie gewohnt per Events.

Slave seitig:
Ein Slave muss nur ECluster_Slave_BindToRegistry(Address$, Port) aufrufen und das wars. Alle anderen Befehle kommunizieren automatisch (wenn nötig) mit dem Registry Server.

Master seitig:
Benötigt ein Master nun eine Funktion kann er beim Registry - Server anfragen. Dieser vermittelt ihm (wenn vorhanden) IP und Port des nächsten Slave der diese Funktion bereistellt. Man kann sich natürlich auch alle Slaves und Enumerations iterieren lassen.




Hätte daran jemand Interresse?

[Max_der_Held]

öh ist das besser...? *denk.* (hört sich kompliziert an..) ^^ ... aber.. du bist der Profi