[quote=gd_barnes;162870]So, how are Karsten or I supposed to balance the results? Ugh![/quote]
Well, that actually wouldn't be too big a deal. Remember, all (or at least almost all) of the results *are* there, and in the correct daily files. The only difference from normal is that they're a little out of order within their correct daily file--but that's no big deal since the results come in from the server out of order in the first place, and will have to be sorted anyway during processing/balancing. Even if there are any missing k/n pairs, they'll be caught quite quickly and easily during processing. :smile:

[quote]I have to beg to differ with you. Correct test plans would quickly catch this. I've worked in the programming industry long enough to know it. You pick what and when you want tested and run TEST data through it at the time that simulates the test that you want to conduct. In this case, run test data from 11:45 PM to 12:15 AM local time and verify that the results are properly being copied off. If not, it's not a big deal because it's misc. test data that we care nothing about.

When we say a test plan, we're talking about using test and not production data. If we "test in production" like this, we get burned.

I know I'm beating a dead horse now but:

For the PRPnet server, I would suggest that we start putting a test plan together and creating some test data for it fairly soon and long before we actually get to loading production data into it.

BTW, I can break anything. lol I've tested legacy stuff for so many years; if there's a bug in something that I'm quite familiar with, I will find the scenario(s) where it won't work. Ian did the same type of work that I did on legacy systems. I'm sure he can do the same if he is familiar with the process being tested.

One final thing: Code reviews can help too. For the PRPnet server, I'd suggest having David and/or Rogue do a code-review on your code before beginning testing. Frequently that will catch more than testing can.


Gary[/quote]Yeah, you're right--it definitely could have benefited from more testing, and I'll be sure to test the PRPnet server thoroughly before setting it up. However, I do have to beg to differ regarding your begging to differ :smile: about this results file blooper being caught by testing: yes, we may have been able to catch it with testing, but it still would have overwritten some G4000 results nonetheless. :smile:

Anyway, long story short: in the future when we try to set up something new we'll test it more thoroughly. :smile:

Max :smile:

[quote=mdettweiler;162888]Well, that actually wouldn't be too big a deal. Remember, all (or at least almost all) of the results *are* there, and in the correct daily files. The only difference from normal is that they're a little out of order within their correct daily file--but that's no big deal since the results come in from the server out of order in the first place, and will have to be sorted anyway during processing/balancing. Even if there are any missing k/n pairs, they'll be caught quite quickly and easily during processing. :smile:[/quote]


OH! Clearly I confused myself. (Nothing new there!) What is missing are the daily results and I assumed that was the only place to get the server results. Duh...server ignorance. Of course they can be gotten directly from the server results file(s). Thanks for the explanation.


Gary

Max,

can you help out kar_bon here?
[url]http://www.mersenneforum.org/newreply.php?do=newreply&noquote=1&p=163106[/url]

Please let me know if there are any files that need to be re-sent to the stats db.

[QUOTE=AMDave;163115]Max,

can you help out kar_bon here?
[url]http://www.mersenneforum.org/newreply.php?do=newreply&noquote=1&p=163106[/url]

Please let me know if there are any files that need to be re-sent to the stats db.[/QUOTE]

i just did it. see there!

Port 2000 has now been dried and removed from the 1st post of this thread.

Not sure what's going on here, but Port 3000 is getting some weird log entries...
user=mdettweiler
[2009-02-22 10:31:19]
1167*2^468538-1 is not prime. Res64: D80357B4A66AA8F9 Time : 1079.0 sec.
[B]user=is prime![/B]
[2009-02-22 10:31:37]
1111*2^468539-1 is not prime. Res64: FB70B65AF0823FDA Time : 406.0 sec.
[B]user=is prime![/B]
[2009-02-22 10:31:50]
1173*2^468539-1 is not prime. Res64: 23D689C292263D8D Time : 406.0 sec.
[B]user=is prime![/B]
[2009-02-22 10:31:52]
1195*2^468539-1 is not prime. Res64: 64CCB477F93BB450 Time : 406.0 sec.
[B]user=is prime![/B]
[2009-02-22 10:31:55]
1233*2^468539-1 is not prime. Res64: C59D2E3D76083254 Time : 406.0 sec.
user=mdettweiler
[2009-02-22 10:34:48]
1221*2^468538-1 is not prime. Res64: F66FDDB862FD5766 Time : 1079.0 sec.

I made a quick script change to ignore this false positive when looking for "prime!" as indicator that a prime was found so they don't show up on the server status page.

I also took the liberty to change it to 1 day instead of 3 in anticipation of it drying up soon... it's almost out of work now.
Port [B]3000[/B] has 1753 remaining knpairs!

Does anyone know who the user "Bismarck" is? By looking at the pattern of the results and their timings, I believe the "is prime!" user is the same person. Here is the pattern that I noticed:

[code]
user=mdettweiler
[2009-02-22 10:24:01]
1365*2^468537-1 is not prime. Res64: 49CED42A1D7673D7 Time : 1080.0 sec.
user=mdettweiler
[2009-02-22 10:24:10]
1053*2^468538-1 is not prime. Res64: 4C8913CD4DBF4CF7 Time : 1082.0 sec.
user=Bismarck
[2009-02-22 10:24:52]
1195*2^460229-1 is not prime. Res64: B349FE3B1A166E40 Time : 107909.0 sec.
user=Bismarck
[2009-02-22 10:25:04]
1309*2^460229-1 is not prime. Res64: 2E2CFEAA0DDF9E5E Time : 107889.0 sec.
user=Bismarck
[2009-02-22 10:25:06]
1119*2^460229-1 is not prime. Res64: 75018450EEFA2A75 Time : 107924.0 sec.
user=Bismarck
[2009-02-22 10:25:09]
1225*2^460229-1 is not prime. Res64: 7B45F74768F58D94 Time : 107907.0 sec.
user=mdettweiler
[2009-02-22 10:27:40]
1113*2^468538-1 is not prime. Res64: 3657B5123158EEC7 Time : 1083.0 sec.
user=mdettweiler
[2009-02-22 10:27:43]
1121*2^468538-1 is not prime. Res64: 701D982CF36626C9 Time : 1079.0 sec.
user=Bismarck
[2009-02-22 10:28:12]
1335*2^460230-1 is not prime. Res64: 14E7E351AD6E97DD Time : 107907.0 sec.
user=Bismarck
[2009-02-22 10:28:25]
1119*2^460231-1 is not prime. Res64: 57626131318408A5 Time : 107889.0 sec.
user=Bismarck
[2009-02-22 10:28:28]
1293*2^460230-1 is not prime. Res64: D66A56CC99908594 Time : 107925.0 sec.
user=Bismarck
[2009-02-22 10:28:31]
1071*2^460231-1 is not prime. Res64: D130A523E123368F Time : 107906.0 sec.
user=mdettweiler
[2009-02-22 10:31:13]
1127*2^468538-1 is not prime. Res64: 7E35DB3815B2BC71 Time : 1080.0 sec.
user=mdettweiler
[2009-02-22 10:31:19]
1167*2^468538-1 is not prime. Res64: D80357B4A66AA8F9 Time : 1079.0 sec.
user=is prime!
[2009-02-22 10:31:37]
1111*2^468539-1 is not prime. Res64: FB70B65AF0823FDA Time : 406.0 sec.
user=is prime!
[2009-02-22 10:31:50]
1173*2^468539-1 is not prime. Res64: 23D689C292263D8D Time : 406.0 sec.
user=is prime!
[2009-02-22 10:31:52]
1195*2^468539-1 is not prime. Res64: 64CCB477F93BB450 Time : 406.0 sec.
user=is prime!
[2009-02-22 10:31:55]
1233*2^468539-1 is not prime. Res64: C59D2E3D76083254 Time : 406.0 sec.
user=mdettweiler
[2009-02-22 10:34:48]
1221*2^468538-1 is not prime. Res64: F66FDDB862FD5766 Time : 1079.0 sec.
user=mdettweiler
[2009-02-22 10:34:55]
1307*2^468538-1 is not prime. Res64: 0E04A6BEEBF0D243 Time : 1080.0 sec.
user=is prime!
[2009-02-22 10:35:02]
1369*2^468539-1 is not prime. Res64: 281B7B78A6192801 Time : 410.0 sec.
user=is prime!
[2009-02-22 10:35:15]
1025*2^468540-1 is not prime. Res64: 7CC78FCCADE81C3F Time : 410.0 sec.
user=is prime!
[2009-02-22 10:35:17]
1095*2^468540-1 is not prime. Res64: 823AC77A46476EF8 Time : 410.0 sec.
user=is prime!
[2009-02-22 10:35:20]
1127*2^468540-1 is not prime. Res64: A02973ED780AAE35 Time : 409.0 sec.
user=mdettweiler
[2009-02-22 10:38:25]
1365*2^468538-1 is not prime. Res64: 39F739FD2D371D6B Time : 1080.0 sec.
user=is prime!
[2009-02-22 10:38:27]
1199*2^468540-1 is not prime. Res64: 3080A732CB3965F3 Time : 410.0 sec.
user=mdettweiler
[2009-02-22 10:38:31]
1371*2^468538-1 is not prime. Res64: FB100CA8753B4226 Time : 1080.0 sec.
user=is prime!
[2009-02-22 10:38:39]
1323*2^468540-1 is not prime. Res64: 0CF35D0CDEF5C469 Time : 409.0 sec.
user=is prime!
[2009-02-22 10:38:42]
1337*2^468540-1 is not prime. Res64: 4F29054BD609FBC2 Time : 410.0 sec.
user=is prime!
[2009-02-22 10:38:45]
1027*2^468541-1 is not prime. Res64: B42DE629C308B9F0 Time : 410.0 sec.
user=is prime!
[2009-02-22 10:41:53]
1167*2^468541-1 is not prime. Res64: 390DD11C3B031441 Time : 411.0 sec.
user=mdettweiler
[2009-02-22 10:42:01]
1051*2^468539-1 is not prime. Res64: 88A175D3FDE869D2 Time : 1081.0 sec.
user=is prime!
[2009-02-22 10:42:03]
1195*2^468541-1 is not prime. Res64: 63D899C14D728086 Time : 409.0 sec.
user=mdettweiler
[2009-02-22 10:42:06]
1105*2^468539-1 is not prime. Res64: DCDFBA1A81A362B5 Time : 1076.0 sec.
user=is prime!
[2009-02-22 10:42:08]
1219*2^468541-1 is not prime. Res64: 5751DF9ED9282FE2 Time : 411.0 sec.
user=is prime!
[2009-02-22 10:42:11]
1221*2^468541-1 is not prime. Res64: 3E22984B5F585632 Time : 411.0 sec.
user=is prime!
[2009-02-22 10:45:18]
1291*2^468541-1 is not prime. Res64: B6AC8C163E486A6C Time : 411.0 sec.
user=is prime!
[2009-02-22 10:45:32]
1005*2^468542-1 is not prime. Res64: B204ABDC9E52ED88 Time : 413.0 sec.
user=is prime!
[2009-02-22 10:45:34]
[/code]


