Rejecting My Computer
9 Jun 2007 0:13:30 UTC
Topic 192831
(moderation:
I turned on my computer after getting home from work today and the following messages were displayed:
6/8/2007 6:33:45 PM||Starting BOINC client version 5.8.16 for windows_intelx86
6/8/2007 6:33:45 PM||log flags: task, file_xfer, sched_ops
6/8/2007 6:33:45 PM||Libraries: libcurl/7.16.0 OpenSSL/0.9.8a zlib/1.2.3
6/8/2007 6:33:45 PM||Executing as a daemon
6/8/2007 6:33:45 PM||Data directory: C:\\Program Files\\BOINC
6/8/2007 6:33:45 PM||BOINC is running as a service and as a non-system user.
6/8/2007 6:33:45 PM||No application graphics will be available.
6/8/2007 6:33:45 PM||Processor: 4 GenuineIntel Intel(R) Xeon(TM) CPU 1.80GHz [x86 Family 15 Model 2 Stepping 7] [fpu tsc sse sse2 mmx]
6/8/2007 6:33:45 PM||Memory: 1023.01 MB physical, 2.90 GB virtual
6/8/2007 6:33:45 PM||Disk: 111.73 GB total, 20.53 GB free
6/8/2007 6:33:45 PM|rosetta@home|URL: http://boinc.bakerlab.org/rosetta/; Computer ID: 103582; location: home; project prefs: default
6/8/2007 6:33:45 PM|Einstein@Home|URL: http://einstein.phys.uwm.edu/; Computer ID: 942314; location: (none); project prefs: default
6/8/2007 6:33:45 PM|SETI@home|URL: http://setiathome.berkeley.edu/; Computer ID: 1957487; location: (none); project prefs: default
{snip}
6/8/2007 6:43:50 PM|Einstein@Home|Sending scheduler request: To fetch work
6/8/2007 6:43:50 PM|Einstein@Home|Requesting 2160 seconds of new work
6/8/2007 6:43:55 PM|Einstein@Home|Scheduler RPC succeeded [server version 509]
6/8/2007 6:43:55 PM|Einstein@Home|Message from server: No work sent
6/8/2007 6:43:55 PM|Einstein@Home|Message from server: (won't finish in time) Computer on 39.7% of time, BOINC on 90.5% of that, this project gets 25.0% of that
6/8/2007 6:43:55 PM|Einstein@Home|Deferring communication for 1 min 0 sec
6/8/2007 6:43:55 PM|Einstein@Home|Reason: requested by project
{snip rest}
OK, Mr. Einstein Server, you need a head check on your "(won't finish in time)" routine. Yes, my computer is only on 39.7% of the time and Boinc is on 90.5% of that. However, you can't then project that an Einstein@home application only "gets 25.0% of that" because I have four virtual processors (two physical processors with hyperthreading turned on): "6/8/2007 6:33:45 PM||Processor: 4 GenuineIntel Intel(R) Xeon(TM) CPU 1.80GHz [x86 Family 15 Model 2 Stepping 7] [fpu tsc sse sse2 mmx]"
Mr. Einstein Server gets one dedicated CPU (25%) of my total Boinc job mix, which is over 60 hours per week. If I left my air conditioner on when I was gone I would leave the computer running, but you have no idea how much that would cost and I just can't afford that these days.
Anyway, at 60 hours per week, I can still crank out an Einstein work unit about once every 6 to 10 days, depending on where the weekend falls in the mix (the estimates for my Xeon hyperthreaded CPUs also consistently over-estimate how long the work unit will take to complete; and I compute more on weekends as I'm home more, too).
Now, because Mr. Einstein server refused to give me another work unit, my Boinc just went and got itself another Rosetta work unit, so its not like I have nothing left to do here.
But I really think you ought to fix that computation if you are going to make these sorts of decisions based upon false facts.
== Bill
Rejecting My Computer
)
I would think that the decision not to download work based on the cited estimation is made by Mr. Boinc Client, tho, and not Mr. Einstein Server :-). So if it's really a bug it would have to be fixed by the BOINC project.
And it looks like a bug to me. If the BOINC client is taking some other stuff into consideration (like "debt" to SETI project, see other threads here), it should mention this in the output. The rationale for not downloading work doesn't make sense to me either as it is given in the output you quoted.
There are a couple of BOINC experts here who will hopefully comment on this.
CU
BRM
Bill, your problem is that
)
Bill, your problem is that the server thought it sent you a work unit on the 6th of June that you clearly have not got. First go to the Transfers window in the advanced view and check that you haven’t got a stuck upload of the WU or any of its associated data files. If you have then highlight them and hit “Retry Now�.
If there is nothing there then you have a ghost unit. If you “Reset project� in the Projects window with Einstein highlighted then this should cure it but, if it doesn’t, then you will need to detach from Einstein in the same window and then reattach. This last method will create a new computer as far as the Einstein server is concerned and it should give you a new WU. After a day or two go to "my computers" in your account on the Einstein web site and merge the two computers. Dave.
RE: Bill, your problem is
)
Theoretically, since EAH has auto-resends enabled you shouldn't have to do anything to recover from a ghost result. It should happen automatically on the next scheduler contact.
Also, I believe EAH is running a new enough server package (although they rolled back from the latest ones awhile back) that a detach doesn't generate a new host ID as long as you don't delete the client_state files.
Alinator
[quote Theoretically, since
)
[quote
Theoretically, since EAH has auto-resends enabled you shouldn't have to do anything to recover from a ghost result. It should happen automatically on the next scheduler contact.
Also, I believe EAH is running a new enough server package (although they rolled back from the latest ones awhile back) that a detach doesn't generate a new host ID as long as you don't delete the client_state files.
Alinator
RE: You are more up to date
)
LOL... No problemo.
As we're finding out on SAH the auto-resend and auto abort features can have some unintended consequences depending on the project configuration. Therefore it's always a good idea to ask questions when you see stuff happening which doesn't seem to make sense, and also to respond to someone's questions here. Even if you're not 100% sure you have the latest data available, that's better than leaving a 'nugget' hanging with no answer for days on end. ;-)
I try hard to stay current, and even then I get get caught short on occaision. :-)
Alinator
More mysteries:
)
More mysteries:
Anybody got any interesting idea on what the "Got server request to delete file" message actually means? I checked that particular in-progress result. It is not late, so far as I can see. And it has not been made obsolete by a late reply from an earlier recipient who failed to respond, again so far as I can see. So, I'm clueless.
And, after reading all of your kind replies, above, I don't see any explanation for my initial problem, either.
I do wish I had a clue.....
== Bill
"Got server request to delete
)
"Got server request to delete file"
When Einstein sends you a brand new unit, that unit comes with files that are utilized with a set of results you will crunch. When all those are done, the server than says it's done with that master file and deletes it.
This master file holds data that helps crunch a set of results all from the same area. It saves on downloading a lot larger files each time you need a result.