It's only because some beta's came arriving to the tablet did i come looking. Whether small is advisable and holding off on the validation i'd query. That's what led in my opinion into missing the 195 debacle. Members who have these large scale, like yoro42 suddenly experienced 17 pages worth serially, need to find out with multiple repetition tests if 195 can be called harnessed. 2000 (quorum 2), will more than likely not expose this to the fullest extend.

Ok, I got two betas - one short one long. The short one finished well (pending validation).

Then at some point the phone simply crashed an then restarted (note, I have a fan blowing on the phone so it should not get hot).

After that, none of the tasks progress anymore. They are stuck at some percentage each (the one that was before they crashed. Anyway, the crash occured with the following beta WU in progress:

BETA_ FAHV_ x3AV9aINfbA_ 0340112_ 0158_ 1--

Should I abort them all and try to get new WUs perhaps?

flodisar,

What does the event log say? Does it show these results as running?

Also, since your device is getting hot, you might want to go into the preferences on your phone and change the max temperature to something like 40C. I believe the default is set to 45C which should be lower than system specs.

Thanks,
-Uplinger

Thanks for the response. Had 3 'short' and upon reenabling wcg fetch, got 4 more without the 'short' piece in the job name, all 4 cores now allowed. Found that the charger could not keep up, even after switching to a heavier from the jbl wireless speaker. Odd thing is, the charger is able to keep up once the battery is 'charged', it's only when between 60-99 percent it cant on 4 cores, sometimes not even 3. Might be another feature worth considering: Automatic scaling the number of computing cores to the battery percent, as a preference of course. Think to have seen others experienced same and having their agents alternating between on and off at whatever charge level they've set. Android does not hold tasks in memory when paused so they must be unloading and loading continuously, and who knows whatever bad effect on the task and the device.

Note, whilst you want the devices that do not have the 195 problem test there's no regression, aiming the test at those that do, even pushing these in their direction, would be good. At any rate, don't wait weeks and weeks and members getting uptight. If you see a major improvement, just promote to production and work your way through further alpha testing to get to whatever bottom line error threshold you aim for.

Also, as a side note, we are testing both the flex work units as well as non-flex work units. 500 of these will be short as these allow us to get some data back quicker to show us if there is a check pointing issue. The other 500 are full length, which will help us check for the error 195 issue (as well as check pointing).

Thanks,
-Uplinger