Message boards :
Number crunching :
-177 (0xffffffffffffff4f) ERR_RSC_LIMIT_EXCEEDED
Message board moderation
Author | Message |
---|---|
Spectrum Send message Joined: 14 Jun 99 Posts: 468 Credit: 53,129,336 RAC: 0 |
Hello all. Almost all of my 6.10 tasks are winding up with this error, does anyone know what is causing it and how to fix it? Any help appreciated. |
Terror Australis Send message Joined: 14 Feb 04 Posts: 1817 Credit: 262,693,308 RAC: 44 |
Hello all. Have you changed anything in your machine or rescheduled tasks from the CPU to the GPU ? A 177 error occurs when the unit is taking much longer to crunch (10x ?) than what BOINC thinks it should. This usually occurs after a CPU to GPU reschedule. If you look the ETA of the shifted tasks will be less than a minute. If you have Fred's Rescheduler. Go to the "Expert" tab, check the "Limit rsc_fpops_bound to avoid -177 errors" box and run the program from Seti tab. Sorry but I can't find the link to Fred's program. I know it's www.efmer.????? T.A. |
William Send message Joined: 14 Feb 13 Posts: 2037 Credit: 17,689,662 RAC: 0 |
Hello all. When reporting errors and you have more than one host, it helps to link the host in question [ 6312756 ] so we won't have to go through a list of hosts trying to find the right one. According to that page your BOINC version is 7.0.25. That version is horribly buggy, so I'd advise to upgrade all the way to the current Alpha 7.0.52 available from the extended BOINC download page. You could use 7.0.28 but there have been a LOT of bugfixes since and the current Alpha is pretty good and should only retain very minor issues. As T.A. has pointed out, -177 errors occur when the task takes more than 10x longer than the original estimate. So either the original estimate is way off, or the DCF is way off [7.0.25 still uses dcf]. From the application details page it appears you only just put that ATI card into the host. I'm not too familiar with ATI card details (I leave that to Mike and Claggy) but an APR of over 700 strikes me as way too high. From the valid tasks page it looks like the first bunch of tasks received were VHAR (shorties) - those are computed faster than estimated, which may explain the insane APR. Strangely though new VHAR are also eroring so I guess your DCF is somewhere insane, too. Ok, so how to get it running again. T.A. has already pointed you to Fred's rescheduler, available from here. Don't bother with the rescheduling itself, you want the expert tab and the option against -177s. That will extend the time for all tasks on board allowing them to finish properly and send a good time to the server. That should get the APR to where it belongs - you should have few enough tasks validated to get the change through quickly. After the settling period APR changes only with glacial speed... Else, if you are feeling adventurous and not particularly attached to the hostid, you could run down your cache and force a new hostID, to get a clean APR sheet. Detach/reattach does not usually result in a new hostID. If you want to force the issue, stop boinc and edit client_state.xml. Make sure you are using notepad (or similar). Look for the seti entry and change <rpc_seqno> to a number smaller than the number shown for contacts on the host webpage. Mind you tampering with client_state.xml is for very advanced users only. Mistakes can cost you dearly - boinc recovers but you lose all your cache - not only seti but other projects too, if you are running them. William the Silent A person who won't read has no advantage over one who can't read. (Mark Twain) |
S@NL - eFMer - efmer.com/boinc Send message Joined: 7 Jun 99 Posts: 512 Credit: 148,746,305 RAC: 0 |
http://www.efmer.eu/ TThrottle Control your temperatures. BoincTasks The best way to view BOINC. Anza Borrego Desert hiking. |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.