> However, this scheme can get stuck in a local minimum for a host: > it might initially send some cuda23 jobs which for some reason run very > slowly. > Then it would switch to cuda, and potentially never use cuda23 again. > Any ideas about this? > > -- David
Yes, it's horribly plausible. I don't know enough about compiling CUDA applications against the various SDKs to know about potential speed variations. But I have run enough CUDA projects to know that, uniquely among BOINC projects, the SETI application is exremely sensitive to the CUDA runtime DLL versions used, with any of the applications available. In speed terms, cuda23 >> cuda22 >> cuda2 - but cuda30 is no improvement on cuda23 with the current apps/hardware. But that's assuming comparable data. What happens if a cuda23 trial coincides with VLAR tasks? The speeds would be abysmal: a later test with cuda2 on normal ARs would appear to be faster (VLAR is ~4x normal runtime), but in reality cuda2 is much slower (~0.5x). Trapped in a minimum for evermore: and about half your cunching capacity lost (SETI Beta only issues cuda2 and cuda23 - the halfway house of cuda22 isn't available). Did you see my log, and earlier report? In a continuous downloading session on a single machine, I got *resend* work allocated to cuda23, and *new* work allocated to cuda - it was downloading both apps, and both sets of DLLs, at the same time, and correctly estimating the cuda23 work to be faster. So I don't think your description of 'actual' running experience tells the whole story. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
