Computer isn't mine...
 

I noticed something very weird a couple of days ago when my "Workstation" computer suddenly got a load of double-check assignments, even though it's not due to receive any work. After checking it out, it seems that my actual "Workstation" computer is still crunching through its jobs and is otherwise working as intended, and all the double-check jobs, which are being processed by the looks of things, belong to a completely different computer.

But here's the thing... that second computer named Workstation isn't mine, and I have no idea where it is physically located or even who it belongs to either. It's listed under my CPU page though.

What should I do about this? Because if those jobs complete, I sense I'll be stealing someone's CPU credit.

Examples:
- One of my actual tasks: [URL="http://www.mersenne.org/M69967421"]2[SUP]69,967,421[/SUP][/URL]
- One of the unexpected tasks: [URL="http://www.mersenne.org/M43717231"]2[SUP]43,717,231[/SUP][/URL]

[QUOTE=CuriousKit;435135]I noticed something very weird a couple of days ago when my "Workstation" computer suddenly got a load of double-check assignments, even though it's not due to receive any work. After checking it out, it seems that my actual "Workstation" computer is still crunching through its jobs and is otherwise working as intended, and all the double-check jobs, which are being processed by the looks of things, belong to a completely different computer.

But here's the thing... that second computer named Workstation isn't mine, and I have no idea where it is physically located or even who it belongs to either. It's listed under my CPU page though.

What should I do about this? Because if those jobs complete, I sense I'll be stealing someone's CPU credit.

Examples:
- One of my actual tasks: [URL="http://www.mersenne.org/M69967421"]2[SUP]69,967,421[/SUP][/URL]
- One of the unexpected tasks: [URL="http://www.mersenne.org/M43717231"]2[SUP]43,717,231[/SUP][/URL][/QUOTE]

Did you accidentally create another instance of Prime95 running in another place on that same machine?

Both of those exponents are indeed assigned to the same user, but the cpu ID's are different... different machines as far as Primenet knows. But a new install on the same machine would create a new unique ID.

Both machines have checked in recently (today)... the one doing the LL test was first seen on April 27 and the machine doing the DC was first seen yesterday.

Let's see... what else could help you... LL machine says it has 16 GB and the DC machine says it has 4 GB ... both are the same speed @ 3.4 GHz.

Older box is running "Windows64,Prime95,v28.7,build 1" and newer one is running "Windows64,Prime95,v28.9,build 2"

Did you update the Prime95 version in place, or did you unzip it to a new directory and start it up separately, by any chance?

Well... probably not. Now that I look at the identifying info for the two machine's CPUs, they report as:
Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz

One thing to keep in mind... someone can run Prime95 and put in whatever user id they want (the actual login id, not the display name that shows up in reports and stuff, which can be different).

Maybe someone accidentally put your login id in... who knows. I didn't see any other users with something similar to yours, or at least similar enough that they might reasonably have mistyped it...

Well, that's all I got. Unless I wanted to crawl through log files and look more, which I don't. :smile:

On the bright side, if this was some user accidentally doing it, let them go ahead and keep chugging away and adding credit to your account. :smile: They're 4% and 4.1% through their first 2 double-checks... maybe it'll finish a few at least (ETA of June 2)

I definitely haven't added any new computers to my collection. "Shadow", "Satellite" and "Remote" are laptops that I have direct access to and can confirm are all build 2 and running as they should, and "Workstation" is my work computer (which is the only 4-core computer I have) that I remote logged in to in order to verify the processes running.

So it does look like someone who decided to name their computer "Workstation" and their user name "CuriousKit". No idea who though, but whoever it is... thank you!

[QUOTE=Madpoo;435158]One thing to keep in mind... someone can run Prime95 and put in whatever user id they want (the actual login id, not the display name that shows up in reports and stuff, which can be different).[/QUOTE]

Isn't that a problem for the integrity of the results?

If someone managed to sneak a bad residue into the database, they could self-verify it by stealing the identities of two trusted users. Some top producers turn in several exponents daily and are hardly likely to keep track of them all. If a fraud was discovered decades from now then the wrong person would get the blame.

