[QUOTE=fivemack;451162]Please check that alim is about the same size as expected Q_max before queuing jobs; 842592:i8053, which has alim=10^8 for a 360MQ job, is sieving really very slowly.[/QUOTE]

Please check this errors:

[url]https://escatter11.fullerton.edu/nfs/forum_thread.php?id=662[/url]

Grr, that's irritating, and I can't fix it through the management interface: Greg will have to do it. It would be nice to forbid colons in task names at the job-submission stage.

I guess if we're only getting Linux sievers that would explain why it's going so slowly.

[QUOTE=fivemack;451171]Grr, that's irritating, and I can't fix it through the management interface: Greg will have to do it. It would be nice to forbid colons in task names at the job-submission stage.

I guess if we're only getting Linux sievers that would explain why it's going so slowly.[/QUOTE]

Yes, apologies for mucking that up. I was never given any information about what constituted legal characters for the name.

As for the parameters, they're not great but as you've suggested I don't think that's the reason it's sieving slowly. The yield is within a tolerable range. It's just that there are very few work units being done. The status page has been showing alarmingly low numbers of pending units for a while, and I didn't have an explanation as to why. Now I do.

Can we get Greg to cancel outstanding work units, then re-insert the number with a new name? And if that happens, is there a way to carry over the relations that have already been found?

Another observation
 

The 14e queue is behaving normally except for the last entry. Nothing is moving from Pending to Received. This has been going on for hours and hours. May be nothing.

[QUOTE=RichD;451178]The 14e queue is behaving normally except for the last entry. Nothing is moving from Pending to Received. This has been going on for hours and hours. May be nothing.[/QUOTE]

No, it's not nothing. Thanks for pointing that out. The original request for this number included the polynomials/parameters, which I just copied into the form. Unfortunately it contained an errant line break in the middle of the "n:" line. Added anew.

[QUOTE=jyb;451174]Yes, apologies for mucking that up. I was never given any information about what constituted legal characters for the name.

As for the parameters, they're not great but as you've suggested I don't think that's the reason it's sieving slowly. The yield is within a tolerable range. It's just that there are very few work units being done. The status page has been showing alarmingly low numbers of pending units for a while, and I didn't have an explanation as to why. Now I do.

Can we get Greg to cancel outstanding work units, then re-insert the number with a new name? And if that happens, is there a way to carry over the relations that have already been found?[/QUOTE]

If Dmitry doesn't mind, I'd be inclined to download all the relations found so far, delete the job, do the rest of the sieving with my own resources, and run the linear algebra myself. Would that be OK?

It's ok with me. According to status page now about 96% of sieving were done.

14e candidate
 

C196_145_47 - survived full t55 by yoyo.

[code]
n: 1539638978922756670166928811628782239346356516505821625978040069660069049848080998194283427693933723544136963787753348060058257380159087715113685388408710955508626354533622263911689449038438482213
# 145^47+47^145, difficulty: 242.45, anorm: 2.90e+032, rnorm: 1.14e+054
# scaled difficulty: 246.05, suggest sieving rational side
# size = 6.363e-017, alpha = 0.000, combined = 1.774e-013, rroots = 1
type: snfs
size: 242
skew: 7.3206
c5: 1
c0: 21025
Y1: -28334269484119140625
Y0: 3096263264537031876137686856267255616967297523567
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code]

[QUOTE=jyb;451183]No, it's not nothing. Thanks for pointing that out. The original request for this number included the polynomials/parameters, which I just copied into the form. Unfortunately it contained an errant line break in the middle of the "n:" line. Added anew.[/QUOTE]

I presume this is C222_125_92b. My cut/paste submittal but I have no idea how a random line break got into the mix. My fault for not noticing it. Apologies to all. Won't happen again.

14e candidate
 

C213_121_106 - survived 4K curves @B1=11e7 and 4K curves @B1=3e8.

[code]
n: 242203525663681892246786058737395625770451922074691383053760278389874986634479141176831595050748121453887679020782594441722484311032448030112575838772991966136007682217835911089128815053532392058505386628231019751
# 121^106+106^121, difficulty: 247.09, anorm: 2.27e+038, rnorm: 3.17e+046
# scaled difficulty: 248.44, suggest sieving rational side
# size = 1.726e-012, alpha = 0.000, combined = 1.828e-013, rroots = 0
type: snfs
size: 247
skew: 1.0223
c6: 106
c0: 121
Y1: -2810243684806424785061213903353404851
Y0: 32071354722128447318829929845779491454976
rlim: 134000000
alim: 134000000
lpbr: 31
lpba: 31
mfbr: 62
mfba: 62
rlambda: 2.7
alambda: 2.7
[/code]

AS 3408
 

AS3408-i1668 (15e siever)

[code]
n: 29460893303338144751360360097976743017149046981259832053501450854362438285630845458294329588136961317820466603439061784124252469966169391148524869909406500896547611862071404959591325864761463
# norm 1.222655e-18 alpha -8.479287 e 1.735e-14 rroots 3
skew: 17653518.44
c0: 826319531224681659341264214653314828053252960
c1: 26940857953335994224321141436849154800
c2: -22688220016211567990602767782164
c3: 15607687492217763886884
c4: 54690847245705303
c5: 1286485200
Y0: -1870545265872388890161243166679811449
Y1: 554791760382776548817
rlim: 450000000
alim: 450000000
lpbr: 33
lpba: 33
mfbr: 66
mfba: 66
rlambda: 3.0
alambda: 3.0
[/code]

Test sieving on the -a side for 10K range at various Q starting values were as follows:

Q_start yield
150M 2.17
300M 2.15
450M 1.81
600M 1.80

alim of 450M seems to work nicely, but perhaps it should be 500M. This factorization is outside my comfort zone.