Posts by Ananas
|
1)
(Message 4149)
Posted 16 Mar 2015 by Ananas Post: well, they are running but not doing any work. I have several workunits with two results that would be available for validation but they are still in validate state initial and the server status page shows nothing waiting for validation. Some are older WUs where the second result finally popped in, but some from the brandnew batch share their fate. As their state is "initial", the transiioner and not the validator might be the lazy one, esp. as the transitioner has many hours backlog. |
|
2)
(Message 4136)
Posted 15 Mar 2015 by Ananas Post: ... When a project is reset the server ought to cancel any outstanding work units on that account but in my experience that doesn't happen. ... A core client side bug. The only way to tell the server that the host will never return those WUs anymore it to detach, then re-attach the same host (and merge the two host entries back into one). I did that on FiND when they had upload server trouble (uploads didn't throw an error but all results were invalid), the results went into the state "abandoned" after the re-attach and the server sent them out again (without having to wait for the deadline to expire). |
|
3)
(Message 4035)
Posted 16 Feb 2015 by Ananas Post: You're right, it's like that one. |
|
4)
(Message 4033)
Posted 16 Feb 2015 by Ananas Post: <message> WU download error: couldn't get input files: <file_xfer_error> <file_name>input_4528_32</file_name> <error_code>-224 (permanent HTTP error)</error_code> <error_message>permanent HTTP error</error_message> </file_xfer_error> tons of those, wingmen are affected too so it's a problem on server side. |
|
5)
(Message 3448)
Posted 26 Jul 2014 by Ananas Post: ... There are very few projects (I would estimate, not more than three) that require a later version, one of them because they have only multithreaded applications, the second one has no CPU applications and 5.x doesn't support GPU. One thing I like about that BOINC version is that it still works with BOINCview, the second one is the installer, it stays away from the system drive (BOINC data directory in HDD areas that might be roamed is an extremely nasty idea). The third reason is that they removed some of the remote commands, like changing short and long term debits. Imo. that debits stuff is implemented very crappy and this command allows me to override some limitations - without stopping the core client and editing the client state XML. |
|
6)
(Message 3445)
Posted 26 Jul 2014 by Ananas Post: I adjusted the version_num tag - the binary already has been 10210. I guess that had to do with some testing quite a while back. ... Did the same on a XP x86 box that doesn't get any work anymore either - no luck. Removed app_info.xml completely but still - no luck. So it can only be either the oldish core client or it checks the operating system (well, or the host owner). Even detach and re-attach doesn't help. So I guess I'm out here :-( |
|
7)
(Message 3443)
Posted 25 Jul 2014 by Ananas Post: I adjusted the version_num tag - the binary already has been 10210. I guess that had to do with some testing quite a while back. I currently cannot restart any of my core clients though, extremely long running QMC workunits (the longest one currently > 34 days at 4%, but they usually end before 20%) and I'm not sure how they checkpoint. |
|
8)
(Message 3441)
Posted 25 Jul 2014 by Ananas Post: Maybe some "minimum core client version" issue then? Or it has to do with a somewhat older bug on server side, that didn't do any damage before : Old client versions report only the CPU time, as the wallclock time is quite irrelevant. If no wallclock time is available, the server should transfer the CPU time into the wallclock time (some projects do that) - but it seems to override CPU time with the (empty) wallclock time instead, so all my results show 0:00 for both time values. Or the new scheduler checks the user name and there's some hardcoded revenge action, when it's one of my hosts ... for fighting the heartbeat bug for so many years ;-) |
|
9)
(Message 3439)
Posted 25 Jul 2014 by Ananas Post: fixed, thank you :-) |
|
10)
(Message 3438)
Posted 25 Jul 2014 by Ananas Post: It ran out of space, probably because reporting (and thus validating/deleting) is currently not possible (Feeder not running) |
|
11)
(Message 3437)
Posted 24 Jul 2014 by Ananas Post: Yes, indeed, it works fine now. I cannot confirm that, one of my boxes that uses anon. platform because I want to enforce a specific CPU command set does not receive work anymore - no reason given. It did receive work immediately after the comeback but today I wanted it to fetch some more results and the server won't give amy to me. The application details page shows no limitations per day that would explain it. |
|
12)
(Message 3421)
Posted 23 Jul 2014 by Ananas Post: The answer Intel would not want to hear : The Pentium 4 has been a waste of power since the Pentium III was introduced ... well, at least since the Tualatin version came out. This refers to the efficiency, not to the plain crunching power - but I would rather reactivate my dual PIII 1266s than the PIV board that I still have in the shelves. A PIV (or a hyperthreaded S604 Xeon) would make perfect sense to help bring a vacation house through the winter, if you had an electrical frost protection heater. But then it should clock down, when temperature raises above the minimum temperature you have to keep. I'm not joking, I have such a house and if it had internet access, I would try to find a solution for that because I hate to use those electrical heaters without having any positive side effect (like crunching). |
|
13)
(Message 3405)
Posted 22 Jul 2014 by Ananas Post: Problem should be fixed. Developers still didn't fix it so I replaced server files with older one. According to log scheduler is working. The fix is working, you did it :-) |
|
14)
(Message 3399)
Posted 22 Jul 2014 by Ananas Post: ... This is not correct, uploading and reporting does work. Just after reporting, the tasks stay in the lists of your BOINC clients so it looks as if they had not been reported. If your host pages here on the project site do not show any tasks in the state "in progress" anymore, you could reset this project on your computers, so they will not try to report already reported tasks anymore. I can't get new tasks. ... Currently a lot of people seem to have this problem, so it is not on your side. The two problems (not removing reported tasks and not getting work) are caused by the same issue. Have a look here, it seems to be related to the BOINC server side update. |
|
15)
(Message 3383)
Posted 21 Jul 2014 by Ananas Post: ... So maybe the new server code requires a https transfer and the project is set up to try a http transfer? ... I don't think so. If it required secure socket, it would be an all or nothing, it should reject the request instead of accepting the reported results and then throwing the error. My core version is ancient btw., not even close to a developers version ;-) |
|
16)
(Message 3379)
Posted 20 Jul 2014 by Ananas Post: One more information : The error happens after accepting the reported results. A lot (if not all) of the finished results that I still have here on my hosts are not "in progress" in the server result lists anymore so reporting must have worked. So currently nothing gets lost, I cannot receive more work though. edit : I just reported this one, despite of the error message, it has arrived on the server |
|
17)
(Message 3373)
Posted 20 Jul 2014 by Ananas Post: Currently sched_reply looks like this : <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>500 Internal Server Error</title> </head><body> <h1>Internal Server Error</h1> <p>The server encountered an internal error or misconfiguration and was unable to complete your request.</p> <p>Please contact the server administrator, webmaster@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error.</p> <p>More information about this error may be available in the server error log.</p> <hr> <address>Apache/2.2.22 (Debian) Server at asteroidsathome.net Port 80</address> </body></html> even though it looks just normal, when I open the scheduler URL in a browser p.s.: uploads and web pages are not affected, it's just the scheduler URL that acts up |
|
18)
(Message 3371)
Posted 19 Jul 2014 by Ananas Post: I still think that a /robots.txt would make sense anyway, as search spiders crawling the results and hosts pages can produce major database load. Nearly all BOINC projects have it. There used to be a file "sample_robots.txt" in the CVS- (later SVN-) path "html/user/sample_robots.txt", not sure if it is still there. In the old version, default had been "allow" and they excluded a few selected directories from crawlers, must have been like this : User-agent: * Disallow: /account Disallow: /edit_ Disallow: /host_ Disallow: /prefs_ Disallow: /result Disallow: /team Disallow: /workunit Afaik. later versions are much harsher defaulting to "disallow everything" and selectively allowing a few directories, something like : User-agent: * Allow: /index.php Allow: /info.php Allow: /intro.php Allow: /old_news.php Allow: /rss_main.php Disallow: / The new version has the advantage that people and bots cannot peak into what they are not supposed to see - just in order to explore especially that ;-) Of course, you would have to add the "/boinc" base directory to all path lines (except for the "/" itself). edit : You even have the sample installed http://asteroidsathome.net/boinc/sample_robots.txt. If you edit it to add the "/boinc" subdirectory, make sure to let it have *ix style line ends, DOS line ends (x0d x0a) render the file useless. |
|
19)
(Message 3320)
Posted 14 Jul 2014 by Ananas Post: I'm getting this message way to often now. Maybe a "robots.txt" file would help to keep search spiders away from results, host and user statistics. The only database driven area where search spiders probably make sense are the forum contents. |
|
20)
(Message 3255)
Posted 29 Jun 2014 by Ananas Post: Result upload is often not affected by the maintenance but if it worked, the data are available for the validator (if not, the BOINC client will retry the upload later). As long as the scheduler accepted the reporting of the results, they will be counted. If the scheduler has not been running anymore when you tried to report, your BOINC client will retry that and it will succeed, as soon as the scheduler is back. So no, you will not lose anything and yes, credits will be granted later. |
Next 20