[Stampede 13] Het Grote Stampedecafe

[Bubbles]

Het is wel degelijk een custom client: je gebruikt niet de executable geleverd door de projectleiding, maar die van een third-party. En wat ik zo van het forum van [H]ard|OCP meekrijg, is het niet alleen opnieuw compileren, maar voert hij ook optimalisaties in de code door (interssant overigens dat hij die code heeft kunnen krijgen, maar dat is een andere discussie). Dit kan dus theoretisch voor nutteloze resultaten zorgen voor het project.

Verder pakt de crew hier de communicatie met POGS en [H]ard|OCP op, om zo gecoördineerd de boel af te handelen, zonder dat er dubbel werk wordt gedaan. Dus graag niet op eigen houtje bezig gaan.

[IWriteCode]

Die code is gewoon algemeen beschikbaar: https://github.com/ICRAR/boinc-magphys

[DigiK-oz]

Het lijkt me dat we het even aan de crew moeten laten inderdaad om met het projekt te communiceren. Ondertussen is een ieder vrij om te besluiten wel/niet deze client te gebruiken lijkt me? Of raadt de crew dit (voorlopig?) af?

[FreezeXJ]

Gezien de projectleiding het niet wil, lijkt het me inderdaad wel af te raden om de alternatieve client te gebruiken, in elk geval totdat we vanuit POGS zelf groen licht hebben. Ja dat is zuur, maar het kan best zijn dat we anders hun hele project-data aan het verknallen zijn... Daarnaast kan het inderdaad punten kosten...

[Evo155]

TheSKynet heeft zelf de code beschikbaar gesteld inclusief de uitleg hoe een zelf gecompilede versie te gebruiken. Kan dan haast toch geen probleem zijn?

[Justberry]

Het probleem is denk ik dat NickOfTime van HardOCP ook de code zelf heeft aan gepast, simpel opnieuw compillen gaf 60% winst, hij heeft het verder aangepast tot 350% door dingen in de code te veranderen.

[FreezeXJ]

