mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   NFS@Home (https://www.mersenneforum.org/forumdisplay.php?f=98)
-   -   Fast Breeding (guru management) (https://www.mersenneforum.org/showthread.php?t=20024)

swellman 2018-11-06 02:56

C157_159978_10275 - Need more relations?
 
Does this need a bit more Q?

unconnected 2018-11-06 06:03

[QUOTE=swellman;499698]Does this need a bit more Q?[/QUOTE]


Yes, 5MQ would be enough. And please +10MQ to the C162_11040_10096.

jyb 2018-11-06 18:20

[QUOTE=swellman;499454]Think it’s a Greg issue. I noticed the 0% pushed issued right away but it seems to have generated relations. Don’t see anything wrong with the poly, and I did remember to add the line “lss: 0” for sieving on the -a side.

The siever is now calling for max Q = 126M but that may be erroneous. Suggest we wait for the job to finish and someone try to postprocess it.[/QUOTE]

There's definitely something weird going on with this number. The status page is now showing 2.33% of work units have been generated, which makes no sense given that the alleged number of them received is already greater than the total should be.

But stranger still, the polynomial as you entered it in the manager page does indeed have "lss: 0" in it; but the .poly file available for download on the nfs_data page does [I]not[/I] have that. And indeed some number of the relations in the .dat.gz file appear to have sieved special-Q on the rational side. The first few lines look like this:
[code]
-56871830813,747:a015a2f,1457081,9773d5,8d505,56e7f:379c187,71f,15a6c63,1329007,ed3b3,200c3,20407,bdef
49950488977,2401:4fcee3f,1457081,943,2bfff9,29d7:170fdc3b,3c3f3005,b6f,3f5,12d4c75,26623,32acd9,23f9f5
69230179021,847:1a6e767b,1457081,11c97fb,854d1,4357:17c9a1df,510a949,b4c2db,199f9,17711,13c88b,3cc7
[/code]
Note the rational factor in each of them: 0x1457081, which is 21328001. However the last few lines of the data file contain this:
[code]
10752495169,6957:44857C3,923,6BB,4E1,D2B8F,4957D:C724075,1FA5533B,F7E05B,35DACF,E78B3,3E0FF,142827D
-119542032011,3257:2AA15193,44F9AB3,773,34DA1,10489:2DB23C9,6944EC7,CCCB5,5672B,142827D
50948844409,4119:3C16A2FF,949,96D799,6527CB,258D:1C20ACAB,312DCA93,1C81,8D8749,5ACC17,37FC1F,142827D
[/code]
Here the common factor is in the algebraic set: 0x142827D == 21135997.

In any case, I see that you've reserved this number for post-processing (though I think you posted that in the wrong thread), so I'll be interested to see what you find. Even if the relations were all valid, there don't seem to be nearly enough of them yet.

swellman 2018-11-06 23:29

[QUOTE=jyb;499753]There's definitely something weird going on with this number. The status page is now showing 2.33% of work units have been generated, which makes no sense given that the alleged number of them received is already greater than the total should be.

But stranger still, the polynomial as you entered it in the manager page does indeed have "lss: 0" in it; but the .poly file available for download on the nfs_data page does [I]not[/I] have that. And indeed some number of the relations in the .dat.gz file appear to have sieved special-Q on the rational side. The first few lines look like this:
[code]
-56871830813,747:a015a2f,1457081,9773d5,8d505,56e7f:379c187,71f,15a6c63,1329007,ed3b3,200c3,20407,bdef
49950488977,2401:4fcee3f,1457081,943,2bfff9,29d7:170fdc3b,3c3f3005,b6f,3f5,12d4c75,26623,32acd9,23f9f5
69230179021,847:1a6e767b,1457081,11c97fb,854d1,4357:17c9a1df,510a949,b4c2db,199f9,17711,13c88b,3cc7
[/code]
Note the rational factor in each of them: 0x1457081, which is 21328001. However the last few lines of the data file contain this:
[code]
10752495169,6957:44857C3,923,6BB,4E1,D2B8F,4957D:C724075,1FA5533B,F7E05B,35DACF,E78B3,3E0FF,142827D
-119542032011,3257:2AA15193,44F9AB3,773,34DA1,10489:2DB23C9,6944EC7,CCCB5,5672B,142827D
50948844409,4119:3C16A2FF,949,96D799,6527CB,258D:1C20ACAB,312DCA93,1C81,8D8749,5ACC17,37FC1F,142827D
[/code]
Here the common factor is in the algebraic set: 0x142827D == 21135997.

In any case, I see that you've reserved this number for post-processing (though I think you posted that in the wrong thread), so I'll be interested to see what you find. Even if the relations were all valid, there don't seem to be nearly enough of them yet.[/QUOTE]

Well I can kill this job and restart it fresh. Not expecting it to actually build, but curious if any valid relations exist in the data file. I’ll download it tomorrow and post the resulting log file. If it’s junk, I’ll delete it and start over.

swellman 2018-11-08 02:45

7_355m2_355 Hopelessly broken
 
Tried downloading this data file and found it totally FUBAR.

Before the job is killed, the poly file currently being sieved on 14e is reproduced here for reference:
[code]
n: 22795329870195321077005339925744314618878566620985708492968838828506288868054836245600917748359472427226420903385921010946757167524879676122623873696521069071
# norm 3.073931e-15 alpha -7.759592 e 1.965e-12 rroots 3
skew: 84683252.00
lss: 0
c0: 356324462563708319026779851750425012404975
c1: 2708627872251538132668667055364341
c2: -236695388794833028236083479
c3: -3835247591175182113
c4: -51781310376
c5: 252
Y0: -9801421806425102632274250332258
Y1: 6297749407119391
rlim: 31800000
alim: 31800000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
[/code]

I suggest r/alim be raised to 67M. Anything else to be changed?

jyb 2018-11-08 04:24

[QUOTE=swellman;499869]Tried downloading this data file and found it totally FUBAR.

Before the job is killed, the poly file currently being sieved on 14e is reproduced here for reference:
[code]
n: 22795329870195321077005339925744314618878566620985708492968838828506288868054836245600917748359472427226420903385921010946757167524879676122623873696521069071
# norm 3.073931e-15 alpha -7.759592 e 1.965e-12 rroots 3
skew: 84683252.00
lss: 0
c0: 356324462563708319026779851750425012404975
c1: 2708627872251538132668667055364341
c2: -236695388794833028236083479
c3: -3835247591175182113
c4: -51781310376
c5: 252
Y0: -9801421806425102632274250332258
Y1: 6297749407119391
rlim: 31800000
alim: 31800000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
[/code]

I suggest r/alim be raised to 67M. Anything else to be changed?[/QUOTE]

Looks fine to me.

VBCurtis 2018-11-08 07:42

[QUOTE=swellman;499869]Tried downloading this data file and found it totally FUBAR.

Before the job is killed, the poly file currently being sieved on 14e is reproduced here for reference:
[code]
# norm 3.073931e-15 alpha -7.759592 e 1.965e-12 rroots 3
skew: 84683252.00
.....
c5: 252
...
rlim: 31800000
alim: 31800000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
[/code]

I suggest r/alim be raised to 67M. Anything else to be changed?[/QUOTE]

The super-low c5 and super-high skew may contribute to sieving difficulties. I wager this poly sieves quite a bit worse than its score would suggest, but that shouldn't make a rels file useless on its own. I was interested to see what sort of matrix this parameter set produced, and I'm sad the rels file failed us.
Test-sieving was done, and if it wasn't done on different settings we have reason to think this may have been related to the server burp last week, or another bad actor sending faked data for boinc credits (or whatever it is that occasionally causes a few million rels to be bad in these jobs).

jyb 2018-11-08 07:55

[QUOTE=VBCurtis;499880]The super-low c5 and super-high skew may contribute to sieving difficulties. I wager this poly sieves quite a bit worse than its score would suggest, but that shouldn't make a rels file useless on its own. I was interested to see what sort of matrix this parameter set produced, and I'm sad the rels file failed us.
Test-sieving was done, and if it wasn't done on different settings we have reason to think this may have been related to the server burp last week, or another bad actor sending faked data for boinc credits (or whatever it is that occasionally causes a few million rels to be bad in these jobs).[/QUOTE]

Large skew aside, the test sieving should really be dispositive here. There's no reason this shouldn't have worked fine. After all, the yields were quite high. My money is on a server-side issue of some sort.

swellman 2018-11-08 12:23

7_355m2_355_B
 
I’ve submitted this job afresh, so let’s see what happens. Leaving the old job in queue for the time being, in case further investigation is desired.

jyb 2018-11-09 00:21

[B]QUEUED AS 9p2_574M[/B]

SNFS-235.6 C193 HCN (9+2,574M), ECM to t52+. For 14e.
[code]
n: 1015118427762432145585256475977208967931967049001687465117734148301497677430505658136809399398115747470750604265258195157430679812175238530495171963177758998271333376916873964485468552102952297
skew: 2.121320
c6: 8
c5: -24
c4: -180
c3: 540
c2: 648
c1: -1944
c0: 729
Y1: 25496472432792156348874752
Y0: -1330279464729113309844748894056472933961
rlim: 67000000
alim: 67000000
lpbr: 30
lpba: 30
mfbr: 60
mfba: 60
rlambda: 2.6
alambda: 2.6
[/code]
Trial sieving 5K blocks:
[code]
Q Yield
--- -----
20M 8056
50M 6333
80M 5301
110M 5190
140M 4232
170M 3985
[/code]
Recommend sieving special Q on rational side, 20M - 150M.

RichD 2018-11-09 13:46

[B]QUEUED AS 230329301_29m1[/B]

C199 from the OPN t550 file.
[ a.k.a. Phi_29(Phi_5(4933)/11/31/7541)/59/978624547/406534500451/51433290893203 ]
[CODE]n: 1158690572480178273500211173099837719117014526580068453604221599691668416907034643088813970163254526076907140314862581224882803593087176003926408882696904959666870517137449980129350839004533132112941
# 230329301^29-1, difficulty: 250.87, skewness: 24.76, alpha: 0.00
# cost: 8.87422e+18, est. time: 4225.82 GHz days (not accurate yet!)
skew: 24.759
c6: 1
c0: -230329301
Y1: -1
Y0: 648255108751911581087513909949143606546501
type: snfs
rlim: 134000000
alim: 268000000
lpbr: 32
lpba: 32
mfbr: 64
mfba: 94
rlambda: 2.7
alambda: 3.6[/CODE]
Trial sieving 5K blocks.
Note: Request starting Q0 @ 30M.
[CODE] Q Yield
30M 9851
60M 8197
100M 8100
200M 6450
300M 5898
400M 4783[/CODE]


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

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