In this vein I am thinking of [URL="http://www.mersenneforum.org/showthread.php?t=20530"]this post[/URL] regarding matching bad residues that were discovered because they had the same shift count (not a fraud but the same user accidentally manually resubmitting the same results.txt lines, once with a very old "S numerical" username and later with an actual name).

I'm also thinking of [URL="http://www.mersenneforum.org/showpost.php?p=398807&postcount=108"]this other post[/URL] which mentions the exponent [URL="http://www.mersenne.org/M1048507"]M1048507[/URL]. The interesting part here is not the fact that Ernst Mayer had a "good" result that was off by one hexadecimal digit, but that "Tom Cage" and "Cornelius Caesar" returned the same bad result.

No dates are available, but that was a result from the very earliest years, surely predating the introduction of the shift count. Could this be a single result accidentally turned in twice by the same person? There are roughly three hundred very low exponents where these two users both turned in a good result, luckily you made sure everything under 2M is triple-checked (except for [URL="http://www.mersenne.org/M958933"]M958933[/URL] for some reason). Or perhaps there was a database glitch when converting from the old PrimeNet server to the new one, or perhaps a rare bug in some very early version of the software...

I am thinking of [URL="http://www.mersenneforum.org/showpost.php?p=312848&postcount=65"]this post by LaurV[/URL], where using the wrong FFT size with an early version of CudaLucas caused a reproducible error in the residue. When exactly were shift counts introduced in Prime95, and can we be sure of all the older residues that were double-checked before that?

[QUOTE=GP2;435172]When exactly were shift counts introduced in Prime95, and can we be sure of all the older residues that were double-checked before that?[/QUOTE]

Version 17, I believe. The wavefront was at 4M or so. Note that pre-v17 results are the same as shift count equal to zero. All verified results where prime95 was used for both tests should have at least one result with a non-zero shift count.

You haven't tried running Prime95 on a virtual machine by any chance have you?

[QUOTE=GP2;435172]Isn't that a problem for the integrity of the results?[/QUOTE]

I'm not sure... I don't know if it was always that way... I kind of remember that in older versions of Prime95 you had to put the username *and* password into the configuration to connect to Primenet?

I suppose the risk of having some random stranger submit results in the name of someone else is low enough that it made more sense than having a plain text password in a bunch of configs that you might want to distribute to many machines.

[QUOTE=GP2]...There are roughly three hundred very low exponents where these two users both turned in a good result, luckily you made sure everything under 2M is triple-checked (except for [URL="http://www.mersenne.org/M958933"]M958933[/URL] for some reason). Or perhaps there was a database glitch when converting from the old PrimeNet server to the new one, or perhaps a rare bug in some very early version of the software...[/QUOTE]

Hmm... that was weird. I had to look and see why I missed that one. Turns out that there are actually *3* results for that exponent, but two are from the same user. Different programs, but shift count=0. One from Prime95 version 11 (whew, that goes back!) and the other labeled simply "Crandall".

It suffers from the same unfortunate LL report "bug" on the website that prevents multiple entries with the same timestamp (or in this case, no timestamp) and same user from appearing more than once as they should. James was actually going to help look into that, although I just realized that the idea I had to fix that wouldn't work in this case since the timestamp is actually NULL. Bummer.

Anyway, maybe I can look again at the exponents below 2M and do a triple-check of anything where only 2 shift-counts exist, instead of just 2 results.

But that one instance shows what George mentioned, that all cases where an exponent was verified with 2 different runs of no-shift-count have been extra verified by a run with a non-zero shift.

[QUOTE=GP2]I am thinking of [URL="http://www.mersenneforum.org/showpost.php?p=312848&postcount=65"]this post by LaurV[/URL], where using the wrong FFT size with an early version of CudaLucas caused a reproducible error in the residue. When exactly were shift counts introduced in Prime95, and can we be sure of all the older residues that were double-checked before that?[/QUOTE]

If I'm reading LaurV's comments on that problem correctly, it sounds like the error was reproducible, but the incorrect residues were different each time? If there was ever a case where a reproducible error would generate the same (wrong) residue, that would indeed be a problem and makes the case for why we shouldn't accept self-verified results. :smile: But in this case, I think it was just a case of the wrong too-small FFT being selected resulting in errors at a certain iteration, at which point the rest of the run was fouled up in their own unique way.

