Ik ben van plan om in de eerstvolgende vakantie een openmosix cluster te maken, en deze voor een weekje voor DPC te laten draaien. Aangezien de openmosix kernel niet is gemaakt om 1 thread over meerdere processors te laten draaien, moet de client dus met multithreading om kunnen gaan. dus mijn vraag is: Kan dit met de standaard linux-client? Ik heb tot nu toe slechts ervaring met de windows client, en hierbij HOEFT het niet multithreaded te zijn.
Ik zat ook al aan zo'n openmosix dingetje te denken.. probleem is alleen dat 1 enkele workunit niet door meerdere processoren gecruncht kan worden... tenminste niet door de huidige clients.
Verder zou je in het geval dat het wel kon met een probleempje zitten... Ik neem aan dat niet alle computers in je clustertje even snel zijn.... dan zou je dus een client moeten bouwen die óf naar processorsnelheid grotere of kleinere threads uitdeelt, óf een client die alvast verdergaat met threads van nieuwe workunits terwijl de tragere systemen nog met delen van de oude bezig zijn...
Al met al, in theorie kan het wel, maar er zit behoorlijk wat gedoe achter.
Verder zou je in het geval dat het wel kon met een probleempje zitten... Ik neem aan dat niet alle computers in je clustertje even snel zijn.... dan zou je dus een client moeten bouwen die óf naar processorsnelheid grotere of kleinere threads uitdeelt, óf een client die alvast verdergaat met threads van nieuwe workunits terwijl de tragere systemen nog met delen van de oude bezig zijn...
Al met al, in theorie kan het wel, maar er zit behoorlijk wat gedoe achter.
Dat is juist het doel van openmosix, het verdelen van threads over een netwerk. Als je ff zoekt op de site van openmosix, openmosix.sourceforge.net meen ik. Dan vind je ook dat het kijkt naar het type processor ed. Het is zelfs zo, dat als een processor beter is in bepaalde soort berekeningen, dat die processor daarvoor gebruikt word. Als ik een paralelle cluster zou maken, dan zou ik dus wel exact dezelfde processors moeten hebben, met het bijkomende voordeel dat je 1 thread over meerdere processors kunt verdelen (iets wat een SMP systeem dus niet eens kan, let vooral op de betekenis de eerste letter bij SMP)Carnivorous1 schreef op 10 februari 2004 @ 19:41:
Verder zou je in het geval dat het wel kon met een probleempje zitten... Ik neem aan dat niet alle computers in je clustertje even snel zijn.... dan zou je dus een client moeten bouwen die óf naar processorsnelheid grotere of kleinere threads uitdeelt
@Fear-factoR:
Jep, het is dus niet multithreaded, maar ze raden mensen met SMP systemen aan het programma meerdere keren te laden. Lijkt mij dat dit ook zo werkt bij een openmosix cluster. Bij mij booten de clients van lan, en loggen automatisch in onder een niet-zo-veel-rechten-hebbende naam, dus denk dat ik het opstartscript ff aanpas, zodat iedere client het gewoon int geheugen laadt. Of dat ik de server het meerdere keren laat laden, als node autodiscovery een nieuwe client heeft gevonden.
[ Voor 21% gewijzigd door defusion op 10-02-2004 20:29 ]
Ja maar dan nog blijft het probleem dat de huidige seti client simpelweg geen ondersteuning heeft voor meerdere threads.
Ik ben trouwens wel bekend met openmosix hoor, en ik gebruik(te) zelf ook SMP-systemen. Ik weet dus wel aardig at het nou allemaal inhoudt. Het feit dat openmosix dus processor load uitdeelt waar dat nodig is, was mij ook al bekend. Punt is dus dat de seti client er ondersteuning voor zou moeten hebben, en ik vraag me af of dit mogelijk zou zijn, aangezien het waarschijnlijk de integriteit van de resultaten niet ten goede zou komen, en het zou het de mannen van berkeley nog moeilijker maken om die resultaten te verifiëren vrees ik.
Niet dat het een slecht idee is wat je opgevat hebt, zoals ik al zei, ik heb er zelf ook al eens over nagedacht. Het zou misschien een strak idee zijn voor berkeley om deze functionaliteit eventueel in een latere versie van de boinc client te implementeren, het zou het project in ieder geval een stuk interessanter maken, en uitdagender.
Al met al is het nu denk ik niet meer de moeite waard voor berkeley of wie dan ook om voor seti1 nog een dergelijke functionaliteit in te bouwen. maar voor het idee dus
, en voor de implementatie ervan zou ik zeggen :
Ik ben trouwens wel bekend met openmosix hoor, en ik gebruik(te) zelf ook SMP-systemen. Ik weet dus wel aardig at het nou allemaal inhoudt. Het feit dat openmosix dus processor load uitdeelt waar dat nodig is, was mij ook al bekend. Punt is dus dat de seti client er ondersteuning voor zou moeten hebben, en ik vraag me af of dit mogelijk zou zijn, aangezien het waarschijnlijk de integriteit van de resultaten niet ten goede zou komen, en het zou het de mannen van berkeley nog moeilijker maken om die resultaten te verifiëren vrees ik.
Niet dat het een slecht idee is wat je opgevat hebt, zoals ik al zei, ik heb er zelf ook al eens over nagedacht. Het zou misschien een strak idee zijn voor berkeley om deze functionaliteit eventueel in een latere versie van de boinc client te implementeren, het zou het project in ieder geval een stuk interessanter maken, en uitdagender.
Al met al is het nu denk ik niet meer de moeite waard voor berkeley of wie dan ook om voor seti1 nog een dergelijke functionaliteit in te bouwen. maar voor het idee dus
Jep, vind ook dat ze dan maar iets moeten maken voor meerdere threads:p ...maja, tot dan draai ik maar gewoon meerdere clients op de server, zodat die het mag verdelen over het netwerk
Of ik moet maar zo'n lieve beowulf cluster maken
En daarbij heel wat exact dezelfde hardware kopen
(of heeft iemand enig idee hoe dit met hardware vanaf een p60 t/m enkele amd barton/tbred en P4 dingen ...nee kheb nog jammer genoeg geen SMP)
Pagina: 1