Het lijkt erop (gezien de opmerkingen op [H]ardOCP dat NickOfTime er effectief stukken code uitsloopt, waarna de resultaten fout kunnen zijn. Gezien Kevin (projectadmin) dat ook zo hard zegt ("Please don't use the custom clients - they don't always get the right answer." ) lijkt het me op z'n best betwijfelbaar of de code nu nog bruikbaar is.

ps. beschikbaar stellen is voor geinteresseerden, en om er anderen mee te helpen. Niet om mogelijk mee vals te spelen (wat hier onbedoeld aan de hand kan zijn).

[Bubbles]

IWriteCode schreef op woensdag 09 april 2014 @ 11:13:
Die code is gewoon algemeen beschikbaar: https://github.com/ICRAR/boinc-magphys

Dat verklaart. Blijf het wel een interessante keuze vinden om dat openbaar te maken. De meeste projecten zijn er niet zo happig op die code openbaar te maken; juist vanwege het feit dat je custom clients kan krijgen die nutteloze data opleveren voor het project, en alleen maar bedoelt zijn om punten binnen te harken.

DigiK-oz schreef op woensdag 09 april 2014 @ 11:18:
Het lijkt me dat we het even aan de crew moeten laten inderdaad om met het projekt te communiceren. Ondertussen is een ieder vrij om te besluiten wel/niet deze client te gebruiken lijkt me? Of raadt de crew dit (voorlopig?) af?

De crew kan het niet verbieden (al was het maar omdat we het niet (goed) kunnen controleren). Maar aangezien er vandaag dus al vanuit de projectleiding bericht is gekomen dat de betreffende data soms waardeloos kan zijn en het verzoek het niet te gebruiken, neemt de crew hier dat standpunt over. Er is een redelijke kans dat er na pasen een nieuwe client komt die geoptimaliseerd zou zijn (grote kans dat veel van de huidige verbeteringen worden overgenomen).

Ja, het is zuur, maar zoals gezegd zijn er nu risico's aan verbonden door die custom client te gebruiken, en je levert mogelijk troep richting het onderzoek van het project.

[Dorus]

Holy cow, op mijn ene pc 9-12 mintuten per WU, op de andere 20-25. Dit tikt echt wel lekker door.

Ik snap de bezwaren wel, toch is er op het moment geen enkele rede om aan te nemen dat de nieuwe cutom client fouten bevat. Tegelijk is het gewoon een belediging voor het project om een dergelijke winst links te laten liggen. Ze willen na Pasen een poging gaan doen zelf iets te compileren. Ik zou bijna zeggen, annuleer het project dan gewoon tot Pasen, zodat mensen hun cpu cycles aan iets anders kunnen besteden, je hebt de verloren tijd binnen 3 dagen terug zodra je met een snellere client verder gaat.

[Bubbles]

Dorus806 schreef op woensdag 09 april 2014 @ 11:29:
[...] toch is er op het moment geen enkele rede om aan te nemen dat de nieuwe cutom client fouten bevat. [...]

Vandaag geschreven door projectleiding:
they don't always get the right answer.

En dat noem jij "geen enkele reden"?

[ Voor 17% gewijzigd door Bubbles op 09-04-2014 11:35 ]

[Verwijderd]

Betekent dat je resultaten "gevalideerd worden" niet dat ze goedgekeurd worden?

[enthernal]

Jammer om te horen, maar als het zo is, dan is het zo. Ik ga alvast terug naar de gewone versie.

[Bubbles]

Gevalideerd betekent dat iemand anders hetzelfde antwoord als jij hebt gehad. Als jullie allebei dezelfde fout hebben berekent, veroorzaakt door de custom client, zal dat wel valideren, maar nog steeds niet correct voor het project zijn.

[Verwijderd]

Aha, duidelijk!

[Dorus]

De enige client die bekent staat om fouten is de officiële 32 bit client. Er is alleen een algemene uitspraak gedaan dat "Onofficiële clients soms fouten resultaten geven".

[Evo155]

Snelste manier om de gewijzigde client terug te draaien is.
1. Update project
2. Reset project (Er wordt dan opieuw client software gedownload)
3. Done

[Justberry]

Voor nu hou ik het op standaard, dan weten wij dat we een goede bijdrage hebben gedaan (dat is waar dit omgaat ). Laat HardOCP maar naar de top racen als zij hiermee verder gaan.

[enthernal]

Gezien er tot nu toe nog geen uitspraak was gedaan dat het fout was stopt het voor hen mogelijks ook. Anders zijn ze inderdaad in hun eigen wereldje bezig.

[Justberry]

Voor mij is de website waar je de tasks kan zien vast gelopen. iemand anders last van?
Werkt weer- Was grandpa aan het checken- in de hele tijd dat hij heeft gewerkt : op 1 machine 27k wu valided, nu in pending 5,7k...

[ Voor 45% gewijzigd door Justberry op 09-04-2014 11:56 ]

[Witlof]

Ik ben ook weer terug aan het gaan. Blijf er wel een naar gevoel aan overhouden dat de power en effort die we er in steken door andere overschaduwt worden die een geoptimaliseerde client gebruiken (al dan niet met goede resultaten). Als je wil testen met iets, doe het dan niet op je complete serverpark als het de goedkeuring van de organisatie niet heeft.

[Witlof]

Evo155 schreef op woensdag 09 april 2014 @ 11:44:
Snelste manier om de gewijzigde client terug te draaien is.
1. Update project
2. Reset project (Er wordt dan opieuw client software gedownload)
3. Done

Weet je zeker dat dit werkt? Hier lijkt het namelijk niet goed te gaan. Blijf als een dolle WU's grazen in minuten ipv uren

[Justberry]

Ik heb de folder moeten deleten om het werkend te krijgen (dat was rede dat ik de nacht niet heb gedraaid, dacht boinc fixed het wel ik ga pitte.....)

[Bubbles]

Dorus806 schreef op woensdag 09 april 2014 @ 11:38:
De enige client die bekent staat om fouten is de officiële 32 bit client. Er is alleen een algemene uitspraak gedaan dat "Onofficiële clients soms fouten resultaten geven".

Als die melding, en alle andere morele en technische bezwaren die hier voorbij zijn gekomen, je niet kunnen overtuigen, houdt het op.

Zolang die custom client niet officiëel wordt goedgekeurd is er gewoon een aanwezige kans (hoe klein die ook lijkt) dat niemand er beter van wordt. Je houdt jezelf dan alleen maar voor de gek, puur omdat je meer punten kan scoren. Ik heb nog geen diff gezien van de code die JustInTime gebruikt en de officiele code die op GitHub beschikbaar is. We kunnen dus niet controleren of de resultaten exact gelijk zijn en tot die tijd blijft er kans voor twijfel daarover.

[Dorus]

Mmm, ik begin ook te twijfelen. Vooral omdat als ik op de pagina van grandpa kijk, er best veel foute WU's uit zijn pc rollen, en ik gok dat hij de custom client gebruikt. (Zijn CPU tijd per taak is immers significant korter dan andere).

Ik laat mijn pc's nog even doordraaien, kijken of ze ook fouten genereren, maar ik denk eigenlijk dat ik het project later vandaag stop ga zetten. Heeft eigenlijk geen zin om nog verder te gaan zolang ze geen correcte en snelle versie uitbrengen. Mochten ze daar aan toe komen, dan loop ik na pasen de verloren tijd toch binnen enkele dagen weer in.

Daar komt bij dat ik, ik gok, een paar euro aan stroom aan het project doneer. Een beetje zonde als dan blijkt dat je maar op 20% kracht hebt gedraaid, dan wacht ik liever tot we op 100% mogen.

[Viper®]

Ik lees hier 9-12 minuten, 2 uur...

Man, mijn boinc geeft mij altijd taken van 9 en 12 uur

Waar kan je trouwens je WU validaties zien ?

[ Voor 20% gewijzigd door Viper® op 09-04-2014 12:03 ]

[Evo155]

Witlof schreef op woensdag 09 april 2014 @ 11:57:
[...]

Weet je zeker dat dit werkt? Hier lijkt het namelijk niet goed te gaan. Blijf als een dolle WU's grazen in minuten ipv uren

Bij merkte werkte het zo (Ubuntu). Als ik het project reset krijgt alle software in the /var/lib/boinc-client/project/pogs.theskynet.org_pogs map een nieuwe timestamp. Daarom heb ik aangenomen dat de software opnieuw werd gedownload. Berekentijden zijn er ook naar.

[enthernal]

Ik kan bevestigen dat je het project moet verwijderen om de folder helemaal weg te hebben.

[Witlof]

Ik heb onder WIndows de BOINC manager afgesloten, de map leeg gegooid (alles erin verwijderd) en weer opnieuw de manager opgestart. Dat werkt ook. Het leek erop dat het aangepaste stukje software bleef staan bij een reset.

[ Voor 5% gewijzigd door Witlof op 09-04-2014 12:05 ]

[Dorus]

Ik ben zo verstandig geweest het bestand niet te vervangen, maar te hernoemen. Ik hoef dus waarschijnlijk alleen maar de huidige wu's te annuleren en het oude bestand terug te zetten

[Evo155]

Als dat beter werkt, kun je idd ook detachen en opnieuw attachen. Detachen verwijderd (op Ubuntu iig) de folder helemaal.

[Viper®]

Dorus806 schreef op woensdag 09 april 2014 @ 12:05:
Ik ben zo verstandig geweest het bestand niet te vervangen, maar te hernoemen. Ik hoef dus waarschijnlijk alleen maar de huidige wu's te annuleren en het oude bestand terug te zetten

Verkapte: Kijk mij eens backups maken post

[Witlof]

backup is voor mietjes

[Viper®]

Ter test: http://pogs.theskynet.org/pogs/results.php?hostid=32125

Tot nu toe 0 ongeldige. Zojuist even die custom client erop gezet.

[FreezeXJ]

Sinds wanneer? Je had 38 errors wegens aborted tasks. ps. voordat je een redelijk betrouwbare uitslag hebt, ben je 300+ WUs verder... Zeker als de error-rate maar een paar procent verschilt.

[Viper®]

Net.

Klopt, 38 errors wegens aborted tasks omdat ik de taken moet annuleren
38 fouten is iets anders als ongeldig.

Ik laat hem draaien, zodra ik een ongeldige krijg gooi ik hem er weer af.

[Justberry]

Het hoeft niet een error op te leveren, als twee custom cleints elkaar valideren en beide fout afronden ==> valided maar fout
Ik weet niet waar de fout zit dus ik gok er voor nu niet op.

[ Voor 19% gewijzigd door Justberry op 09-04-2014 12:18 ]

[thedon46]

leuk dat iedereen hier allerlei scenario's aan het verzinnen is wat er allemaal fout kan gaan.
maar ik heb nog niemand gehoord die nou zegt wat er mis is met die aangepaste files
en wat er mis kan gaan.

ik heb ook invalids gekregen voordat ik die andere client draaide dus een 1 invalid krijgen is nog steeds geen goede reden.

en hoe groot is de kans dat ik met mijn pc precies dezelfde fout maak als een andere pc.

het is nu ook gewoon koffiedik kijken zonder dat iemand is een keer echt goede uitleg geeft en niet zo van: ja maar het zou kunnen dat die een fout maakt.

[Justberry]

Als de programmeur van het team zegt "Please don't use the custom clients - they don't always get the right answer." Dan neem ik aan dat het niet om invalids aangezien die geen probleem opleveren

[Verwijderd]

"Not always"... maar als er zeg > 90% gewoon goed is, dan is de client zeker wel bruikbaar gezien de grote performance winst. De <10% foute units kunnen dan gewoon met de originele client gedaan worden, lijkt me?

[FreezeXJ]

Als je weet welke units fout zijn wel, maar dat weet je dus niet.

De projectleiding is wetenschapper, die willen 100% betrouwbare resultaten (ok, zo betrouwbaar als mogelijk), en als dat meer rekentijd kost, so be it. Ongedocumenteerde veranderingen halverwege je metingen leveren hoe dan ook problemen op, je betrouwbaarheid duikelt opeens onder het vriespunt.

Voor thuis wat super-pi-rekenwerk is het niet erg dat ie soms (eens per miljoen) een foutje maakt, het antwoord is al bekend, en je kunt het netjes controleren. Voor dit soort astrowerk willen ze zeker zijn van de antwoorden, ze zijn immers slecht nog eens te testen.

[ Voor 81% gewijzigd door FreezeXJ op 09-04-2014 12:33 ]

[cctl01]

Natuurlijk klopt het wat de programmeur zegt. Custom clients geven net als de gewone client soms een verkeerd antwoord. Daarom hebben we in de eerste plaats validatie in het leven geroepen.

[DigiK-oz]

Kan de crew misschien aan de skynet-jongens vragen om zelf "alvast" een geoptimaliseerde client te compileren? Dit i.v.m. onze huidige stampede, die hun erg veel oplevert, en wat dus factoren meer kan zijn?

Tot dat gebeurt : * DigiK-oz gaat terug naar de standaard-client

[Verwijderd]

FreezeXJ schreef op woensdag 09 april 2014 @ 12:31:
Als je weet welke units fout zijn wel, maar dat weet je dus niet.

Maar dat weet je met de originele client in principe toch ook niet dan??

[enthernal]

In feite is het relatief logisch hoor, die grandpa van HardOCP doet iets van een 5/6M per dag. Wij doen er net geen 3M en de rest nog veel minder. Zowat alle jobs worden nu dus als door grandpa geverifieerd. Dus als wij ook custom draaien, dan gaan we gewoon onder elkaar valideren. Dan slippen die fouten er door.

[ Voor 20% gewijzigd door enthernal op 09-04-2014 12:34 ]

[thedon46]

De maker van de custom client heeft aangegeven dat er 2% errors zijn.
dan doe je toch 4x valideren? met de huidige snelheid ben je dan alsnog sneller

[enthernal]

Hij heeft aan gegeven dat er 2% validation errors zijn, dat is nog iets anders

[FreezeXJ]

thedon46 schreef op woensdag 09 april 2014 @ 12:34:
De maker van de custom client heeft aangegeven dat er 2% errors zijn.
dan doe je toch 4x valideren? met de huidige snelheid ben je dan alsnog sneller

Nee, tenzij je gegarandeerd valideert tegen een originele client.
Als de nieuwe client beweert dat 2+2 = 5, en je dan tegen een nieuwe client valideert, zal je project voortaan aannemen dat 2+2=5. Wie dan nog roept dat er 4 uitkomt (want oude client) wordt doodleuk genegeerd als error. Nu Grandpa met een hele sloot computers beweert dat 2+2 = 5, wordt het leven lastig voor de projectleiding.

[IWriteCode]

Sowieso vind ik vertrouwen op het valideren door een originele client nogal laakbaar... met een gemodificeerde client 'pak-je-de-winst' en dan mogen de originele clients die geen winst hebben jouw werk nakijken...

[Verwijderd]

Wie garandeert trouwens dat de originele client alles wel goed uitrekent?

[enthernal]

niemand, maar gezien het project die zelf ondersteunt is het aan hen om dat te controleren en indien nodig aan te passen

[Verwijderd]

Dan is het ook hun zaak om resultaten die zijn uitgerekend met de custom client niet mee te rekenen als ze argwaan hebben, lijkt me, niet onze zaak.

[thedon46]

of ze moeten die mensen die ervan gebruik maken benadelen of ze moeten zelf met een beter geoptimaliseerde versie komen

[enthernal]

Als de zaken doorgaan zoals nu het geval is, dan zie ik dat inderdaad wel gebeuren. Maar het moeilijk om enkel aan de hand van de ingeleverde WU te zien welke client er gebruikt is. je kan wel sorteren op tijd, maar waar trek je dan de grens? Een lichte WU op een ietswat geklokte 3570 zal al onder de 45 zitten, een wat zwaardere WU op een hyperthreaded 3770 kan er 20 minuten over doen. Als het dan op een CPU met lager kloksnelheid is, dan komt er een overlappende zone...

Bovendien is het een hoop extra werk die het project (zelf) moet doen.

[IWriteCode]

Mja, ze hebben ook wel een beetje zelf veroorzaakt... door a> de code vrij te geven en b> door niet te (adequaat) te reageren op vragen van de maker van de gemodificeerde versie...

[Verwijderd]

Zeker gezien er nu met de Stampede zo'n grote hoeveelheid extra hardware ter beschikking wordt gesteld door de community, lijkt het me dat ze er snel extra induiken!

[Dorus]

Mmm, even een update van wat ik tot nu toe tegen ben gekomen: Mijn custom build WU's (zo zal ik ze maar even noemen), valideren allemaal, op eentje na die tegen grandpa werdt gevalideerd. Die grandpa lijkt mij een behoorlijk brokkenpiloot als ik het zelfs tussen mijn wu's tegen kom. Natuurlijk heeft hij een hoge output, maar het verbaast mij toch dat mijn custom wu tegen hem fout gaat, als er een fout in de client zit zou je verwachten dat hij diezelfde fout maakt en mijn resultaat goedgekeurd was.

[Justberry]

Grandpa is dubbel zo snel als ons nu, dus de kans dat hij jou valideerd is groot. Dat er 1 fout is uit gekomen hoeft geen bewijs te zijn want niet elke wu hoeft fout berekent te worden. Maar zolang wij niet weten wat de fout, waar hij vandaan komt en de leider zegt dat het voor komt...

Maar ik hoop wel dat het pogs team zich hierin verdiept gezien de giga voordelen/nadelen

[ Voor 13% gewijzigd door Justberry op 09-04-2014 13:13 ]

[Verwijderd]

Dat de leider zegt dat er mogelijk fout wordt uitgerekend, komt op mij over als slechts een vermoeden, maar is niet overtuigend. Misschien weten ze het zelf ook nog niet precies...

[Witlof]

Ik laat voorlopig nog even mijn parkje POGS draaien tot er een duidelijk en goed verhaal ligt over dit. Ik vind het persoonlijk erg jammer dat er veel energie (letterlijk en figuurlijk) ingestoken wordt en vervolgens door (al dan niet) legale cheats de competitie in mijn ogen vervalst wordt. De stampede wordt er zo ook niet beter op als er gebruikers zijn die het wel gebruiken en de grote meerderheid (waarschijnlijk) niet.

Ik zie trouwens bij mijn WU's normaal dit staan: fitsedwrapper v3.40
Als ik wat scroll en kijk bij computers met die custom build staat er dit: fitsedwrapper Anonymous platform (CPU)

Dus volgens mij is het wel duidelijk terug te halen en uit de stats te halen

[bassiexp]

Een hoop Wu's van grandpa zijn al ongeldig verklaard voordat ze met de zwaar aangepaste versie bezig waren. Ik zou bijna zeggen dat hij een paar stukke cpu's in zijn servers heeft zitten.

Zelf hou ik het nog maar even bij de orginele software. Op pasen zie ik wel wat er uitkomt

[Dorus]

ik zie zowel fitsedwrapper v3.40, fitsedwrapper v3.41 als fitsedwrapper Anonymous platform sinds ik met de nieuwe client bezig ben. Die laatste zit vooral op de meer recente wu's, de eerste stapel heeft nog steeds fitsedwrapper v3.40. Ik moet wel opmerken dat ik alleen de lopende wu's geanuleerd had, en niet wat in mijn buffers stond.

Oveigens gaat er met de custom build nog iets anders fout, hij schat in dat een wu 12 uur duurd (ipv 20 minuten), en download daarom maar 10 wu's vooruit, waardoor ik dus elke 20 minuten zonder wu's zit.

[Bubbles]

Verwijderd schreef op woensdag 09 april 2014 @ 13:13:
Dat de leider zegt dat er mogelijk fout wordt uitgerekend, komt op mij over als slechts een vermoeden, maar is niet overtuigend. Misschien weten ze het zelf ook nog niet precies...

Die kans bestaat zomaar ja. Des te meer reden om er niet meer door te gaan: mocht het inderdaad blijken dat het data oplevert waar het project niets mee kan, dan blijft de schade voor het project beperkt. Zij zullen eerst zelf grondig die aangepaste client moeten testen om er 100% zeker van te zijn, en niet minder dan dat dat het dezelfde resultaten oplevert. En dan is het goed mogelijk dat het voor 99.9% hetzelfde is, maar voor het onderzoek mag je gewoon geen foute data gebruiken, omdat dat je resultaten zal beïnvloeden en daarmee de uitkomst dus niet meer te vertrouwen is.

En ja, er zijn dingen slordig gelopen, danwel fout gedaan door de projectleiding (niet snel reageren, niet eerder een geoptimaliseerde client gebruiken, source beschikbaar maken (waar ik al eerder mijn bedenken over heb verteld)), maar dat is nog geen rechtvaardiging om hiermee door te gaan.

Voor de gebruikers is het vervelend, zoniet uitermate zuur, dat de puntentelling niet meer eerlijk lijkt te verlopen, maar met een vriendin die bezig is met promovatie-onderzoek begrijp ik maar al te goed wat voor een impact mogelijke corrupte data kan hebben voor de onderzoekers: hun complete onderzoek kan in twijfel worden getrokken, sponsoring of beursen kunnen worden ingetrokken, banen kunnen op het spel komen te staan. Dat is wel even wat serieuzer dan "hunnie krijgen meer punten dan ik".

Witlof schreef op woensdag 09 april 2014 @ 13:14:
[...]
Ik zie trouwens bij mijn WU's normaal dit staan: fitsedwrapper v3.40
Als ik wat scroll en kijk bij computers met die custom build staat er dit: fitsedwrapper Anonymous platform (CPU)

Dus volgens mij is het wel duidelijk terug te halen en uit de stats te halen

Nope. Als ik bij mij bij het systeem kijk waar ik mee heb getest, zie ik gewoon fitsedwrapper v3.40 staan. Wat dat betreft dus niet te onderscheiden van het origineel.

[Witlof]

Das wel jammer dan

Maar goed, we wachten nog maar af. Ik draai nog even door. Wie weet komt het nog goed

[IWriteCode]

Ik krijg door dit hele gebeuren wel steeds een onbehaaglijker gevoel bij dit project.

Ik heb nu 1 invalid block... en 6 'Validation inconclusive' blocken... terwijl ik niet heb 'gerommeld' met clients oid.

[ Voor 4% gewijzigd door IWriteCode op 09-04-2014 14:04 ]

[enthernal]

Dat komt zoizo na verloop van tijd, ik heb er ook eentje dat ongeldig is, op 3000+ geldige

Enuh; ICRAR hebben we ondertussen ook al onder voeten gelopen

[ Voor 26% gewijzigd door enthernal op 09-04-2014 14:29 ]

[DPCKippie]

Iemand toevallig ook bezig met het compileren van een 32-bit client?
Wil deze dan wel testen op mn intel core 2 duo met..... *tromgeroffel* Windows XP

[DPCKippie]

Uiteraard op eigen risico.....
Indien niet gewenst uiteraard niet.

[Viper®]

http://pogs.theskynet.org/pogs/results.php?hostid=32125

nog steeds 0 ongeldige en 38 fout, maar die had ik al.

Wel is die ongeveer 6 tot 8 maal sneller

[DukeBox]

DPCKippie schreef op woensdag 09 april 2014 @ 14:42:
Iemand toevallig ook bezig met het compileren van een 32-bit client?
Wil deze dan wel testen op mn intel core 2 duo met..... *tromgeroffel* Windows XP

Ik heb hem wel voor 32bit ARM onder linux maar vooralsnog zie ik niet veel performance verschil.

[Bubbles]

DPCKippie schreef op woensdag 09 april 2014 @ 14:43:
Uiteraard op eigen risico.....
Indien niet gewenst uiteraard niet.

Vanuit de crew dus het advies niet die custom clients te gebruiken, totdat er vanuit de projectleiding een groen licht wordt gegeven (maar dan zal er waarschijnlijk wel gewoon van daaruit een nieuwe client worden uitgegeven).

[DPCKippie]

Oki, thanks.

[bassiexp]

[H]ard | OCP heeft het nieuws ook meegekregen
http://hardforum.com/show...1040755738&postcount=1824
Eens kijken wat ze er mee gaan doen.

[DigiK-oz]

Hun "grote jongen" heeft wat extra info gevraagd op het skynet forum. Hij lijkt wel te willen teruggaan naar de reguliere client, maar vraagt om wat duidelijkheid. We'll see.

[Viper®]

Goed verhaal

Ik zit inmiddels op 131 geldig met nog steeds 0 ongeldige.

[Bubbles]

Viper® schreef op woensdag 09 april 2014 @ 16:59:
Ik zit inmiddels op 131 geldig met nog steeds 0 ongeldige.

Impliceer je daar mee dat je nog steeds de custom client gebruikt?
Zoals eerder aangegeven, het kan zijn dat gevalideerd niet per se daadwerkelijk goed voor het project betekend

[Viper®]

Bubbles schreef op woensdag 09 april 2014 @ 17:10:
[...]
Impliceer je daar mee dat je nog steeds de custom client gebruikt?
Zoals eerder aangegeven, het kan zijn dat gevalideerd niet per se daadwerkelijk goed voor het project betekend

Correct. Ik had vanmiddag de aangepaste bestanden op 1 machine gezet om te kijken wat het verschil is in verwerking, maar ook of ik validatie fouten zou krijgen, aangezien de originele client tot nu toe 0 validatie fouten gaf.
Inmiddels begrijp ik wel dat de validatie alleen werkt zoals verwacht als de validerende partij een default configuratie betreft. Zal zometeen weer de oude bestanden terugzetten, er was vanmiddag nog niet zo'n ophef over, maar de situatie is nu wat concreter.

[DukeBox]

Ik heb 40 units met de oude en met de nieuwe client gedaan (backup gerestored) de hashes van de uitkomst zijn 100% gelijk.

[Justberry]

Ik lees nu van NickOfTime dat de linux versie fast math gebruikt (nu nieuwe update zonder) dat creëerde waarschijnlijk fouten. Maar de windows versie alleen een recompile was (all is die als nog verbazing wekend sneller)

[Dorus]

Ik lees zonet dat Grandpa een overgeklokte client gebruikt, en minder fouten heeft met de custom client dan de standaard client. Het lijkt mij geen onredelijke verklaring waardoor hij zoveel fouten heeft. Ik heb zelfs fouten tegen zijn wu's gevonden met de custom client wu's van mijzelf.

[Verwijderd]

DukeBox schreef op woensdag 09 april 2014 @ 17:19:
Ik heb 40 units met de oude en met de nieuwe client gedaan (backup gerestored) de hashes van de uitkomst zijn 100% gelijk.

Begrijp ik goed dat je 40 units 2x hebt uitgerekend, 1x met de oude, 1x met de nieuwe en dat de uitkomsten volledig identiek zijn?

In dat geval ziet dat er goed uit voor de nieuwe client

[enthernal]

Ik hoop ook dat ze van pogs de zaken wat duidelijker uit klaren. Zelfs al wordt enkel die 60% recompiled versie toe gestaand, het is nog steeds een hoop

Een topic om zeker in het oog te houden.

[bassiexp]

Ik wacht nog maar even met de nieuwe geoptimaliseerde client.
Hoop dat er zowiezo nog een reactie van Kevin zelf komt.

Ik ben nou wel even aan het kijken geweest met het verschil tussen windows en linux.
ondanks dat ik op de windows 300+ units en op linux nog maar 29 units heb gedaan zie ik wel dat linux ongeveer 10% sneller is.

Dit wel in gedachte houden dat dit op mijn esxi server is, waar ook mijn spotweb en sabnzbdplus server staan. En nog wat vm's die incidenteel actief zijn.

Hier de gegevens in google spreadsheet. Hier voeg ik later ook de andere afgeronde linuxtaken aan toe voor een betere sampleset.
https://docs.google.com/s...w7j7iPW8/edit?usp=sharing

Dit komt dus wel redelijk overheen met de 8% waar Enthernal het over had.
Het zat toch niet zo goed in mijn geheugen. De linux vm was 8% trager in Enthernal testje

[ Voor 14% gewijzigd door bassiexp op 09-04-2014 18:13 ]

[Bubbles]

DukeBox schreef op woensdag 09 april 2014 @ 17:19:
Ik heb 40 units met de oude en met de nieuwe client gedaan (backup gerestored) de hashes van de uitkomst zijn 100% gelijk.

Dit zijn interessante testen en resultaten, maar dit is iets wat ook door de POGS organistatie gedaan moet worden, en dan op grotere school. Zoals ik al eerder zei, moeten resultaten voor onderzoek 100% betrouwbaar zijn. Dat kunnen ze alleen garanderen als ze de boel zelf hebben gebouwd, of zo grondig hebben getest dat het statisch verantwoord is (maar dan praat je al gauw over een zekerheid van 99,9995%), wat enorme bergen werk betekend (zo richting de miljoen tests)

Verwijderd schreef op woensdag 09 april 2014 @ 18:01:
[...]

Begrijp ik goed dat je 40 units 2x hebt uitgerekend, 1x met de oude, 1x met de nieuwe en dat de uitkomsten volledig identiek zijn?

In dat geval ziet dat er goed uit voor de nieuwe client

Dat zou het zeker zijn, maar totdat er een GO komt van de projectleiding, blijft ons advies staan.

bassiexp schreef op woensdag 09 april 2014 @ 18:02:
Ik wacht nog maar even met de nieuwe geoptimaliseerde client.
Hoop dat er zowiezo nog een reactie van Kevin zelf komt.

Ik ben nou wel even aan het kijken geweest met het verschil tussen windows en linux.
ondanks dat ik op de windows 300+ units en op linux nog maar 29 units heb gedaan zie ik wel dat linux ongeveer 10% sneller is.

Dit wel in gedachte houden dat dit op mijn esxi server is, waar ook mijn spotweb en sabnzbdplus server staan. En nog wat vm's die incidenteel actief zijn.

Hier de gegevens in google spreadsheet. Hier voeg ik later ook de andere afgeronde linuxtaken aan toe voor een betere sampleset.
https://docs.google.com/s...w7j7iPW8/edit?usp=sharing

Dit komt dus wel redelijk overheen met de 8% waar Enthernal het over had.
Het zat toch niet zo goed in mijn geheugen. De linux vm was 8% trager in Enthernal testje

JustInTime liet eerder ook al weten dat hij de linux client verder had kunnen optimaliseren. Maar dat kon nog wel eens aan de -fast-math flag gelegen hebben, wat de precisie van de uitkomsten niet bevoorderd.

[bassiexp]

Bubbles schreef op woensdag 09 april 2014 @ 18:33:
[...]
JustInTime liet eerder ook al weten dat hij de linux client verder had kunnen optimaliseren. Maar dat kon nog wel eens aan de -fast-math flag gelegen hebben, wat de precisie van de uitkomsten niet bevoorderd.

Even voor de goed orde. Dit is beide gewoon met de standaard applicatie van theSkynet.
Ik heb met beide niks anders gedaan dan Boinc installeren, project toevoegen en maximaal gas laten geven.
Ik had de linux VM wel voor dat doeleind opgezet maar ik wou eerst even een aantal WU's draaien met linux voor deze getallen. Als vanuit Skynet een ok komt op een bepaalde optimized app, of een vanuit skynet zelf dan kan ik die er dan ook nog mee vergelijken.

[ Voor 29% gewijzigd door bassiexp op 09-04-2014 18:42 ]

[DukeBox]

Toch is het onzin.. ze gebruiken de zelfde source alleen wordt er in mijn geval optimalisatie flags gebruikt voor bepaalde cpu instructie sets bij het compileren. Iets wat ze (=pogs crew) eigenlijk standaard al hadden moeten doen.

Het zou in mijn geval voor het eerst zijn dat code welke op een andere manier/compiler gecompileerd wordt iets op een andere manier gaat werken. Ik compileer ook altijd mijn eigen kernels en ook daar heb ik nog nooit verschillen gehad (buiten performance) met de pre-compiled distributies.

[ Voor 3% gewijzigd door DukeBox op 09-04-2014 18:39 ]

[Bubbles]

Ik heb ook wel eens een stuk code gebouwd wat prima werkte. Toen kwam ik erachter dat ik in de compiler wat optimalisatieflags kon toevoegen. Programma werd inderdaad sneller, maar ik had ook ineens last van unexpected behaviour. Flags uitzetten zorgde ervoor dat het weer correct werkte. Dus zelfs dat kan uitmaken.

[Justberry]

In linux had hij meer dan alleen recompile gedaan, hij vertelt zelf ook dat hij aan de code heeft gewerkt (Zoals de code aanpassen dat in plaats van 12000 keer zichzelf optellen bij zichzelf, het getal met 12000 vermenigvuldigen)

[enthernal]

@bassiexp: Ik deed die test omdat ik ook een vermoeden had dat linux sneller was Mijn VM was echter gewoon op een windows PC met virtualbox, naar performance toe niet de beste keuze, dus kan het verschil volledig verklaren

[Justberry]

Wegens all het testen en reseten in vm buiten vm etc.. heb ik 600 taken gekilled/gedumpt, terwijl ik nog maar 580 taken heb gedaan

[bassiexp]

Justberry schreef op woensdag 09 april 2014 @ 19:25:
Wegens all het testen en reseten in vm buiten vm etc.. heb ik 600 taken gekilled/gedumpt, terwijl ik nog maar 580 taken heb gedaan

Dan heb je ook een grote buffer ingesteld. Ik heb een buffer van 0,1 - 0,5 dagen en ik kom niet te kort.
De server wordt ook gehost bij amazon welke automatisch meer capaciteit bijschakeld mocht dat nodig zijn.
Dus ik verwacht niet zo heel veel problemen. Scheelt ook een hoop met validation pending als iedereen een kleinere buffer aan zou houden.

[Justberry]

Hij hoort voor 1 dag werk op te halen maar doet het vaak voor 2.

[klepje]

[H]ard|OCP heeft flink bij geknald zie ik, vandaag een daily credits van 4,133,808.. Ik hoop wel dat er duidelijkheid komt van POGS zelf wat betreft de custom client

[Justberry]

Grandpa doet in zijn 1tje 6mill, vandaag

[DukeBox]

Justberry schreef op woensdag 09 april 2014 @ 18:45:
In linux had hij meer dan alleen recompile gedaan,

Ja, maar ik niet..

[Justberry]

DukeBox schreef op woensdag 09 april 2014 @ 21:15:
[...]

Ja, maar ik niet..

Gebruik je een eigen compiled versie?

[DukeBox]

Ja, moest wel want mijn OS wordt standaard niet ondersteund.

[R0SSI]

Damn, ik heb dus wel even wat gemist... Jammer dat het zo gaat en er nog geen duidelijkheid is vanuit Pogs. Mijn machine gaat gewoon rustig door met wu's kauwen

[enthernal]

welk OS/architectuur gebruik je dan wel? Ik zit echt wel te wachten tot er groen licht komt, als het gewoon hercompileren is, dan duurt het wel erg lang (pasen).

[Bubbles]

Tel 2 posts van mij bij elkaar op, daar ligt je antwoord waarom dat niet zo snel kan. Hint: 100% zekerheid en mogelijke resultaatverschillen bij gebruik van optimalisatieflags. Los van het feit dat het natuurlijk ook prima mogelijk is dat de developers (als het er al meerdere zijn) mogelijk ook nog andere deadlines hebben en nu gewoon niet de tijd hebben om er goed naar te kijken.

R0SSI: TL;DR versie: er komt na pasen waarschijnlijk een nieuwe client die geoptimaliseerd is, de rest is nu feitelijk niet belangrijk. Nothing to see here, move along.

[ Voor 3% gewijzigd door Bubbles op 09-04-2014 23:05 ]

[enthernal]

wat kan ik zeggen, als een belg niet klaagt...