Out of order reported task listing
20 Jul 2016 4:09:18 UTC
Topic 198697
(moderation:
I'm running Parkes BRP6. Usually the tasks are shown in the order they are reported. For the last couple of days, however, there is no order. Tasks are shown what appears more randomly, although that may not be the case. For example, tasks reported on 18 July appear higher in the chart than tasks reported on 19 July. There are individual tasks and groupings of out of order tasks. Note that the tasks were sent on exactly the same day at the same time, 14 July 2016, 22:20:01 UTC.
I saw this once before, but I don't remember the circumstances. I assume, and hope, the condition is temporary, since it was that time. I don't know of any corrective action that could be taken.
Would one of the mods kindly give their take on the issues? TIA
Steve
"Remember, nothing that's good works by itself, just to please you. You have to make the damn thing work." Thomas A. Edison
Out of order reported task listing
)
Are the out of order tasks more recently validated by the 2nd user?
I'm not sure I understand
)
I'm not sure I understand your question. Most of them are valid when I report them, so they have already been reported by a wingman, and I have provided confirmation. For the three that are waiting for validation I am the first one to report the work unit, but they are out of order also.
"Remember, nothing that's good works by itself, just to please you. You have to make the damn thing work." Thomas A. Edison
RE: I'm running Parkes
)
At the time you mention, you received a very large influx of new tasks, in batches of decreasing size, over a period of several minutes. There are two possible scenarios (that I can immediately think of) which could cause this behaviour. The first one is that at that time a large increase in work cache size was made, possibly by adjusting the settings. The second one is that BOINC had been unable to get all the new tasks required to keep the cache full, perhaps for some considerable time. Then suddenly whatever was causing the restriction vanished and BOINC was able to fill up using a number of consecutive requests over a period of several minutes.
In either scenario, the result is much the same. The server sends the required tasks in batches, separated by approximately the 60s delay between server requests. The very first batch was 44 tasks. After that the following batches were of diminishing size until the required number of tasks to fill the cache had been received.
All the tasks within any single batch will show on the website as having the same 'sent time' but presumably there are small differences that will be used by the client to determine the order in which the tasks are crunched and returned. I assume this order may be quite different to the order a particular batch is listed on the website because I've seen this sort of behaviour before with a host with a new GPU when it fills up with work for the first time. None of this is any sort of a problem and will disappear once the host goes back to topping up the cache with small 'sips' at regular intervals rather than receiving big batches like the ones you had.
It would be interesting to know if either of the above 'scenarios' can explain why so much work was suddenly received. It could be something else like a big change (decrease) in duration correction factor (DCF) which made the client immediately think it was well short of the correct amount of work but the number of tasks fetched was so large that this seems unlikely.
Cheers,
Gary.
I had no out of order tasks
)
I had no out of order tasks through those that were sent on 13 July and reported on 17 July. The out of order tasks began with those sent on 14 July and reported on 18 July, continuing until now. So far I have reported 49 tasks. The first 35 were sent at 22:20:01 and the most recent 12 were sent at 22:21:09.
I reverted from Windows 10 back to Windows 7 on 7 July. As soon as I got BOINC and E@H running I increased my (temporary) cache size from 0.25 days to 1.7 days. I don't remember when I increased the cache to 3.5 days, but it is possible it was on 14 July. If so, it seems the first scenario would be the likely explanation.
"Remember, nothing that's good works by itself, just to please you. You have to make the damn thing work." Thomas A. Edison
RE: I had no out of order
)
That would be because you weren't getting large batches of tasks then. It seems pretty certain that what you are seeing is the result of doubling your cache setting in a single hit, and that that occurred at the particular time mentioned on the 14th.
As I said, the order in which BOINC chooses to crunch a single large batch is of no real consequence and the effect will pass once you get to tasks that were received in ones or twos. If you really must avoid this effect in future, just don't increase your cache size from 1.7 days to 3.5 days in a single leap. Take it up in lots of small stages so that there are only a very small number of tasks in each new batch.
Cheers,
Gary.
RE: That would be because
)
Yes. I was acknowledging that with my comment about the first scenario you mentioned. Thanks again.
"Remember, nothing that's good works by itself, just to please you. You have to make the damn thing work." Thomas A. Edison