2019 14e post processing reservations and results - Page 61

RichD · 2019-10-09, 20:37

Taking C233_M19_k86.

jyb · 2019-10-10, 18:47

Code:

p90 factor: 527319287801386637111815779104012748330879918568428556345641784967344991243118837480670391
p102 factor: 393989957301163488068558959610408822863797003421887082925785552135924029245827045773593813055130241159

https://pastebin.com/61PY4WEg

jyb · 2019-10-12, 04:53

Taking 1091_79m1.

jyb · 2019-10-12, 05:06

Taking 11503_59m1.

jyb · 2019-10-13, 03:57

Can anybody explain what's going on with the 14e status page? The last two jobs shown, 10p9_750L and 10p9_750L_take2, appear to have their work units mixed up in some way. 10p9_750L should have a total of 12500 work units, but the status page says the server has received over 13000 of them. Meanwhile, 10p9_750L_take2 should have 5000 work units, but it appears that the vast majority of them just disappear into the void when they are returned to the server.

I'm assuming that the work units returned for 10p9_750L_take2 are being counted for 10p9_750L, but setting aside the fact that things still don't quite add up correctly, how does that happen? I've verified that these two numbers have different entries in the server's management system, with different names (not just display names), and that the data files for each are being kept in separate directories. What's causing this confusion? Does the server do some sort of intentional string prefix matching on the names? And if so, toward what end, and with what effect?

jyb · 2019-10-13, 06:12

Code:

p110 factor: 21133837304875248115753274420585503358449765600875248295226696845792555337063932309187955165154961802106507329
p122 factor: 65786832450896660078594822037902188130886869036102729957283980059183747981827902360322942277496706555959090270504416545397

https://pastebin.com/WvxRyQe9

swellman · 2019-10-13, 11:33

Quote:

Originally Posted by jyb

Can anybody explain what's going on with the 14e status page? The last two jobs shown, 10p9_750L and 10p9_750L_take2, appear to have their work units mixed up in some way. 10p9_750L should have a total of 12500 work units, but the status page says the server has received over 13000 of them. Meanwhile, 10p9_750L_take2 should have 5000 work units, but it appears that the vast majority of them just disappear into the void when they are returned to the server.

I'm assuming that the work units returned for 10p9_750L_take2 are being counted for 10p9_750L, but setting aside the fact that things still don't quite add up correctly, how does that happen? I've verified that these two numbers have different entries in the server's management system, with different names (not just display names), and that the data files for each are being kept in separate directories. What's causing this confusion? Does the server do some sort of intentional string prefix matching on the names? And if so, toward what end, and with what effect?

I noticed this too but could not do anything but hope for the best. This is Greg’s area.

No idea why the siever would manage near duplicate entries that way. Are the results usuable? How many total relations were produced?

jyb · 2019-10-14, 05:48

Quote:

Originally Posted by swellman

I noticed this too but could not do anything but hope for the best. This is Greg’s area.

No idea why the siever would manage near duplicate entries that way. Are the results usuable? How many total relations were produced?

I haven't tried downloading them relations yet, though I can say that the compressed file of relations has a size and growth rate that's consistent with it receiving all of the results from both entered numbers. I.e. as of right now the status page is showing 235M relations, and that seems plausible given the size of the compressed file on the server.

But my real question is what will happen if we increase the range of the second entry. Will work units of the correct form (i.e. sieving spec-q on the algebraic side) be handed out, but the results continue to accrue to the first entry? I guess we'll just have to try it, because I think 235M raw will get cut down substantially by duplicates so it won't be enough.

unconnected · 2019-10-14, 08:16

C168_11040_10141 completed - 78 hours for 7.2M matrix (TD=140)

Code:

p69 factor: 543628290632009031159350695568462875836868218457605096562016855538923
p100 factor: 1398430717445076020061934748793362118487425798848998734454908732002363344521514640035142848463614549

https://pastebin.com/b5zTNEmt

jyb · 2019-10-14, 15:58

[QUOTE=jyb;527956But my real question is what will happen if we increase the range of the second entry. Will work units of the correct form (i.e. sieving spec-q on the algebraic side) be handed out, but the results continue to accrue to the first entry? I guess we'll just have to try it, because I think 235M raw will get cut down substantially by duplicates so it won't be enough.[/QUOTE]

Yes, adding to the range for 10p9_750L_take2 causes new results to be added to 10p9_750L, so I guess that's okay. Meanwhile, I did try downloading relations, and as expected, the duplicate rate is very high: a little over 38%. Let's give it a chance to accumulate some more.

jyb · 2019-10-14, 16:12

Code:

p90 factor: 626122935255933130090953870358188059786380205099662988821642549460808952017464181128587489
p143 factor: 11678366943149106684482644658600978080628967817258325627469895196798682316339705367001949484517268282727977569198407208509640640645165915517699

https://pastebin.com/7SbTtuRW

2019-10-13, 03:57	#665
jyb Aug 2005 Seattle, WA 2·883 Posts	Can anybody explain what's going on with the 14e status page? The last two jobs shown, 10p9_750L and 10p9_750L_take2, appear to have their work units mixed up in some way. 10p9_750L should have a total of 12500 work units, but the status page says the server has received over 13000 of them. Meanwhile, 10p9_750L_take2 should have 5000 work units, but it appears that the vast majority of them just disappear into the void when they are returned to the server. I'm assuming that the work units returned for 10p9_750L_take2 are being counted for 10p9_750L, but setting aside the fact that things still don't quite add up correctly, how does that happen? I've verified that these two numbers have different entries in the server's management system, with different names (not just display names), and that the data files for each are being kept in separate directories. What's causing this confusion? Does the server do some sort of intentional string prefix matching on the names? And if so, toward what end, and with what effect? Last fiddled with by jyb on 2019-10-13 at 03:58

2019-10-14, 08:16	#669
unconnected May 2009 Russia, Moscow A21₁₆ Posts	C168_11040_10141 completed - 78 hours for 7.2M matrix (TD=140) Code: p69 factor: 543628290632009031159350695568462875836868218457605096562016855538923 p100 factor: 1398430717445076020061934748793362118487425798848998734454908732002363344521514640035142848463614549 https://pastebin.com/b5zTNEmt

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
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
16e Post Processing Progress	pinhodecarlos	NFS@Home	8	2018-11-28 13:45
Update on 7^254+1 post processing	dleclair	NFSNET Discussion	4	2005-04-05 09:51
Post processing for 2,757-	xilman	NFSNET Discussion	3	2003-11-06 14:23

2019-10-09, 20:37	#661
RichD Sep 2008 Kansas 2·3·5·113 Posts	Taking C233_M19_k86.

2019-10-12, 04:53	#663
jyb Aug 2005 Seattle, WA 2·883 Posts	Taking 1091_79m1.

2019-10-12, 05:06	#664
jyb Aug 2005 Seattle, WA 6E6₁₆ Posts	Taking 11503_59m1.

2019-10-14, 15:58	#670
jyb Aug 2005 Seattle, WA 2·883 Posts	[QUOTE=jyb;527956But my real question is what will happen if we increase the range of the second entry. Will work units of the correct form (i.e. sieving spec-q on the algebraic side) be handed out, but the results continue to accrue to the first entry? I guess we'll just have to try it, because I think 235M raw will get cut down substantially by duplicates so it won't be enough.[/QUOTE] Yes, adding to the range for 10p9_750L_take2 causes new results to be added to 10p9_750L, so I guess that's okay. Meanwhile, I did try downloading relations, and as expected, the duplicate rate is very high: a little over 38%. Let's give it a chance to accumulate some more.