tf results not needed
 

Hello,

A few days ago I got some assignments for dc-tf.
Today I reportet the results but most of them were 'not needed'.
See attached error-text.
Any info about this problem available?

tia, Matthias

There is no such work type as double-checking of trial factoring. Each bit range for each exponent should only be done once. Even if there's some error and factors are missed, it's no big deal because the LL test will still get done.

For some exponents, like [M]M47389751[/M], you were the first to do the range 2[SUP]72[/SUP] to 2[SUP]73[/SUP] and you received credit for it. For others like [M]M47397607[/M], you ended up doing a redundant check for which someone else (it seems it was kladner) turned in a result for this range one day earlier, and received no credit.

[QUOTE=GP2;473424]There is no such work type as double-checking of trial factoring.[/QUOTE]
DC-TF means (extended) TF on DC candidates. This is a "GPU to 72" work type. The exponent is handed over via GPUto72 site, and it usually manages to avoid double reservation, but sometimes stuff happens.
The OP is a problem report for chalsall.

[QUOTE=GP2;473424]There is no such work type as double-checking of trial factoring. [/QUOTE]

As axn said, it is a work type of GPUto72. If a factor is found the LL-DC
is not needed and it saves some GHz-Days of work for GIMPS.

If kladner is the same as GIMPS-user 'ktony' then I'm pretty sure
that he got a regular assignment from GPUto72 like me, too.
The simple question is: why?
As you turned out, a dc of a tf is really not needed :wink:

chalsall should have a look at the assignment-rules, maybe there is a problem.
And the credit I will spend for Xmas *g*

[QUOTE]If kladner is the same as GIMPS-user 'ktony'[/QUOTE]Yep. They are the same.
[QUOTE]I'm pretty sure that he got a regular assignment from GPUto72 like me, too.[/QUOTE]This is also true. Sorry we bumped into each other this way. As you say, perhaps Chris (chalsall) should have a look.

As a note, the server will accept results with overlapping ranges as long as the overall bit level is increased. For example, you can still get credit for submitting "no factor from 2^72 to 2^74" results. Of course, you shouldn't do this unless you've actually factored to 74 bits.

I personally think that the server should be changed to accept duplicate results. From an academic perspective, it's probably a good idea for all results (at least the "no factor" ones) to be independently verified.

[QUOTE=kladner;473456]This is also true. Sorry we bumped into each other this way. As you say, perhaps Chris (chalsall) should have a look.[/QUOTE]

Sorry about this. I do try my best to avoid the duplication of effort.

But it appears that kladner reserved several assignments, and then shortly unreserved them. But then completed them. The Status column of 90 means manually unreserved; the Completed column in that case is when it was unreserved.

[CODE]MariaDB [factfind]> select Exponent,User,Status,FactFrom,FactTo,Assigned,Completed,GHzDays from Assigned where Exponent=47397619;
+----------+----------------------------------+--------+----------+--------+---------------------+---------------------+---------------+
| Exponent | User | Status | FactFrom | FactTo | Assigned | Completed | GHzDays |
+----------+----------------------------------+--------+----------+--------+---------------------+---------------------+---------------+
| 47397619 | 0b704871bc2c1d367ffd1518c35d6e60 | 1 | 68 | 69 | 2013-10-14 08:41:11 | 2013-10-17 19:15:04 | 1.2612853050 |
| 47397619 | 2423ae6e8f696d5e7d1447de91ca35a6 | 1 | 69 | 70 | 2015-05-24 13:21:52 | 2015-05-26 21:15:27 | 2.5225706100 |
| 47397619 | ea39a75de82cd896610be22735054fc5 | 1 | 70 | 71 | 2015-06-14 08:08:56 | 2015-06-15 08:16:39 | 5.0451412201 |
| 47397619 | 7fac3b9d4f6ca691282b08af536d6adf | 1 | 71 | 72 | 2015-11-06 20:46:20 | 2015-11-20 19:44:06 | 10.0902824402 |
| 47397619 | 8ad778c87c3d88f688fef4ebad36994c | 90 | 72 | 73 | 2017-12-05 04:24:49 | 2017-12-05 04:25:09 | 20.1805648804 |
| 47397619 | 8ad778c87c3d88f688fef4ebad36994c | 90 | 72 | 73 | 2017-12-05 04:25:32 | 2017-12-05 04:35:13 | 20.1805648804 |
| 47397619 | 59d92a384f7b1bbe129f3696e4256adb | 1 | 72 | 73 | 2017-12-05 11:14:37 | 2017-12-07 12:27:25 | 20.1805648804 |
+----------+----------------------------------+--------+----------+--------+---------------------+---------------------+---------------+
7 rows in set (0.00 sec)[/CODE]

I know this doesn't help at all, but you did get the credit on GPU72.

[QUOTE=chalsall;473505]Sorry about this. I do try my best to avoid the duplication of effort.

But it appears that kladner reserved several assignments, and then shortly unreserved them. But then completed them. The Status column of 90 means manually unreserved; the Completed column in that case is when it was unreserved.[/QUOTE]
Oh no! My apologies to all concerned. I have used Unreserve All, but usually before having copied anything to working files. Very sorry for the carelessness.

[QUOTE=kladner;473509]Oh no! My apologies to all concerned. I have used Unreserve All, but usually before having copied anything to working files. Very sorry for the carelessness.[/QUOTE]

Shit happens.

Please try to be more careful in the future.

:redface:

Thank you for all information.
As I said, the credit doesn't matter.
The problem seems to be that the GIMPS-DB doesn't know
which GPUto72-user finally got the assignment.

......hmmmmmm, only to answer the question:
if the credit is not the problem of the OP, what is the problem of the OP? :grin:
The real problem were the '[COLOR=Red]red-bad-angry[/COLOR]' output lines in GIMPS '[COLOR=Red]result not needed...[/COLOR]'
Change them to '[COLOR=Lime]green-lovely-smiling[/COLOR]' output lines '[COLOR=Lime]result already known, used as
verification, creditet with 0.000 GHz-days[/COLOR]' and I will never again recognize them :lol: