[Leiden Classical] Geen werk

[Z!oN]

Nederlandse koeien vrienden,

Deze week ben ik in Leiden geweest bij de beheerder van het project (dr. M. Somers) en na het inleveren van opdrachten heb ik hem nog even gevraagd naar de problemen met het uitgeven van werk aan verschillende clients.

In een nutshell komt het gesprek wat ik met hem heb gehad op het volgende neer:

Een van de problemen die op dit moment op het project spelen is dat de workunits aan de kleine kant zijn, zeker voor de wat snellere processoren op de markt (i7), dit is bewust gedaan om de teleurstelling bij het niet uitkeren van punten niet al te groot te laten zijn.

Een tweede probleem wat de beheerder mij heeft uitgelegd is dat de resultaten 'homogeneous redundant' moet zijn. Humogeneous redundancy komt er neer dat een pakketje twee maal gedaan moet worden door een processor van hetzelfde type, dit heeft te maken met de precisie die voor de klassieke dynamica berekeningen nodig is (dubbele precisie). De fouten achter de komma kunnen relatief snel oplopen doordat processor fabrikanten sin(), cos() en tan() functies allemaal net iets anders definiëren (dit omdat het niet is vastgeled in een IEEE-standaard. Om dus de pakketjes te kunnen verifiëren moet (om fraude te voorkomen) het pakketje dus nogmaals getest worden op een zelfde type CPU.

Om deze redundancy vol te kunnen houden en dus de resultaten ook voor wetenschappelijke doeleinden te kunnen gebruiken is door de beheerder de scheduler van BOINC aangepast om te voorspellen welke clients om werk zullen gaan vragen. Het grote nadeel van de queue in BOINC is dat de queue dus maar 500 pakketjes kan bevatten.

Een mogelijke work-around voor dit probleem waar Mark zijn gedachte over ging laten gaan is het verlengen van de simulaties, waardoor er dus minder pakketjes nodig zijn per tijdseenheid en dus de keren dat er geen pakketjes beschikbaar zijn.

Een nadeel van deze aanpak zou kunnen zijn dat er iets vaker geen punten uitgekeerd worden voor een bepaald pakketje, wat kan gebeuren als de tweede computer niet hetzelfde resultaat opleverd.

Any thoughts / commentaar.

Als er iets goed uit komt, zal ik mark emailen.

[FreezeXJ]

Meerdere queues tegelijkertijd organiseren? Eventueel de punten later alsnog uitdelen, liever dat dan dat ze als 'D.net-belasting' verdwijnen. Grotere WUs is ook niet echt een probleem (met nog geen uur atm zijn ze behoorlijk klein inderdaad), maar dan moet de credit-afdeling wel goed werken.

[JohFraEl]

Schijnbaar hebben meer BOINC projecten Homogeneous redundancy zouden die niet een oplossing weten...?

[Megaflix]

Grotere wu's zijn wat mij betreft geen probleem eigenlijk.

[Z!oN]

JohFraEl schreef op donderdag 10 september 2009 @ 20:40:
Schijnbaar hebben meer BOINC projecten Homogeneous redundancy zouden die niet een oplossing weten...?

Als ik de beheerder goed heb begrepen zij er meer dan 20 klassen cpu's in zijn boinc project, omdat zelfs verschillende types bv. pentium4 processoren een verschillende resultaat leveren. Hij heeft in ieder geval, naar eigen zeggen, een geheel eigen scheduler geschreven. Maar toch, als er een core i7 alle pakketjes weg neemt uit de queue duurt het dus tot een refresh plaats vind (uurlijks).

Het verlengen van pakketjes lijkt dus een interessante oplossing.

[Z!oN]

FreezeXJ schreef op donderdag 10 september 2009 @ 20:34:
Meerdere queues tegelijkertijd organiseren? Eventueel de punten later alsnog uitdelen, liever dat dan dat ze als 'D.net-belasting' verdwijnen. Grotere WUs is ook niet echt een probleem (met nog geen uur atm zijn ze behoorlijk klein inderdaad), maar dan moet de credit-afdeling wel goed werken.

Volgens de officiele BOINC regels is het volgens mij niet toegestaan om niet gevalideerde pakketjes alsnog te krediteren. Ik denk dat de BOINC-belasting verder wel mee valt, heb iig nog geen niet gecrediteerde pakketen gezien.