[QUOTE=CuriousKit;435135]I noticed something very weird a couple of days ago when my "Workstation" computer suddenly got a load of double-check assignments, even though it's not due to receive any work. [/QUOTE]

Not sure if this has any relevance at all, but a similar thing happened to me in mid-May. Out of the blue, I suddenly got a double-check (38615407) assignment, instead of the usual record level numbers. I checked the setting for "type of work requested" to be sure it was still world record, and that looked fine. It finished quickly, and I didn't give it any additional thought. No change in computers, etc., so I'm not sure what triggered that. Currently my assignments are back to the normal range (74M).

Norm

[QUOTE=Spherical Cow;435226]Not sure if this has any relevance at all, but a similar thing happened to me in mid-May. Out of the blue, I suddenly got a double-check (38615407) assignment, instead of the usual record level numbers. I checked the setting for "type of work requested" to be sure it was still world record, and that looked fine. It finished quickly, and I didn't give it any additional thought. No change in computers, etc., so I'm not sure what triggered that. Currently my assignments are back to the normal range (74M).

Norm[/QUOTE]

That is due to a recent change which means everyone get 1 DC per year at least unless you opt out here: [url]http://www.mersenne.org/thresholds/[/url]

[QUOTE=CuriousKit;435165]I definitely haven't added any new computers to my collection. "Shadow", "Satellite" and "Remote" are laptops that I have direct access to and can confirm are all build 2 and running as they should, and "Workstation" is my work computer (which is the only 4-core computer I have) that I remote logged in to in order to verify the processes running.

So it does look like someone who decided to name their computer "Workstation" and their user name "CuriousKit". No idea who though, but whoever it is... thank you![/QUOTE]

As Madpoo says the DC machine appeared for the first time 2 days ago and is running Prime95 28.9 build 2. Did you download the new Prime95 28.9 recently just to test it?

[QUOTE=CuriousKit;435165]I definitely haven't added any new computers to my collection. "Shadow", "Satellite" and "Remote" are laptops that I have direct access to and can confirm are all build 2 and running as they should, and "Workstation" is my work computer (which is the only 4-core computer I have) that I remote logged in to in order to verify the processes running.

So it does look like someone who decided to name their computer "Workstation" and their user name "CuriousKit". No idea who though, but whoever it is... thank you![/QUOTE]

This intrigued me enough to look at the web log files to see where the hits were coming from.

