mersenneforum.org  

Go Back   mersenneforum.org > Factoring Projects > Cunningham Tables

Reply
 
Thread Tools
Old 2019-04-19, 12:48   #34
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

22·5·373 Posts
Default

Quote:
Originally Posted by swellman View Post
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.
R.D. Silverman is offline   Reply With Quote
Old 2019-04-19, 14:08   #35
Max0526
 
"Max"
Jun 2016
Toronto

13138 Posts
Default C207 degree 6 poly -- 1.8

Quote:
Originally Posted by vebis View Post
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
Max0526 is offline   Reply With Quote
Old 2019-04-19, 15:44   #36
DukeBG
 
Mar 2018

3×43 Posts
Default

Quote:
Originally Posted by swellman View Post
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 View Post
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
DukeBG is offline   Reply With Quote
Old 2019-04-19, 16:37   #37
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

746010 Posts
Default

Quote:
Originally Posted by DukeBG View Post
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.....
R.D. Silverman is offline   Reply With Quote
Old 2019-04-19, 16:47   #38
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

1D2416 Posts
Default

Quote:
Originally Posted by R.D. Silverman View Post
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".
R.D. Silverman is offline   Reply With Quote
Old 2019-04-19, 16:57   #39
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

22×5×373 Posts
Default

Quote:
Originally Posted by R.D. Silverman View Post
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...
R.D. Silverman is offline   Reply With Quote
Old 2019-04-19, 16:59   #40
xilman
Bamboozled!
 
xilman's Avatar
 
"𒉺𒌌𒇷𒆷𒀭"
May 2003
Down not across

246728 Posts
Default

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.
xilman is offline   Reply With Quote
Old 2019-04-19, 17:06   #41
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

22·5·373 Posts
Default

Quote:
Originally Posted by xilman View Post
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"........
R.D. Silverman is offline   Reply With Quote
Old 2019-04-19, 17:35   #42
xilman
Bamboozled!
 
xilman's Avatar
 
"𒉺𒌌𒇷𒆷𒀭"
May 2003
Down not across

101001101110102 Posts
Default

Quote:
Originally Posted by R.D. Silverman View Post
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.
xilman is offline   Reply With Quote
Old 2019-04-19, 17:46   #43
R.D. Silverman
 
R.D. Silverman's Avatar
 
Nov 2003

11101001001002 Posts
Default

Quote:
Originally Posted by xilman View Post
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.......
R.D. Silverman is offline   Reply With Quote
Old 2019-04-19, 19:34   #44
swellman
 
swellman's Avatar
 
Jun 2012

5·599 Posts
Default

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
swellman is online now   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Coordination thread for redoing P-1 factoring ixfd64 Lone Mersenne Hunters 81 2021-04-17 20:47
big job planning henryzz Cunningham Tables 16 2010-08-07 05:08
Sieving reservations and coordination gd_barnes No Prime Left Behind 2 2008-02-16 03:28
Sieved files/sieving coordination gd_barnes Conjectures 'R Us 32 2008-01-22 03:09
Special Project Planning 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

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.