2020 “small” 15e post processing reservations and results - Page 6

jyb · 2020-10-30, 21:45

Quote:

Originally Posted by pinhodecarlos

Just wait then until they are reassigned, wus have a 7 day limit.

If I thought there were no returns because of bunkering, then yes, that would be a fine suggestion. My whole point is that I find it very doubtful that out of more than 15000 work units, every single one of them is being held onto for this reason. If that were true, then we wouldn't expect to see any returns from 13_2_873m1 either. Yet there they are.

Shouldn't we consider the possibility that there's an actual problem of some kind with 5_2_791m1 which is preventing work units from being processed correctly on return? It's not like that sort of thing hasn't happened occasionally in the past.

pinhodecarlos · 2020-10-30, 21:58

Quote:

Originally Posted by jyb

If I thought there were no returns because of bunkering, then yes, that would be a fine suggestion. My whole point is that I find it very doubtful that out of more than 15000 work units, every single one of them is being held onto for this reason. If that were true, then we wouldn't expect to see any returns from 13_2_873m1 either. Yet there they are.

Shouldn't we consider the possibility that there's an actual problem of some kind with 5_2_791m1 which is preventing work units from being processed correctly on return? It's not like that sort of thing hasn't happened occasionally in the past.

Don't see what´s the problem regarding your first paragraph. I know some of those big hitters have enough cores or virtual machines setup to host more than 15,000 wus in a row.
2nd paragraph, maybe. Just wait please. Let the challenge go away to troubleshoot what's going on. The only thing now is do not mess around during the challenge window, this is the only thing I am asking for now.

VBCurtis · 2020-10-30, 22:01

The poly is bad- I cut and pasted from my linux terminal, not noticing that it cut off the n: line with a $ at the end of the visible line.

So, as jyb correctly surmised, those 15000 WUs are bad. :-/

I'll re-post the corrected poly file in the queue management thread.

Charybdis caught this same mistake on my Aliquot C196 to 16e queue thread, and I forgot and did it again after doing 5_784 and 13_873 correctly.

Mea Culpa.

pinhodecarlos · 2020-10-30, 22:06

Quote:

Originally Posted by VBCurtis

The poly is bad- I cut and pasted from my linux terminal, not noticing that it cut off the n: line with a $ at the end of the visible line.

So, as jyb correctly surmised, those 15000 WUs are bad. :-/

I'll re-post the corrected poly file in the queue management thread.

Charybdis caught this same mistake on my Aliquot C196 to 16e queue thread, and I forgot and did it again after doing 5_784 and 13_873 correctly.

Mea Culpa.

This will mess guys bunkering, they will see all wus giving errors, nevertheless it is possible to bunker 15,000 wus BTW. I can do that with my old laptop tricking the server to see my laptop with 512 cores for example. Glad you managed to detect the issue.

VBCurtis · 2020-10-30, 22:15

I fully believe that they could grab that many workunits- but, as jyb said, zero coming back when all other numbers still have a trickle returning suggested investigation was necessary.

The problem was simple to catch, but that doesn't change the status of those 15,000 workunits.

pinhodecarlos · 2020-10-30, 22:19

Fair enough.

frmky · 2020-10-31, 03:03

I canceled the WUs on the server. When they next connect to the server, those WUs will be canceled locally.

RichD · 2020-11-01, 16:24

Code:

p86 factor: 19652183625441417364455036701749227215746653115421156493850613911841785292330548132931
p100 factor: 7074552900597229236192695114691356909702349100114562034686087633821472243730999357334985850406421321

207M unique relations built a 12.0M matrix using TD=120. (124 failed)
Solve time about 114 hours. (-t 3)

Log at: https://pastebin.com/VEnWGs4g

chris2be8 · 2020-11-01, 17:24

f57_142p1_2nd_try has built a matrix. About 66 hours remain so I should have a result on Wednesday.

Chris

jyb · 2020-11-02, 19:11

Taking 7p4_302.

chris2be8 · 2020-11-04, 16:41

f57_142p1_2nd_try is done:

Code:

p63 factor: 167552745124874086437111677817378592021218235263605211795460501
p127 factor: 1418723206877549581259386845930718578719177439135569583383952710748369719861830037858937637046396185716684523600568438957459509

Log at https://pastebin.com/2BjBtKCn

Reported to factordb and http://myfactors.mooo.com/

And f62_139m1 has built a matrix. About 69 hours remain so I should have a result on Saturday.

Chris

2020-11-01, 16:24	#63
RichD Sep 2008 Kansas 3×5×13×17 Posts	9p8_305 factored Code: p86 factor: 19652183625441417364455036701749227215746653115421156493850613911841785292330548132931 p100 factor: 7074552900597229236192695114691356909702349100114562034686087633821472243730999357334985850406421321 207M unique relations built a 12.0M matrix using TD=120. (124 failed) Solve time about 114 hours. (-t 3) Log at: https://pastebin.com/VEnWGs4g

2020-11-04, 16:41	#66
chris2be8 Sep 2009 3⁴·5² Posts	f57_142p1_2nd_try is done: Code: p63 factor: 167552745124874086437111677817378592021218235263605211795460501 p127 factor: 1418723206877549581259386845930718578719177439135569583383952710748369719861830037858937637046396185716684523600568438957459509 Log at https://pastebin.com/2BjBtKCn Reported to factordb and http://myfactors.mooo.com/ And f62_139m1 has built a matrix. About 69 hours remain so I should have a result on Saturday. Chris

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
2020 14e post processing reservations and results	swellman	NFS@Home	544	2020-12-31 15:14
2020 15e post processing reservations and results	swellman	NFS@Home	112	2020-12-29 22:58
2019 14e post processing reservations and results	swellman	NFS@Home	862	2019-12-31 10:51
2018 15e post-processing reservations and results	fivemack	NFS@Home	221	2019-01-04 13:08
2018 14e post processing reservations and results	pinhodecarlos	NFS@Home	551	2019-01-04 13:06

2020-10-30, 22:01	#58
VBCurtis "Curtis" Feb 2005 Riverside, CA 1001001111100₂ Posts	The poly is bad- I cut and pasted from my linux terminal, not noticing that it cut off the n: line with a $ at the end of the visible line. So, as jyb correctly surmised, those 15000 WUs are bad. :-/ I'll re-post the corrected poly file in the queue management thread. Charybdis caught this same mistake on my Aliquot C196 to 16e queue thread, and I forgot and did it again after doing 5_784 and 13_873 correctly. Mea Culpa.

2020-10-30, 22:15	#60
VBCurtis "Curtis" Feb 2005 Riverside, CA 2²×7×13² Posts	I fully believe that they could grab that many workunits- but, as jyb said, zero coming back when all other numbers still have a trickle returning suggested investigation was necessary. The problem was simple to catch, but that doesn't change the status of those 15,000 workunits.

2020-10-30, 22:19	#61
pinhodecarlos "Carlos Pinho" Oct 2011 Milton Keynes, UK 1315₁₆ Posts	Fair enough.

2020-10-31, 03:03	#62
frmky Jul 2003 So Cal 2·3·347 Posts	I canceled the WUs on the server. When they next connect to the server, those WUs will be canceled locally.

2020-11-01, 17:24	#64
chris2be8 Sep 2009 3⁴×5² Posts	f57_142p1_2nd_try has built a matrix. About 66 hours remain so I should have a result on Wednesday. Chris

2020-11-02, 19:11	#65
jyb Aug 2005 Seattle, WA 2·3·283 Posts	Taking 7p4_302.