There are actually 5 different CPUs using your user id on the site, FYI... based on which assignment you said was yours I used the IP address of your most recent updates to determine where your "official" CPU named "workstation" connects from (IP address #1) and the other 4 CPUs all connect from a different spot (IP address #2).

You mentioned the names of some of your other systems "Shadow", "Satellite" and "Remote" and those 3 (plus the other one called "Workstation") are all connecting from that different IP address.

So wherever those other 3 systems are, the 4th one also named "Workstation" lives in the same spot.

Anyway, that should give you some relief... the extra "Workstation" is in the same spot as those other 3 boxes, it's not some random stranger on the intertubes, and it's "birthday" was May 29. :smile:

EDIT: Also if it helps, that extra "Workstation" reports itself as having 2 cores, 4 GB RAM, speed of 3.4 GHz even though the CPU model lookup for it says it's "Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz" ... not sure why the speed discrepancy there except that it might get that 3.4 GHz if a config file was copied over from your original "Workstation", but other things like the core count and memory adjusted themselves properly.

Also if it helps, the CPU model, speed, memory is identical to your machine "Remote" but with different application versions ("Remote" has v28.9 build 2 and the extraneous "Workstation" has v28.7 build 1)

[QUOTE=ATH;435232]That is due to a recent change which means everyone get 1 DC per year at least unless you opt out here: [url]http://www.mersenne.org/thresholds/[/url][/QUOTE]

Ah- OK. That seems pretty reasonable. Thanks for the explanation; I hadn't heard about it.

Norm

[QUOTE=Madpoo;435222]
If I'm reading LaurV's comments on that problem correctly,[/QUOTE]
you don't, there were two different residues, always the same, generated by the same program, with shift zero, for two different FFTs. That problem arose IIRC, during implementing non-power-of-two FFTs in cudaLucas, which was long before implementing the shifting. And it is normal that if you start with the same data, no random, you get the same result. The real problem was that CL was selecting the wrong FFT for it, which was later fixed. You are right in the second part of your post, it was just a case of wrong FFT selection, which kept giving [U]the same[/U] erroneous result, due to the fact that the random part (shifting) was missing, and the error checking was very poorly implemented at that time. It is not the case anymore. In fact all that discussion was in a thread and time where/when people were trying to make a reliable version of CL. I was only the "critique" there. Which CL we have today, thanks to a lot of good people who put a lot effort into developing it.

And I am still self-DC-ing :razz: (not currently, no free resources, but having big plans for the future, as usual, hehe).

[QUOTE=LaurV;435267]And I am still self-DC-ing :razz: (not currently, no free resources, but having big plans for the future, as usual, hehe).[/QUOTE]

Sigh... if you're really concerned about the reliability of your system, do the occasional double-check of someone else's work... DC could use the extra boost. :smile:

Plus that way you'd find out quicker if you were wrong (I mean, testing 36M goes much faster than testing something above 70M).

[QUOTE=LaurV;435267]It is not the case anymore. In fact all that discussion was in a thread and time where/when people were trying to make a reliable version of CL. I was only the "critique" there. Which CL we have today, thanks to a lot of good people who put a lot effort into developing it.[/QUOTE]

Yes, no doubt both CudaLucas and Prime95 are solid today. The only question was, are there any pre-shift results from long ago where perhaps the same bad residue was double-checked into the database.

The fact that this very old version of CudaLucas gave the identical wrong result reproducibly (when used with a badly-chosen FFT size) made me wonder if old pre-shift versions of Prime95 ever did the same (and I mentioned the exponent [URL="http://www.mersenne.org/M1048507"]M1048507[/URL] as an example where I wondered if that happened).

[QUOTE=Prime95;435178]All verified results where prime95 was used for both tests should have at least one result with a non-zero shift count.[/QUOTE]

Eek... may be a bug in that part of the verification.

So... since I had previously triple-checked everything below 2M (that wasn't already triple-checked), I thought, hey, why not make sure everything below 2M has 2 non-zero shift count results. Why? I don't know. :smile:

For no particular reason I queried for any verified results where the only shift-counts were zero... there are 13 of them.

All 13 had the latest verifying run done by our good friend AirSquirrels, part of the strategic double-checking he was helping me out with, especially in regards to the previous results by Robert_SoCal (who made up 12 of the 13 exponents first results).

So maybe it was my fault for assigning those to him when the first test was also done by a GPU.

Anyway, since it was probably my foul-up, I'll do a 3rd test of those 13 using Prime95 with a non-zero shift, and any others that may show up. I think AirSquirrels already finished up with those strategic double-checks and is now working with me on tackling the exponents that need triple-checks to declare the winner.

The fact that Shadow, Satellite and Remote all use the same IP address makes sense because they are all laptops running in my apartment, sharing the same router. The 4-core Workstation is my computer at my workplace and so should have a different IP address.

The fact that the second Workstation is identical to Remote and is running on the same IP address is a big clue. Basically, Remote is a "work from home" laptop, which occasionally connects to a network share. That share contains backups of the Prime95 jobs for both Remote and the 4-core Workstation (stored under different directories), so I'm wondering if I accidentally ran the Workstation backup by mistake or something similar. I'll investigate. If it's the case, then I'll reconfigure the work files so they all run on Remote, then merge the new Workstation with Remote. Would that work or could the merge cause problems due to the different CPU ids?

P.S. Sorry if I raised a false alarm.

Problem solved. It turns out that the copy of Prime95.exe in the backup directory somehow got executed and fetched its own work, at the same time while the regular copy was running. What it resulted in was "Remote" trying to perform twice as many tasks as it was supposed to and hence being somewhat slow on everything.

I've resolved the problem now by shutting down the running processes, making backup copies of what's been computed so far, merging the worktodo.txt files, and synchronising the network share (which also updated the copy of Prime95.exe that got executed somehow).

When I started up Prime95.exe again, a couple of the DoubleCheck tests (M43835747 and M43863007) got automatically unassigned, presumably due to unrealistic completion times - they were nowhere near close to even being started, so I wasn't worried about those, although it's nice to have warning before a task is unassigned sometimes, in case it actually [I]has[/I] been started, say. I do like to complete double-check tasks occasionally... to do my bit in making certain that the list of Mersenne numbers is reliable and to clear the back-log, even if I get no fame from it - it's a good community service!

Sorry if I caused any worries for anyone. It was what people suggested it was... I just wasn't aware that the backup copy of the program started somehow (most likely due to being configured to run on start-up or something). Thank you MadPoo for giving me the clues I needed to identify the problem, since I probably wouldn't have even identified the computer in question.

The potential exploit that was pointed out is something to consider though.

P.S. I dropped the extra "Workstation" CPU that appeared, so I should only have 4 computers to my name currently.

[QUOTE=CuriousKit;435328]The potential exploit that was pointed out is something to consider though.[/QUOTE]

No real exploit. If someone wants to give you credits, is this a serious problem?

LaurV played a bit of a joke on me a couple of years ago. He gave me some serious credits.

Perhaps it's a problem if someone gives you bad results.

Karma goes a long way....

[QUOTE=Madpoo;435312]For no particular reason I queried for any verified results where the only shift-counts were zero... there are 13 of them.

All 13 had the latest verifying run done by our good friend AirSquirrels, part of the strategic double-checking he was helping me out with, especially in regards to the previous results by Robert_SoCal (who made up 12 of the 13 exponents first results).

So maybe it was my fault for assigning those to him when the first test was also done by a GPU.[/QUOTE]

So...even the latest versions of GPU-based LL testing programs still use shift count = 0 ?

[QUOTE=CuriousKit;435328]When I started up Prime95.exe again, a couple of the DoubleCheck tests (M43835747 and M43863007) got automatically unassigned, presumably due to unrealistic completion times - they were nowhere near close to even being started, so I wasn't worried about those, although it's nice to have warning before a task is unassigned sometimes, in case it actually [I]has[/I] been started, say. I do like to complete double-check tasks occasionally... to do my bit in making certain that the list of Mersenne numbers is reliable and to clear the back-log, even if I get no fame from it - it's a good community service![/QUOTE]

You can add UnreserveDays= to your prime.txt. Prime95 will then only unreserve assignments if worktodo.txt exceeds that number of days.

Aah, thanks. What is the default value if "UnreserveDays=" isn't specified? It only unreserved them when I put the Double Check tests that hadn't started at the end of the work to-do list - there was also an LL test that was partially complete; originally that one was at the end of the list instead, but wasn't unreserved (thankfully!). Only after rearranging the list in order to complete it more quickly (basically, right after the DC test that was in progress) did it unreserve those two tests.

[QUOTE=chalsall;435329]No real exploit. If someone wants to give you credits, is this a serious problem?

LaurV played a bit of a joke on me a couple of years ago. He gave me some serious credits.

Perhaps it's a problem if someone gives you bad results.

Karma goes a long way....[/QUOTE]

Yeah, I don't think it's an issue. Worst case, someone "joins" your account and submits a bunch of bad results, but any type of good/bad in terms of what kind of cat 0 or cat 1 work you get is based solely on that CPU, not the user id.

[QUOTE=GP2;435330]So...even the latest versions of GPU-based LL testing programs still use shift count = 0 ?[/QUOTE]

Yeah... weird huh?

[QUOTE=chalsall;435329]LaurV played a bit of a joke on me a couple of years ago. He gave me some serious credits.[/QUOTE]
Not my idea, Kracker did it to me first, giving me some DC credit. That is where I got the idea from. :blush:

edit: This has another funny story attached to it, after the joke ended, he switched his computers back, but forgot one of them, which still continued to report results on my name for few consecutive months, haha...

[QUOTE=GP2;435330]So...even the latest versions of GPU-based LL testing programs still use shift count = 0 ?[/QUOTE]
Only for clLucas, which is very seldom used.
cudaLucas has the shifts implemented years ago.