mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Information & Answers (https://www.mersenneforum.org/forumdisplay.php?f=38)
-   -   Duplicated credit (https://www.mersenneforum.org/showthread.php?t=13704)

Unregistered 2010-08-09 02:07

Duplicated credit
 
A few days ago, when prime95 was sending a result, the communication timed out after 180 seconds with 0 bytes received. Later, when the client tried to send the result again, I got an error 40: no assignment, and was told that the result was not needed. Since it was reserved the usual (automatic) way, all I can think of is that in the first communication the result actually "got in", and in the second one, it was no longer necessary (it was already reported).

Anyway, since that time the result count in the User Summary doesn't match the amount of results in results.txt (it did before this). In fact, the difference is 2, when only 1 result had the problem I talked about before.

To make sure that no result got lost (the server results count was lower than the results.txt one), I uploaded the results.txt file thru the manual results page. The server (correctly) rejected most results as unnecessary, but all the ECM results were credited again, and now I have 90 more duplicated results, and their duplicated credit, with the CPU "Manual testing".

I guess that the server can't tell if two ECM results of the same expo, B1, B2, and number of curves are the same or not.

Is there anything that can be done to fix this? My main concern is that Primenet will think that more work has been done than the actual amount, and that people can use this potential bug to make more credit, something that I wasn't trying to achieve (in fact, I would be glad to have the duplicated credit and results removed).

petrw1 2010-08-09 16:45

The same topic in another thread....
 
You can see more discussion about the same topic over here (nearer the end):
[url]http://www.mersenneforum.org/showthread.php?t=5758&page=2[/url]

Unregistered 2010-08-09 17:58

I just noticed that I also got a couple of error 11: server database malfunction around the same time of the other errors. Those sound more serious than the others.

George, if it helps to diagnose this issue, I have a copy of prime.log, the duplicated results, the manual results page which duplicated the credit, and so on.

petrw1, I just read the posts you mention and my situation is similar but not quite the same, because the results that got the "no assignment" error are credited to my results page and to the exponent status page. That is, despite the error (and the things I mentioned in the first post), the results seem to have been registered correctly.

Unregistered 2010-08-09 22:27

Just moments ago it happened again: a communication timeout, and later the no assignment error. Is something going really wrong with the server? I mean, having contributed to GIMPS for more than a year I don't remember any other ocassion of this kind of errors, specially with this frequency.

Unregistered 2010-08-11 19:50

Is there anything that can be done to remove the false credit and results (besides creating another account)?

Unregistered 2010-08-11 21:50

Checking the prime.log I confirmed that this problem is recent: going all the way back to October-November 2009, only 5 times the "no assignment" error ocurred. The first time was July 11, then twice in August 6 and also twice in August 9.

If there is anything I can do to help diagnose this, please let me know.

Unregistered 2010-08-11 22:34

Poached!
 
I'm sorry to post so often, but I have new information about these problems.

Browsing the logs, I found the five results with the error 40 I mentioned before. Surprinsingly, all five results are correctly credited in the results page, and their history is correctly recorded in the exponent status (something that didn't happen to petrw1). Because of this, I still did not know why my results count does not match anymore.

But I looked further and finally found the problem: I WAS POACHED. The (guess how many?) two exponents in question are 848684891 and 848672197. I reserved them following Primenet rules, worked on them, sent expected completion dates daily, and returned the results within 3 days of their reservation. All that only to receive a SUCCESS (WTF) code that told me that the results were not needed. If you look in the database you can see that the user BloodIce returned both results. I suppose he "beat me" to it.

I can understand (but not agree with) poaching "stragglers" in DC or even LL. What I can not understand is how someone can completely bypass the usual protocols, take two exponents that are years away from being tested, and report them without being rejected.

What is even harder to understand is the server allowing that, and REJECTING THE RESULTS FROM THE RIGHTFUL OWNER, not giving credit, not registering the result, and so on. Because of that poaching (which I didn't know at the time), I feared that some results were lost, and sent my results.txt manually, hoping to contribute to a more accurate database.

And that worry led to my current situation: missing results and credit, and, because of my later actions, being with a ton of duplicated false results and their corresponding credit.

In short: my account now is missing the two poached results (and that can't be corrected, at least from my end), has 90 repeated results that it shouldn't have, has much more (50+ GHz-days) credit than it should (more than 20% of the total), and the server gladly encourages poaching, when it should take the result from the correct person and give credit, even if it received it first from someone else.

I thought that if someone reported a result in a number reserved by someone else, the server would simply dismiss it. I guess I was wrong.

My interest in contributing has diminished significantly, and I may cease to do it.

Uncwilly 2010-08-11 23:56

What you experienced was rare. I would hope that you would not leave, just because of this isolated incident.

ckdo 2010-08-12 00:07

CPU credit is 0.002313 GHz-days for each of the two exponents.

An i7-750 (not overclocked) will finish 8,000+ such assignments per day, or take less than 11 seconds for one. Actually reserving those 8,000+ assignments would take several hours - which is why it's usually not done.

You should probably get over the 22 seconds of CPU time you lost and the time you took researching the reasons thereof, as well as complaining about the case.

Unregistered 2010-08-12 03:01

Perhaps the tone of my post was taken the wrong way. I really don't mind credit at all. I'm not going to die if my account has 2 points less or more. What I don't like about this is knowing that anyone can make other people waste time in an assignment that will be rejected. Whether that time is 1 second or 3 months is irrelevant (although in my case it was way more than 11 seconds).

Also, don't forget the double-crediting problem. In the whole picture, this situation made me "win" 50+ (yes, fifty) GHz-days, instead of losing 0.002313. But I really don't want the server to believe that all those ECM curves were done twice when that is not the case, and I don't like my stats to reflect something that is utterly wrong. Why do we keep stats at all, then?

After all, we donate time and money to this project for free. Is it that much to want these little things? I'm not asking more that having the server have the correct data, and not being so easygoing on people taking other people's assignments.

Telling me to "get over" the credit, the research and the complaining, then, is completely uncalled for. I came to the forum reporting a problem that I think is of interest to the people running this, and get pointed at like some loser that can't get over 2 seconds of lost computing time. Even more, if I wanted (I don't), I could keep reporting those ECM results to get up in the rankings for free, and that should be fixed/solved.

Uncwilly 2010-08-12 06:29

If you are going to work up in the LMH range (exponents above 100,000,000) you need to claim them by posting in the appropriate part of the forum
[url]http://www.mersenneforum.org/forumdisplay.php?f=46[/url]

If you don't claim the range, you do run the risk of getting over run (if you are working at lower bit levels.)

ckdo 2010-08-12 15:29

[quote=Unregistered;225011]What I don't like about this is knowing that anyone can make other people waste time in an assignment that will be rejected.[/quote]

What I was trying to say is that, at the far high end of PrimeNet's exponent scale, it becomes infeasible for the people doing 99.999% of the work there to respect single assignments by others. They have a hard enough time not stepping on each others' toes. Credit goes to whoever finishes an exponent first, not whoever reserved it.

Yes, this could be changed. If you reserved an assignment you could get the credit even if someone else completed it. That would then lead to people reserving exponents and never processing them, waiting for free credit when someone else did, probably.

Or if you have reserved an assignment and someone else finishes it, they couldn't get any credit at all (ignoring the result alltogether, eventually), and you wouldn't get the credit until you actually finish the assignment yourself. Now since whoever reported the result supposedly did the work, too, is it fair not to credit them?

[quote=Unregistered;225011]Also, don't forget the double-crediting problem.[/quote]

As far as ECM is concerned, the problem of potential double credit can not easibly be avoided. A single exponent may require hundreds of thousands of curves at various bounds to be run on it in order to come up with a factor.

People will report that they have done this and that many curves at some bounds or other, and if they can back up that claim with the correct checksum for the task, they will get the credit. If they later run the same amount of curves with the same bounds on the same exponent, the checksum will be identical. There's no way of telling whether someone actually did the work twice or is just reporting the result twice.

Consider the analogy with bank notes: If you hand me 20 one dollar bills, I will usually trust you that no two of them have the same serial number. Now even if I kept track of all bills I ever had, I will probaly not call the police if you come back a year later to hand me another 20 one dollar bills and I find that I had already received one of them the year before. I would assume that by whatever means you got the exact same bill back, and accept it.

Likewise, the "serial number" for an ECM curve is the combination of exponent, bounds, and s-value. Even if you reported your individual s-values along with the rest and the server kept track of all of them to identify duplicate curves, what would you expect to happen? You'd report 20 curves and be credited 19. You may still have come up with the same s-value by coincidence, in which case you'd be missing credit for work you truly did. The only ways of making sure that no s-value is reused are either transferring the entire list of used s-values to the client or the client asking "is this s-value okay?" before it actually does the work, neither of which is even remotely feasible in terms of storage space, bandwidth, and CPU time, as well as breaks compatibility with all existing software.

[quote=Unregistered;225011]Is it that much to want these little things?[/quote]

These "little things" are actually quite insurmountable obstacles. Either you double credit work, which would increase the potential of cheating, or you don't credit work which actually has been done. Neither is a good choice, and depending on the type of work, different (non-) solutions to the problem have been found.

As long as you stay on the beaten track, you're mostly safe. Deep in the woods, however, you may encounter bears, and the rangers may not be there to shoot them. As far as PrimeNet is concerned, both ECM and (TF-) LMH should be considered the woods.

Occassionaly, a bear may even shit, err, cheat in the woods. That issue is best ignored. There's a number of people around who will double check unrealistic results, identifying both software bugs and cheaters in the process.

Unregistered 2010-08-12 17:27

Thanks for the detailed explanation, ckdo. I should have been more clear when I said "little things". It's probably quite a challenge avoiding the manual duplication before it happens, but perhaps it would be more viable allowing the user say to the server "hey, those results are duplicated, please remove them" once they are submitted. Another way could be telling George which results are duplicated, but I suppose that would be too time consuming.

bloodIce 2010-11-03 16:24

My excusses
 
I was really astonished to see my nickname engaged in this discussion. Firstly, I am sorry to Unregistered for what I seem to have caused. I have an explanation. I remember that during a day in August I was checking exponents in some range, I guess the mentioned range unaware that someone else is working in the same range. I think I noticed that I overlapped with someone so I aborted the whole schedule for my program. Than I checked what was the current report for current range. I found 3 or 4 exponents which were not factored to the border (64 I assume). I was surprised that whoever was working there missed those. So I run those (which took me around 10 min) and I was really surprised that the first returned a factor, second returned a factor... and up till the last. The factors were submitted automatically after they were found. Well, I would like to say sorry for that. I do not know what to do now with the issue. I could agree that those 3 or 4 exponents belong to Unregistered and if it is possible they could be stripped from my record. P.S. The exponents I was talking about were TF, not ECM efforts, so the time spend on those was less than 5 min probably. 848684891 and 848672197 are still not factorized and yes I was TF-ing them to 64. However, I could not see which are the exponents in question 848171213, 848171747, 848195707 and 848198129 may be?


All times are UTC. The time now is 09:14.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.