Some WU's are faster than others. I have had some that ran for twenty minutes and then some that would run for several hours. The same on Android devices; some would complete in a dew hors whereas others would run for 10 hours. The current sets could just take longer and may not necessarily be an indication that all future ones will be that long. With this project allowing mobile devices, having long WU's does not bode well for them.

"With this project allowing mobile devices, having long WU's does not bode well for them."

This is the reason the techs are holding back the long running batches to the end, so the Androids can participate. When the really long ones are run, it might come to the hard decision to exclude this platform, but then maybe by then they've found a way to subdivide a single molecule run across multiple tasks. Hopes for something like that is really small... it's like sending one part to Host1, then waiting on the result to send to Host2 for the next part. A sequence like that really builds up active results underway [explodes the Result Status pages numbers, slowing down the system... was that not so with HCMD2?]

If my tablet is 'fast', in relative terms, longest logged since started the WCGDAWS v3 spin-off development [an Office app], got 11.14 hours as longest.

Batch 1019 I've seen now as highest.

So I recently installed Linux on my 2 core netbook (note: not notebook) and the WUs were 90 minutes ~ 2 hours per at that time (unsure how normal that is as I recently joined OET). I gave it a buffer of 3 days as it has no internet on weekends and it worked fine until the WUs started running 20 hours plus. The Boinc software has slowly caught on to what current runtimes are and hence how many in my buffer is doable but there is a backlog that is running right up against the deadline. In my opinion it is better to cancel a WU than to report it too late and it not count or risk having it partially run on some other CPU and then aborted by the server.

Originally the indexer for OET1 had a sanity check limit of 100,001 work units in a batch. Because of the long run times for each VINA job for OET1, batches can actually exceed 100,000. When this happened, the indexer just skipped those batches. This was noticed very quickly, and the limit was adjusted and we indexed batches that were skipped for this reason. Batches are sent out in the order that they are indexed so we're now sending out work units from batches that had been skipped in indexing the first time around.

Seippel