Notice the pattern of 2 results by Max followed by 4 results by Bismarck, the pattern of which repeated twice. Directly after that, there were 2 results by Max followed by 4 results by "is prime!", the pattern of which repeated twice. It then went to a slightly different pattern with the "is prime!" user in between Max's 2 results but that appears to only be because the "is prime!" cores are gaining on Max's cores at just slightly greater than a 2 to 1 ratio.

Barring some bug that just now came into the server results conversion process, I believe this is a sabatoge attempt of some kind. Whomever Bismarck is needs to cut it out! :mad: David, can you tell by the IP address where the "Bismarck" and "is prime!" connection is coming from and that it is indeed the same person?

I'm not sure how this will be scored in the stats but IMHO, unless it's a server error of some kind, the "is prime!" entries should not be scored at all. I'll leave that up to you server/stats guys.

BTW, nice work in supressing the entries from showing as prime in your listing! :smile:


Gary

[B]If that is the case...
Bismarck[/B] or [B]is prime![/B] has not picked up any work since I posted.
I assume because 'he/she/they' got their kicks/laughs and then were found out, they went away.
Didn't mean to crash their party... :grin:

No big deal, found another spot in my script to harden :smile:

Be interesting how the rest of the scripts/stats/database handle it... not a big issue, we'll script around the 'kiddies' :big grin:

A quick search for Boinc and Bismark show someone on Team China...
and it shows a Q6600 computer using Vista64...
[URL]http://boinc.bio.wzw.tum.de/boincsimap/show_user.php?userid=25765[/URL]

Don't know if it's the same person or not however... and to be fair, on another Boinc site, searching for Bismark shows the following

[code]
User Name Country Team
Bismark Ukraine Ukraine
Bismark Australia Australia
BISMARK Spain Spain
bismark International International
bismark Canada Canada
[/code]

Max is the only person coming in now, so will keep an eye out...

[QUOTE=IronBits;163609]Be interesting how the rest of the scripts/stats/database handle it... not a big issue, we'll script around the 'kiddies' :big grin:
[/QUOTE]
I have modified the teams table and admin pages
For the admins with access, I am adding some notes at the top of the admin page to explain why.

I've put my 3 cores on port 3000 until it's gone.

I'll have to go take a look at what AMDave has up his sleeve next ;)

GB4000 seems to be down again.