Taking C233_M19_k86.

12p11_233 factored
 

[code]
p90 factor: 527319287801386637111815779104012748330879918568428556345641784967344991243118837480670391
p102 factor: 393989957301163488068558959610408822863797003421887082925785552135924029245827045773593813055130241159
[/code]

[url]https://pastebin.com/61PY4WEg[/url]

Taking 1091_79m1.

Taking 11503_59m1.

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?

1091_79m1 factored
 

[code]
p110 factor: 21133837304875248115753274420585503358449765600875248295226696845792555337063932309187955165154961802106507329
p122 factor: 65786832450896660078594822037902188130886869036102729957283980059183747981827902360322942277496706555959090270504416545397
[/code]

[url]https://pastebin.com/WvxRyQe9[/url]

[QUOTE=jyb;527876]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?[/QUOTE]

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?

[QUOTE=swellman;527892]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?[/QUOTE]

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.

C168_11040_10141 completed - 78 hours for 7.2M matrix (TD=140)
[CODE]p69 factor: 543628290632009031159350695568462875836868218457605096562016855538923
p100 factor: 1398430717445076020061934748793362118487425798848998734454908732002363344521514640035142848463614549[/CODE]
[url]https://pastebin.com/b5zTNEmt[/url]

[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.

11503_59m1 factored
 

[code]
p90 factor: 626122935255933130090953870358188059786380205099662988821642549460808952017464181128587489
p143 factor: 11678366943149106684482644658600978080628967817258325627469895196798682316339705367001949484517268282727977569198407208509640640645165915517699
[/code]

[url]https://pastebin.com/7SbTtuRW[/url]