log in |
1)
Message boards :
Number crunching :
Updates on BoincStats
(Message 2279)
Posted 17 Jan 2016 by Ananas FYI : I just found this in the BoincStats board : No, there was a real problem here. So everything should be fine by this evening :-) |
2)
Message boards :
Number crunching :
How do i know if i found a prime?
(Message 2246)
Posted 4 Jan 2016 by Ananas Riesels seem to run much longer if they suspect a prime in the 1st pass. So it might be interesting to have a look at the task details if you catch one of those by chance. p.s.: I guess that's not a reportable one : 1411147994*3^243348-1 may be prime, trying to compute gcd's
U((N+1)/3) is coprime to N!
1411147994*3^243348-1 is prime! (116116 decimal digits, P = 9) Time : 5408.691 sec.
08:44:21 (2916): llr.exe exited; CPU time 5401.109375
|
3)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 2243)
Posted 2 Jan 2016 by Ananas ... But only 8 concurrent tasks then instead of 16, overall that would be a loss. I guess I need an AVX machine some day :-/ |
4)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 2241)
Posted 2 Jan 2016 by Ananas ... It is getting harder to keep the deadline ... 8*800^973840-1, bit: 50000 / 9391576 [0.53%]. Time per bit: 41.762 ms. 8*800^973840-1, bit: 100000 / 9391576 [1.06%]. Time per bit: 40.380 ms. ... 8*800^973840-1, bit: 3250000 / 9391576 [34.60%]. Time per bit: 40.744 ms. 8*800^973840-1, bit: 3300000 / 9391576 [35.13%]. Time per bit: 147.026 ms. <= oops! 8*800^973840-1, bit: 3350000 / 9391576 [35.67%]. Time per bit: 40.288 ms. ... 8*800^973840-1, bit: 7100000 / 9391576 [75.59%]. Time per bit: 41.622 ms. 8*800^973840-1, bit: 7150000 / 9391576 [76.13%]. Time per bit: 41.693 ms. same computer, 20% longer processing time/bit |
5)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 2222)
Posted 29 Dec 2015 by Ananas ... The last stderr line seems to be even more interesting (taken from an active run) :
|
6)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 2191)
Posted 16 Dec 2015 by Ananas Thanks, I will use that formula next time to fight my (not the core client's) deadline panic :-) |
7)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 2187)
Posted 16 Dec 2015 by Ananas ... I can answer it myself now, they end somewhere between 95.5% and 95.8% - I finished all 6 before a second one had been sent out and it gave my RAC temporarily a nice boost :-) |
8)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 2186)
Posted 15 Dec 2015 by Ananas I'have stopped the Sierpinski / Riesel Base - long v0.01 WUs because with my Phenom II X6 1100T under Ubuntu 14.10 64 bits the time of calculation was far too much long especially the last 10% where progress moved only 0.001 % forward every 2 - 3 seconds. Did they run to 100% or have they been finished earlier? I have lix long ones on a lowpower Xeon (much slower than your box, especially the int speed - and no AVX on chip) and I'm afraid that the last 10% will run much longer than the first 90% The result with the best progress is 93.75% / 79 hours, this morning (~10 hours ago) it was at about 91% so it isn't too much happening per hour :-/ |
9)
Message boards :
Number crunching :
short deadlines cause panic mode
(Message 2177)
Posted 14 Dec 2015 by Ananas Something that would help - but I'm not sure if it can be done so easily : Delay the resend of the long ones after a timeout by 2 days without changing the deadline itself. This would give the slower hosts a better chance to return them before the server side scheduler sends them out a second time, even if they are somewhat behind the deadline. According to the server status page, they currently have a worst runtime of 52+ hours, hard to do within the deadline if they are not on top of the stack on client side. p.s.: if it is hard to do by application ... this behaviour wouldn't hurt for any kind of results, I even think it should be default for BOINC servers. The client still would do its best to stay within the deadline but the server would be more tolerant. I made that proposal a few years ago but the Berkeley guys didn't pick up the idea :-/ |
10)
Message boards :
Number crunching :
server overloaded ???
(Message 2130)
Posted 1 Dec 2015 by Ananas ... Lots of tiny results seem to have a major impact on the server's connection to the internet, when a lot of the 2-3 minutes Riesel results are available, the server becomes somewhat sluggish sometimes. I guess it is not necessarily the throughput but rather the number of concurrent connections that causes this. |