Work is *not* preassigned to either CPU or GPGPU... one pool feed. Only the wingman getting second copy is locked to resource and platform based on where the first copy went.

Strictly by the seippel indicator, now it being the 27th, about 3 days left of full flow. Don't count on there being more in *new* work if too close to a goal or batch... buffer [or give back excess as some do].

My understanding is that the BOINC server knows to what kind of client it is sending each WU. So if the first copy of a particular one goes to, say, a GPU on a Linux machine, the second one will also be sent to a GPU on a Linux machine. The second send does NOT have to wait until the first is returned.

kateiacy has it spot on. This goes for any task/science no matter what quantity required for quorum, with exception maybe for HPF2. It does not use HR classes. (Homogeneous Redundancy). In the example of a VINA ZR, if the first copy is marked non-valid, any additional copies go to the same HR class, which can be an OS family or a CPU group (used for HCMD2 to get more matching runtimes).

[OT] On more matching runtimes... first code has been checked in at the developers for variable size task distribution, meaning that atoms could get an atom wingman and run a tasks about 6 hours, and a different sized task would go an I7, and be running about 6 hours too [no blunt cut off though like for HCMD2, Rice and CEP2... all what's in the package will be processed to completion] [/OT]

Thanks For the update! I an so glad I have been able to participate in this project!

Thanks for the update seippel.