work from other applications
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4273
Credit: 245179476
RAC: 14022
4 Aug 2008 13:28:43 UTC
Topic 193798
(moderation:
The server side software we're currently upgrading to has a flaw that causes of lot of Clients to get confusing messages from the server:
Message from server: No work can be sent for the applications you have selected Message from server: You have selected to receive work from other applications if no work is available for the applications you selected Message from server: Sending work from other applications
(though you haven't actively selected any application at all). So far we know these can be safely ignored.
BM
work from other applications
)
I don't have access to the machine right now, but my Intel host has been trying to do Project Initialization over the past few days. I currently have 3 hostIDs for the one machine. I'm not worried about that, as I can merge them because they'll all have the same name, but do you have any idea as to when work will be available for S5R4? My AMD grabbed some more S5R3 resend work this morning, so I'm debating if I want to set up the Intel host to get R3 or R4...
Thanks....
RE: The server side
)
G'Day Bernd,
I have received these messages and am a little confused.
I am still running power App 4.49 on all computers.
I get these messages and then Einstein still tries to download as many work units as it thinks I can handle.
The only problem is after downloading it finds that there is a problem and there is no "State File" and the S5R4 application is not there.
This has happened on each machine I still have work fetch enabled as I was going to help clear out the old resend work.
Is there a way to stop the project trying to download S5R4 work when I in fact can't run it.? It just wastes my bandwidth and causes problems at your end.
I have one WU that the project says I have but as it is an S5r4 WU I in fact do not have it. It will time out eventually.
RE: I have received these
)
I've just created a separate thread about how to support both S5R3 and S5R4 during the transition. I've had pretty much the same behaviour you describe and after setting up my new app_info.xml and the new S5R4 apps, the scheduler has been able to resend the "lost" S5R4 tasks and everything seems to be fine.
I anticipate publishing the app_info.xml file soon.
Cheers,
Gary.
RE: The server side
)
Just curious but did you get any angry messages emanating from your firewall? Comodo popped up a red (high risk) message asking what kind of an app it was and when I chose 'isolated stand alone program' rather than a Windows system application, I got the very same message. Made the change and I've yet to see it again.
But of course there's always the possibility it was nothing more than a simple coincedence. Anyway, it seemed to work for me.
F. Prefect
In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move.....Douglas Adams
RE: The server side
)
I am now getting this message on one Linux computer and then I get the S5R3 work as requested for the "other" platform.
However on my other Linux computer all I get is the message "Message from server: To get more Einstein@Home work, finish current work, stop BOINC, remove app_info.xml file, and restart."
Why are they different, one is working as it should but the other is not. This is the host id 868612.
To Gary, I am not going to worry about getting both S5R3 and S5R4 work at the moment, I will help clear out S5R3 first, then see about coming back to S5R4, I am interested in the credit issue, Seti against the rest. So I am keeping an eye on that.
RE: I am now getting this
)
This is probably because the scheduler has not yet instructed this host to delete the remaining R3 data files that it has. Whilst there are resend tasks available for the data you have, the scheduler will be happy to send those resends to you. At some point when that host makes a further contact with the scheduler there may be no resends at that moment so the scheduler will instruct the client to delete the remaining R3 data. From that point on you may not get work if you don't make the host dual capable or completely remove your R3 only app_info file.
I believe this means that this host has previously been instructed to delete the remaining R3 data. The scheduler does have resends for sure but it wont (yet) send them to your machine because it is still waiting for a host with the right data files to come along. There are still enough hosts that the scheduler can use if it waits a bit. Soon there wont be enough hosts and the scheduler will need to get a bit less picky.
They both are working as they should - according to the "rules" built into the scheduler :-).
There are two ways to do that and unfortunately continuing to leave just the R3 app_info file in place isn't one of them :-).
You have two choices (for the machine that is currently not getting resends)
1. Delete your R3 app_info file and let your machine get R4 stuff. When the scheduler gets desperate with R3 resends, it may occasionally send you the full kit to crunch the resend with the stock R3 app.
2. Install the dual R3/R4 full kit. The scheduler will send you R4 tasks immediately and then it may send you R3 resends with full data files but not the stock apps. You will crunch the resends with the optimised app as specified in app_info.
For the machine that is currently getting R3 resends (because it has the "right" data files), stock up with tasks while the going is good :-). Add an increment to your cache with the local prefs override facility and see if you get an extra resend task. Don't try to grab a big number because if it can't supply all immediately it may mark your R3 data for deletion and then your host will be in the same predicament as the other one :-).
Cheers,
Gary.