Why am I getting this message?
Anonymous
15 Dec 2009 20:35:50 UTC
Topic 13796
(moderation:
Quote:
To me it looks like the scheduler thought it might be able to send some old S5R5 work but in the end it concluded that the best option was to just send an S5R6 task (taskID #151245075) which you now have in your cache. The messages at the end of the snippet are to tell the client that the request for S5R5 work couldn't be honoured and that S5R6 work was sent instead. I don't really know why it felt the necessity to tell this to the client. I also don't understand why it talked about removing the l1_1112.xx files while confirming the h1_1112.xx files near the start of the snippet. Maybe there's a bit of a bug in the current locality scheduling algorithm.
There probably is, but not visible here ;-)
I recently switched on a bit more debugging output to find things that need to be fixed in the locality scheduling.
Since the launch of the Radio Pulsar search Einstein@home is actually calling two different scheduler codes to serve both types of work:
The Radio Pulsar search (ABP1) is an ordinary ('non-locality') BOINC type of work, where one data file is downloaded for every task, and after processing the task it is deleted from the client (and even from the server when the workunit is done).
The Gravitational Wave search (S5R6) is 'locality work': The same set of data files is used for multiple workunits. So the whole server (locality scheduler, workunit generator and even transitioner) tries to generate, find and assign tasks to the client that minimizes its download volume.
At each scheduler contact one scheduler part gets called first to handle the client request, then the other one gets called to fill up if more work is requested than the first scheduler part could send. Which scheduler part gets the first chance to send work is chosen at random at each contact, the current setting is 70% locality, 30% non-locality. We call this 'mixed' scheduling.
From the cited log you can see that locality work was sent first ("[mixed] sending locality work first").
The locality scheduler removes everything that is not a 'trigger' (i.e. the beginning of a workunit name) from an internal structure named 'file_infos' list. As far as I can see, the behavior of the 'locality scheduler' is correct.
The message apparently comes from the 'non-locality scheduler' that is called second ("[mixed] sending non-locality work second").
Honestly I don't know yet where it comes from, but I'll look into that. It's definitely a problem on the server side.
BM
Why am I getting this message?
)
Should be fixed now. If you still get this message, please post here.
BM
BM
RE: I would expect it to
)
Hm. I could see that the message is a bit too general. It means that though you have selected to get GPU work (too) the project has no GPU work that could be sent to your machine.
But anyway - that's a (slightly) different message and a different problem than what I was addressing.
BM
BM