mersenneforum.org Planning & Coordination for 2,2330L
 Register FAQ Search Today's Posts Mark Forums Read

2019-04-19, 12:48   #34
R.D. Silverman

Nov 2003

22·5·373 Posts

Quote:
 Originally Posted by swellman Yoyo is aware of the required ECM work for this composite, and has it in queue for another 9000 curves. The server automagically activates the next job when appropriate. It can be maddening to watch the last few curves drip in for a 99% completed task and the next number just won’t seem to advance. A characteristic of BOINC? Fewer WUs to hand out so slower progress towards the end of a task? I don’t know. But it will get there. (Note that DONE status indicates the ECM work has started on a number. The graphic indicator sometimes lags this event a few hours.)
Other projects seem to run several numbers simultaneously. Watching
"the last few curves" drip in does not seem to be a problem because there is
another number to take up the slack.

2019-04-19, 14:08   #35
Max0526

"Max"
Jun 2016
Toronto

13138 Posts
C207 degree 6 poly -- 1.8

Quote:
 Originally Posted by vebis Code: n: 334377437706404684733884220732190564550147039308686365251932207592010868660163280944362994773042289837865752943086095333357861608005044927356022538834108845220872215597190097852981295940487497385774178731621 skew: 533132.085 c0: 13400871167573270650087884944996454257736480 c1: 170662016202584202246103429104502541792 c2: -106489302432833541662856860257198 c3: -1862164478135527803969537503 c4: 375011464350515249437 c5: 1161035722389120 c6: 848502000 Y0: -1694165626316187446160079002429297 Y1: 428100302665617359981 # MurphyE (Bf=3.436e+10,Bg=1.718e+10,area=5.469e+16) = 1.45e-08 # found by revision 9436c2ff8 # f(x) = 848502000*x^6+1161035722389120*x^5+375011464350515249437*x^4-1862164478135527803969537503*x^3-106489302432833541662856860257198*x^2+170662016202584202246103429104502541792*x+13400871167573270650087884944996454257736480 # g(x) = 428100302665617359981*x-1694165626316187446160079002429297 My best (deg-6)
Really well done, vebis! Will do my best to spin.
Anybody is available to test-sieve and compare with the best so far in degree 5?
The skew and E should be (http://cownoise.com/):
Code:
skew = 602645.83721
E = 1.84800741e-15

2019-04-19, 15:44   #36
DukeBG

Mar 2018

3×43 Posts

Quote:
 Originally Posted by swellman It can be maddening to watch the last few curves drip in for a 99% completed task and the next number just won’t seem to advance. A characteristic of BOINC? Fewer WUs to hand out so slower progress towards the end of a task? I don’t know.
Yes, this is a characteristic for BOINC projects, but not exactly like that.

There are vary different people running BOINC on very different setups. Some people use the settings to limit when the BOINC is running. Some people turn off their PCs for the night. Some run on spot cloud servers and the spot instances vanish in thin air. Some run on very slow hardware in the first place.

Thus, the time a unit can be completed can vary a lot. But even for a dead host it won't be infinite. It will reach the timeout threshold – that's when another task for this workunit would be automatically sent out to a different host. In our case a workunit is a single curve on the specific number.

Imagine the new number is added and 9000 tasks are up for grabs. 1000 tasks are grabbed by fast hosts, 1000 tasks are grabbed by slow hosts. The fast computers finish theirs and take another ones and then another ones. Meanwhile some slow hosts finish some of theirs too, but not all. In the end, the fast hosts finish everything there is free to grab – but there'll still be some tasks that were assigned to the slow hosts. Or grabbed by now dead hosts. And those would have to wait till timeout and be resent.

Thus the speed the project is moving is fast in the beginning and very slow in the end. The last ones to finish are always the slow ones, not the fast ones.

Quote:
 Originally Posted by R.D. Silverman Other projects seem to run several numbers simultaneously. Watching "the last few curves" drip in does not seem to be a problem because there is another number to take up the slack.
ECM is a single subproject (i.e. not divided further) on yoyo@home, hosts do not and cannot run only cunningham numbers exclusively, all types of numbers get tasks grabbed equally. When there are tasks to grab.

Last fiddled with by DukeBG on 2019-04-19 at 15:50

2019-04-19, 16:37   #37
R.D. Silverman

Nov 2003

746010 Posts

Quote:
 Originally Posted by DukeBG Yes, this is a characteristic for BOINC projects, but not exactly like that. There are vary different people running BOINC on very different setups. Some people use the settings to limit when the BOINC is running. Some people turn off their PCs for the night. Some run on spot cloud servers and the spot instances vanish in thin air. Some run on very slow hardware in the first place. Thus, the time a unit can be completed can vary a lot. But even for a dead host it won't be infinite. It will reach the timeout threshold – that's when another task for this workunit would be automatically sent out to a different host. In our case a workunit is a single curve on the specific number. Imagine the new number is added and 9000 tasks are up for grabs. 1000 tasks are grabbed by fast hosts, 1000 tasks are grabbed by slow hosts. The fast computers finish theirs and take another ones and then another ones. Meanwhile some slow hosts finish some of theirs too, but not all. In the end, the fast hosts finish everything there is free to grab – but there'll still be some tasks that were assigned to the slow hosts. Or grabbed by now dead hosts. And those would have to wait till timeout and be resent. Thus the speed the project is moving is fast in the beginning and very slow in the end. The last ones to finish are always the slow ones, not the fast ones. ECM is a single subproject (i.e. not divided further) on yoyo@home, hosts do not and cannot run only cunningham numbers exclusively, all types of numbers get tasks grabbed equally. When there are tasks to grab.
Yes. It was not suggested to run Cunninghams exclusively. However, I note
that as of this moment there are about ten (yes 10) different HC's running
simultaneously. How is this possible? Thus, when one number is near finishing
there are others still running full steam.....

2019-04-19, 16:47   #38
R.D. Silverman

Nov 2003

1D2416 Posts

Quote:
 Originally Posted by R.D. Silverman Yes. It was not suggested to run Cunninghams exclusively. However, I note that as of this moment there are about ten (yes 10) different HC's running simultaneously. How is this possible? Thus, when one number is near finishing there are others still running full steam.....

It's taken over 2 days for 2,2330L to run ~200 curves. Why hasn't a second
set of 9000 curves been queued/started? Or a different number started?
Also, one might ask: Why limit to 9000 curves?

*If* the current behavior continues, it will take 2+ months to complete each Cunningham
--> i.e. 10 years to run just the ~60 numbers that I suggested.

As I noted, the HC's have 10 different numbers running at a time.......Other sets of
numbers also have multiple numbers running simultaneously.... Yes, the
progress on any one of them slows as the assignment nears completion... But then
there are others to "pick up the slack".

2019-04-19, 16:57   #39
R.D. Silverman

Nov 2003

22×5×373 Posts

Quote:
 Originally Posted by R.D. Silverman It's taken over 2 days for 2,2330L to run ~200 curves. Why hasn't a second set of 9000 curves been queued/started? Or a different number started? Also, one might ask: Why limit to 9000 curves? *If* the current behavior continues, it will take 2+ months to complete each Cunningham --> i.e. 10 years to run just the ~60 numbers that I suggested. As I noted, the HC's have 10 different numbers running at a time.......Other sets of numbers also have multiple numbers running simultaneously.... Yes, the progress on any one of them slows as the assignment nears completion... But then there are others to "pick up the slack".
Let me put this another way. If I look at the Cunningham list, I see only 1 number
queued: the next set of 9000 curves for 2,2330L.

If I look at http://www.rechenkraft.net/yoyo/down...m/hc/wu_status,
I see several dozen HC numbers queued...

 2019-04-19, 16:59 #40 xilman Bamboozled!     "𒉺𒌌𒇷𒆷𒀭" May 2003 Down not across 246728 Posts I can't answer your specific questions. However, I see the smae sort of behaviour for my GCW entries in the server. My view is that yoyo is providing me with free computation so I cut him a great deal of slack.
2019-04-19, 17:06   #41
R.D. Silverman

Nov 2003

22·5·373 Posts

Quote:
 Originally Posted by xilman I can't answer your specific questions. However, I see the smae sort of behaviour for my GCW entries in the server. My view is that yoyo is providing me with free computation so I cut him a great deal of slack.
Cut Slack??? Absolutely!.......

I also thought that B1 = 850M was the limit for yoyo.

However, I see that the "up for the Count" sub-project is using B1 = 2.9 x 10^9.

If possible, we really should be using "about" B1 ~ 3 x 10^9 for the Cunninghams.

BTW, I see the HC's as "low priority"........

2019-04-19, 17:35   #42
xilman
Bamboozled!

"𒉺𒌌𒇷𒆷𒀭"
May 2003
Down not across

101001101110102 Posts

Quote:
 Originally Posted by R.D. Silverman BTW, I see the HC's as "low priority"........
You may very well think that but I couldn't possibly comment. One man's fish is another man's poisson.

TBH, I don't know what the true upper limit may be on B1. Yoyo is a friendly and helpful guy and you could ask him. It makes no difference to me because my entries are nowhere near the point where tests optimized for > p60 are indicated.

2019-04-19, 17:46   #43
R.D. Silverman

Nov 2003

11101001001002 Posts

Quote:
 Originally Posted by xilman I can't answer your specific questions. However, I see the smae sort of behaviour for my GCW entries in the server. My view is that yoyo is providing me with free computation so I cut him a great deal of slack.
I don't see it as providing computation to me. I see it as providing computation
to Dick Lehmer, John Selfridge, and Bryant Tuckerman.......

 2019-04-19, 19:34 #44 swellman     Jun 2012 5·599 Posts I have noticed with xyyxf numbers that yoyo@Home tends to advance the queues on Tuesday and Saturday. Don’t know if that’s true for Cunningham numbers but it would not surprise me. But make no mistake, the decision to activate the next number in the queue is an autonomous one. Yoyo did indicate that there may be a race next week that could greatly increase throughput. I will keep an eye on the Cunninghams. Last fiddled with by swellman on 2019-04-19 at 19:35

 Similar Threads Thread Thread Starter Forum Replies Last Post ixfd64 Lone Mersenne Hunters 81 2021-04-17 20:47 henryzz Cunningham Tables 16 2010-08-07 05:08 gd_barnes No Prime Left Behind 2 2008-02-16 03:28 gd_barnes Conjectures 'R Us 32 2008-01-22 03:09 wblipp ElevenSmooth 2 2004-02-19 05:25

All times are UTC. The time now is 23:07.

Thu May 13 23:07:06 UTC 2021 up 35 days, 17:47, 0 users, load averages: 2.78, 2.87, 2.98