Lucky 13 (M51 related)

[Madpoo]

Originally Posted by kriesel

...Haven't seen anything out of the ordinary yet. That's encouraging but not definitive...

If they all pass, it does not necessarily mean the existing codes are without flaw.
...

The programmers would be more definitive in their answers, but I'm pretty sure the bases are covered...

There are false positives, for sure, where a test has returned "is prime" even though it isn't. And we catch those.

Although we haven't seen any, there can be false negatives as well. And that's why we do double-checks and compare the 64-bit residue of that final iteration.

Barring something going terribly awry with the LLR itself, it's highly improbable for two false negatives to arrive at the same 64-bit residue. Maybe different ones, but surely not the same one. This happens often with a regular "is composite" where a triple or even more tests are needed because the first couple didn't match.

The tricky bit, which the programmers would weigh in on, is whether it's possible for some flaw in the LLR itself to "miss" a prime result, and do so in a repeatable way. Some odd quirk in either the implementation, the hardware, the chipset, etc. I think issues like that are tested for and can be caught (roundoff errors, etc). The different code bases go through a lot of testing. And there was that one time way back when that a bug in Prime95 was discovered and the tests from that version were re-done. Don't remember what version...long time ago.

EDIT: found it... it was version 17.

[ewmayer]

Originally Posted by kriesel

I hope it's either statistical fluctuation, or an actual pattern with mathematical justification TBD, not a consequence of similar effect undiscovered bugs lurking in the primality test codes. Some of the codes have ancestry in common. If there was an issue in common, present in a bit of "DNA in common", despite the best efforts of the authors and extreme care in using differing programs on differing hardware in multiple confirmations by multiple individuals, how could we know?

AFAIK the 3 distinct codes used to verify the latest find have no ancestry in common, except in a very general sense, i.e. they all use IBDWT/FFT. The bigger concern would be if George's code, which is responsible for the vast majority of GIMPS work, were somehow stealthily missing some M-primes with p == 3 (mod 4), i.e. the disparate independent verify codes never had a crack at those. But IMO those codes are doing enough DC work that if there were such a bug, it would have showed up long ago, by way of an unexpectedly high % of mismatches between 1st and 2nd tests.

Lastly, we've found far more M-primes than statistically expected - were we missing a bunch (or even a handful) of primes with p == 3 (mod 4), the actual prime count would be *really* out of whack vs the theory.

But I can see where you are coming from - it's alas an aspect of proof-by-computer that only a handful of people (via their written code) are in a position to check a given result. It's a far cry from the days when any kid could cut some squares and rectangles of proper size & shape and reassemble them so as to replicate Pythagoras' proof of the theorem which now bears his name.

[kriesel]

Originally Posted by Madpoo

The programmers would be more definitive in their answers, but I'm pretty sure the bases are covered...

There are false positives, for sure, where a test has returned "is prime" even though it isn't. And we catch those.

Although we haven't seen any, there can be false negatives as well. And that's why we do double-checks and compare the 64-bit residue of that final iteration.

Barring something going terribly awry with the LLR itself, it's highly improbable for two false negatives to arrive at the same 64-bit residue. Maybe different ones, but surely not the same one. This happens often with a regular "is composite" where a triple or even more tests are needed because the first couple didn't match.

The tricky bit, which the programmers would weigh in on, is whether it's possible for some flaw in the LLR itself to "miss" a prime result, and do so in a repeatable way. Some odd quirk in either the implementation, the hardware, the chipset, etc. I think issues like that are tested for and can be caught (roundoff errors, etc). The different code bases go through a lot of testing. And there was that one time way back when that a bug in Prime95 was discovered and the tests from that version were re-done. Don't remember what version...long time ago.

EDIT: found it... it was version 17.

Again, I appreciate the efforts made by the various authors and others to do what can be done to ensure reliability and accuracy as well as speed.
We thought we were doing all that could be done. Errors creep through. New approaches get identified, implemented, tested, and rolled out, such as the Jacobi test for LL, and adoption of PRP3 with Gerbicz check. Bugs occasionally get found after release, identified, disclosed, fixed, etc. We'll keep iterating, leaving no stone unturned.

My crude diagram for the ancestry of the various codes is attached at https://www.mersenneforum.org/showpo...04&postcount=5 (Corrections or additions are invited. My own independently developed code begun in the 1980s is not included, because its run time scaling is terrible. Trial factoring inefficiently, and LLtest via schoolboy multiplication with integer arrays in C, was as far as I got before I learned of the far more advanced much faster prime95 and collaborative systematic search operating through a mailing list and range assignments, and quit a solo effort on my own slow code and a handful of systems.)
It's my understanding, from reviewing and summarizing the various authors' descriptions, to produce that parentage diagram, that gpuowl, Gpulucas, and Mlucas are unrelated to the rest and each other, and prime95 is "loosely" derived from lucdwt. Lucdwt and MacLucasUNIX are identified as the common ancestors of cllucas, glucas, and CUDALucas. So confirming new finds by prime95, CUDALucas, Mlucas, and gpuowl is close to as unrelated as possible. Substituting gpulucas for CUDALucas, or adding gpulucas, might help slightly. (I haven't attempted thoroughly reviewing and comparing the source codes for degree of commonality. Haven't run gpulucas.)

The programmers would be more definitive in their answers, but I'm pretty sure the bases are covered...

Different offsets help some types of error. They may not be as effective in catching some systematic errors.

https://www.mail-archive.com/mersenn.../msg07476.html shows LL test error rates used to be higher than they are now averaging.

And there was that one time way back when that a bug in Prime95 was discovered and the tests from that version were re-done. Don't remember what version...long time ago.

EDIT: found it... it was version 17.

Bug announced on April 1 1999 and alas no joke. The previous day, March 31 1999, the EFF primes prizes were announced and being discussed on the mailing list. I'm more familiar than the average GIMPS participant with the QA effort beginning with the V17 bug and continuing on succeeding versions. From my local GIMPS mailing list participant email folder, passed on from one aging PC to the next:

Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
From ???@??? Sun Apr 11 11:42:23 1999
Return-Path: mersenne-invalid-reply-address@base.com
Received: from [144.92.9.42] by mail6.doit.wisc.edu
id WAA197884 (8.9.1/50); Fri, 9 Apr 1999 22:05:18 -0500
Received: from [209.233.24.120] by mail3.doit.wisc.edu
id WAA79632 (8.9.1/50); Fri, 9 Apr 1999 22:05:17 -0500
Received: (from majordomo@localhost)
by acid.base.com (8.9.3/8.9.3) id UAA11308
for mersenne-outgoing; Fri, 9 Apr 1999 20:02:06 -0700
Received: from magicnet.magicnet.net (magicnet.magicnet.net [204.96.116.9])
by acid.base.com (8.9.3/8.9.3) with ESMTP id UAA11305
for <mersenne@base.com>; Fri, 9 Apr 1999 20:02:04 -0700
Received: from DUAL400 (pm56-41.magicnet.net [208.6.201.97])
by magicnet.magicnet.net (8.8.6/8.8.8) with SMTP id XAA13712;
Fri, 9 Apr 1999 23:01:27 -0400 (EDT)
Message-Id: <3.0.5.32.19990409225750.00a56b20@dual400>
X-Sender: woltman@dual400
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Fri, 09 Apr 1999 22:57:50 -0400
To: Kriesel <(obsolete email address redacted)>,
Mersenne-list <mersenne@base.com>
From: George Woltman <woltman@alum.mit.edu>
Subject: Re: Mersenne: preventive measures
In-Reply-To: <3.0.32.19990403165624.0066cad0@facstaff.wisc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: mersenne-invalid-reply-address@base.com
Precedence: bulk

Hi all,

At 04:56 PM 4/3/99 -0600, Kriesel wrote:
>Since we now have a wealth of exponents to be tested or retested,
>requiring a total expenditure of billions of cpu-hours, perhaps
>we could introduce a little more formalism into the program-validation
>process. I volunteered months ago to test 1 or 2 exponents in each
runlength.
>Several have completed. Brian Beesley offered to double-check my
>results, and George has assigned them to Brian as double-checks.
>The nature of the just-discovered bug suggests that more test cases are
>in order.
>
>I propose the following be considered, for each future version released
>(and for the versions in heavy use currently):
>1. Code review by qualified volunteers.

A good idea for the C code, I doubt the assembly code qualifies.

>2. George and such other people as are qualified, determine which exponents
>make good test cases, based on a review of the code.

My input:

1) Those near the end of each range should be checked for
excessive convolution error. In fact, it would be nice it the QA
suite recommended the crossover points for the FFTs.

2) Exponents that are close to a multiple of the FFT length.
Crandall's "magic numbers" are very sensitive here.

>3. Volunteers with some cpu-power run LLtests and double-checks on the test
>cases selected.

As pointed out earlier, a few hundred iterations *should* suffice.
But Ken may decide a few more lengthy checks are required.

And as v17 pointed out, the shifting code needs to be checked
in the above tests.

>Since this project is in a sense George's baby, I feel he has the right
>to ok or nix this. If he says ok, I volunteer to be the contact point
>for volunteers to enlist as either code reviewers, testers, or both.
>After a week or two I will summarize to George.

OK, I never turn down a volunteer! I hereby appint Ken the coordinator
of the official GIMPS QA project.

First order of business is a plan of action - formulating the QA test suite.
How much CPU power are we going to require? Would enough tests to keep
5 volunteers busy for 24 hours suffice? Will the ports run shorter suites?

This QA suite will not be my baby, so don't be shy folks in chiming
in with ideas or offering to help Ken out. I'll put in whatever hooks
you folks need.


Now for some good news-------->

Prime95 v19 is under way. It involves rewriting ALL the FFT code!
So this QA project is quite timely.

What's new in v19? It should support FFT lengths from 32 up to 4M
with PFA lengths (3*power-of-two and 5*power-of-two) supported.
It has a slightly modified memory model that should be more efficient in
using the Pentium's TLB (translation look-aside buffers) cache for
larger FFT sizes. A little less memory traffic for some FFT lengths.
P-1 factoring support.

What isn't coded yet: Save files for P-1 and ECM factoring. A O(n log n)
GCD to make P-1 and ECM factoring on larger exponents feasible. A more
memory efficient but slower stage 2 for large exponents. Several FFT sizes
are not coded yet. Obviously, don't expect v19 anytime soon!

Here's a teaser: A 128K FFT is 1.5% faster, a 512K FFT is 5% faster.

Oh, and by the way, the re-engineered assembly code will be easily usable
in other large integer programs.

Best regards,
George

Originally Posted by ewmayer

AFAIK the 3 distinct codes used to verify the latest find have no ancestry in common, except in a very general sense, i.e. they all use IBDWT/FFT. The bigger concern would be if George's code, which is responsible for the vast majority of GIMPS work, were somehow stealthily missing some M-primes with p == 3 (mod 4), i.e. the disparate independent verify codes never had a crack at those. But IMO those codes are doing enough DC work that if there were such a bug, it would have showed up long ago, by way of an unexpectedly high % of mismatches between 1st and 2nd tests.

Lastly, we've found far more M-primes than statistically expected - were we missing a bunch (or even a handful) of primes with p == 3 (mod 4), the actual prime count would be *really* out of whack vs the theory.

But I can see where you are coming from - it's alas an aspect of proof-by-computer that only a handful of people (via their written code) are in a position to check a given result. It's a far cry from the days when any kid could cut some squares and rectangles of proper size & shape and reassemble them so as to replicate Pythagoras' proof of the theorem which now bears his name.

There is an LL primality test error rate of ~2%/exponent, and similarly on second checks. We iterate until there's a match.
We know from some gpu runs that some bugs/misconfigurations will preferentially stabilize on a specific wrong res64 result, not a random wrong one. One such value is a false positive, as Madpoo has long known and dealt with. So that's an existence proof of nonrandom result from error, that occurs despite nonzero offset. A patch to detect and halt such runs was added. (See item 4 in the CUDALucas bug and wish list attached at https://www.mersenneforum.org/showpo...24&postcount=3)

One promising take on the recent history of discoveries is we've been the beneficiaries of catching up to the expected number. See George's post earlier. https://www.mersenneforum.org/showpo...&postcount=204

[bhelmes]

A peaceful and pleasant evening,

I am lucky about the new mersenne prime, very just in time for Christmas
and congratulation for all, who have made possible this success.


Greetings

Bernhard

[Madpoo]

Originally Posted by kriesel

...I'm more familiar than the average GIMPS participant with the QA effort beginning with the V17 bug and continuing on succeeding versions...

It was funny to see my own replies in the linked thread. It's always weird to me to re-read things I wrote years ago (in this case, 19 years ago).

...One such value is a false positive, as Madpoo has long known and dealt with. So that's an existence proof of nonrandom result from error, that occurs despite nonzero offset...

At least as far as I'm aware, the false and repeatable residues are actually to be expected, because of the way the LL itself works. You may wind up with a zero or -2 for some odd reason or another, and from that point on there's really no help for it. At least those are easy to spot.

We had another false positive come in from a cudalucas 2.05.1 version just a couple days ago (in a DC range). When we see those, once we see the version is the "bad" one we just ignore it. Far too common, sadly, to spark our interest. That version is the version that cried wolf and now I simply refuse to believe it anymore.

Truly, anyone still using that version of cudalucas had better update because if you ever did find a prime, nobody would believe you until it was double-checked on a non-buggy version. LOL

As far as getting some repeatable, but false, final residue that looked more believable, not "2" or "0", I'm drawing a blank on how that could happen. The only thing that comes to mind is a repeatable flaw in the add or mul that consistently gives the wrong result... something like the old Pentium fdiv bug, on the hardware side, or somewhere in software. The software side with it's selection of the best FFT size is always doing checks to make sure there aren't any roundoffs, and other issues that are actually hardware related (overclocking that leads to memory issues, as an example) are random in nature.

I don't think I'm saying anything too shocking when I say that *all* incorrect residues that show up are the result of hardware... memory in particular, although knowing if it's CPU or memory is a little bit of a guess. Even if it's CPU related, it's probably because of an overheated/overclocked CPU giving bad L2/L3 cached data.

In my experience, systems with ECC memory have NEVER had issues. This goes for the systems I used to check with as well as the accounts that use AWS instances, or other people that I happen to know use servers with ECC. We're talking zero errors, and that's pretty impressive.

In fact I think it'd be pretty cool if George added something to the code so that when the system stats are reported (things like CPU type/speed) it also includes whether ECC memory is installed. I'm not sure if that's something that's generally available via a standard WMI query or not, but maybe... so it would be model agnostic to get such a datapoint.

It's also interesting to see how a particular machine may "degrade" over time. They start out with great results, no problems, but as that same machine keeps working over the years, it gets a little flaky and starts spitting out bad residues. I imagine the owner of that system notices other problems because in general those systems don't stick around too long. They probably start blue-screening here and there, and I'm guessing it's when memory goes bad.

Anyway, point being, bad residues occur, and as far as I can remember from looking at error rates from particular code or versions of software, nothing really stood out. Getting a repeatable error is possible, I suppose, although my gut tells me it's highly unlikely aside from a flaw in the CPU itself like that fdiv one I mentioned.

[chalsall]

Originally Posted by Madpoo

It's also interesting to see how a particular machine may "degrade" over time. They start out with great results, no problems, but as that same machine keeps working over the years, it gets a little flaky and starts spitting out bad residues.

And, if I may, this is why some of us run only DCs.

When the kit can't do a DC reliably, it's time to put the "evil eye" on it. And then move mission critical services onto another server...

I can't even begin to guess how much time and money running GIMPS has saved me over the last ~20 years....

[kriesel]

Originally Posted by Madpoo

At least as far as I'm aware, the false and repeatable residues are actually to be expected, because of the way the LL itself works. You may wind up with a zero or -2 for some odd reason or another, and from that point on there's really no help for it. At least those are easy to spot.
...
As far as getting some repeatable, but false, final residue that looked more believable, not "2" or "0", I'm drawing a blank on how that could happen. The only thing that comes to mind is a repeatable flaw in the add or mul that consistently gives the wrong result... something like the old Pentium fdiv bug, on the hardware side, or somewhere in software. The software side with it's selection of the best FFT size is always doing checks to make sure there aren't any roundoffs, and other issues that are actually hardware related (overclocking that leads to memory issues, as an example) are random in nature.

I don't think I'm saying anything too shocking when I say that *all* incorrect residues that show up are the result of hardware... memory in particular, although knowing if it's CPU or memory is a little bit of a guess. Even if it's CPU related, it's probably because of an overheated/overclocked CPU giving bad L2/L3 cached data.
...
Anyway, point being, bad residues occur, and as far as I can remember from looking at error rates from particular code or versions of software, nothing really stood out. Getting a repeatable error is possible, I suppose, although my gut tells me it's highly unlikely aside from a flaw in the CPU itself like that fdiv one I mentioned.

Which bad residues show up is a function of application also. Cllucas is supposed to also be doing LL. Note it has a unique bad residue. CUDAPm1 is doing different math, and has a different set of bad residues. Zero is in common among several.
As far as all erroneous residues being due to hardware, that seems from my testing clearly not the whole picture. There are ways to generate bad residues at will on hardware that is very solid otherwise, by using a particular CUDA level or threads setting in CUDALucas, exceeding the capabilities of a gpu in CUDAPm1 so stage 2 residues repeat every output, etc.

# (in perl form) application-specific bad residues, indicative of some problem causing the calculation to go wrong
# for applications other than gpuowl their detection means the run should be halted and the problem fixed before continuing
# for gpuowl, the Gerbicz check will cause a lot of iterations recalculation requiring more time. Fixing the issue is recommended
%badresidues=(
'cllucas', '0x0000000000000002, 0xffffffff80000000',
'cudalucas', '0x0000000000000000, 0x0000000000000002, 0xfffffffffffffffd',
'cudapm1', '0x0000000000000000, 0x0000000000000001, 0xfff7fffbfffdfffe, 0xfff7fffbfffdffff, 0xfff7fffbfffffffe, 0xfff7fffbffffffff, '.
'0xfff7fffffffdfffe, 0xfff7fffffffdffff, 0xfff7fffffffffffe, 0xfff7ffffffffffff, 0xfffffffbfffdfffe, 0xfffffffbfffdffff, '.
'0xfffffffbfffffffe, 0xfffffffbffffffff, 0xfffffffffffdfffe, 0xfffffffffffdffff, 0xfffffffffffffffe, 0xffffffffffffffff',
'gpuowl', '0x0000000000000000',
'mfaktc', '',
'mfakto', ''
); #fff* added to cudapm1 list 7/19/18
# note, since second to last LL iteration's full residue can be +-2^[(p+1)/2], for a Mersenne prime,
# and, above M127, that looks like in a res64, '0x0000000000000000, 0xffffffffffffffff', special handling may be required
# for iteration p-3 for cllucas and cudalucas; add checks for below to cllucas and cudalucas checking code as (ok) exceptions to bad residues
$llpm3okresidues='0x0000000000000000, 0xffffffffffffffff';
# see http://www.mersenneforum.org/showthread.php?t=5862
# see also http://www.hoegge.dk/mersenne/resultspenultimate.txt
# http://www.hoegge.dk/mersenne/penultimate.txt

[science_man_88]

Originally Posted by Madpoo

At least as far as I'm aware, the false and repeatable residues are actually to be expected, because of the way the LL itself works. You may wind up with a zero or -2 for some odd reason or another, and from that point on there's really no help for it. At least those are easy to spot.

-1,2 and 1 are all possible errors as well.

[chalsall]

Originally Posted by science_man_88

-1,2 and 1 are all possible errors as well.

Sure. But how often do they occur?

Work the empirical....

[Madpoo]

Originally Posted by chalsall

Sure. But how often do they occur?

Work the empirical....

Here's a quick count of "funny" residues that have a lot of zeroes. Note there are WAY more with a residue of zero than are genuinely prime. There are a few others that have a somewhat suspicious amount of leading zeroes, but that may actually be the case. I mean, technically, since these are only partial residues, we could find one where the last 64-bits really are zero, by chance, but the rest of the residue is non-zero. That could actually be the case here and there because I have seen some funny results (same user who submitted a lot of false positives) where it said "xxx is composite" but the partial residue was all zero... that machine of his definitely had an issue though.

Which, by the way, is why double-checks should *always and only* be done by a different user. If they have a flaky system that can generate repeatable, but wrong, results, then we need *independent* double-checks to catch those things. And which is why, even though I have limited capacity now, I still hunt those down and do an independent check of my own.

Anyway, here's that list:

Residue              	Count
0000000000000000	311
0000000000000002	 14
0000000000000003	  1
0000000000000004	  1
000000000000006C	  1
0000000000000269	  1

[GP2]

Originally Posted by Madpoo

Anyway, here's that list:

Residue              	Count
0000000000000000	311
0000000000000002	 14
0000000000000003	  1
0000000000000004	  1
000000000000006C	  1
0000000000000269	  1

If you recall, the "269" result and 6C result were because of a temporary bug that zeroed out a random number of higher-order bits whenever the shift count was very high, namely within 64 of the exponent value itself. Obviously it was more likely to strike when the exponent was a small one, although the "269" was for one in the 37M range.

You fell victim to it yourself and reported it and George replied later in the same thread and fixed it.

These results (and others with fewer leading zeros) were retroactively accorded "good" status.

The 0000000000000003 result should also be changed from bad to good, since it's clearly a victim of the same thing (shift count was 162887 for exponent 162889).

The 0000000000000004 result, on the other hand, had a shift count of 0, so it was a genuine bad result of some kind.

PS,
I don't know if it's possible to attach some kind of comment field to a database record, to explain for posterity why the status is set to good despite having a non-matching result.

Below is the list of 64-bit residues marked good despite not being matching values. As I mentioned, Eivind Triel's result for 162889 should be added to it. The Myrmans I think had a bug in their residue-printing code, not sure about the others.

This doesn't include all the residues of other-than-64 bits from Slowinski and others from the pre-GIMPS era, which are also marked good.

8291,MadPoo,Manual testing,0000000013773232,,2015-04-11 05:58
12281,MadPoo,Manual testing,00001808E5C18969,,2015-04-11 05:57
731767,MadPoo,Manual testing,00000001F7189369,,2016-06-01 02:40
801883,MadPoo,Manual testing,00000001C201CCBD,,2015-04-11 15:52
1048507,Ernst W. Mayer,,B746F5680BFB3B27,,
1373483,Alex and Nick Myrman,,64F5D369DBA07793,,
1373501,Alex and Nick Myrman,,ABF49AB2AF916CDF,,
1373531,Alex and Nick Myrman,,AF8EF844F9474831,,
1373683,Alex and Nick Myrman,,30BFB9C3AEFC441F,,
1397983,Dwayne Towell,,F427ECDEE6EC189D,,
1397989,Dwayne Towell,,5A05B3487791000E,,
1398017,Dwayne Towell,,49A8806CB134DB28,,
1398049,Dwayne Towell,,3F8A270790967635,,
1398079,Dwayne Towell,,0BA8DA1E02FB903A,,
1398083,Dwayne Towell,,91A8568BCC0F0D00,,
1398427,Dwayne Towell,,F565D2176BFC2F4C,,
1398451,Dwayne Towell,,4803B9D97D901714,,
1398473,Dwayne Towell,,D2E7AD3ABBAA2148,,
1560953,Alex and Nick Myrman,,C3540B0D6FBB4034,,
1563277,Alex and Nick Myrman,,2C2F1357AA6986E7,,
1586707,Alex and Nick Myrman,,63ADFEF11B443BB2,,
1611131,Alex and Nick Myrman,,3C781C2CCDD1EF08,,
1653739,Alex and Nick Myrman,,D58C0B0E00C9B49E,,
1666387,Alex and Nick Myrman,,D8777EE4DA90A7F8,,
1666397,Alex and Nick Myrman,,091E42E39EFA24A9,,
1666409,Alex and Nick Myrman,,3AB476FA9FB0362A,,
1709377,whanlon,,353F2707EB55CB86,,
1798127,Alex and Nick Myrman,,71DAB0C3B7949AA0,,
1798409,Alex and Nick Myrman,,37E913D0172C6EF9,,
1874527,Alex and Nick Myrman,,94D1F78019D07BB8,,
1874797,Alex and Nick Myrman,,47DF9C1D4DAAF8B4,,
1874953,Alex and Nick Myrman,,CD1BFC19E87C597D,,
1907593,Alex and Nick Myrman,,1C2D318920D7D67D,,
2070071,Rob Hooft,,F8E2468605C42010,,
2070083,Rob Hooft,,8B2E7F39A8A4A724,,
2401579,Rob Hooft,,6D9ACDBF5B2E816D,,
2403971,Alex and Nick Myrman,,A53C50800A4494AE,,
2414081,Rob Hooft,,4D51566403FBF53E,,
2414099,Rob Hooft,,8370E0C747FC7D96,,
2414129,Rob Hooft,,B96148394C745EF6,,
2528969,Alex and Nick Myrman,,1C6CB11AB95BDF35,,
2816873,Alessandro Castagnini,,71E1061E98A2F864,,
2816927,Alessandro Castagnini,,6F69C92D75F22C25,,
2816941,Alessandro Castagnini,,3F6F56D3C63134DB,,
2816963,Alessandro Castagnini,,507DA633D4529624,,
3739199,Brian J. Beesley,alfalfa,12EF2F0EC9B15ADE,,
4059563,Phil Forrest,,754EA2C4ECF29DA6,,
4163539,whanlon,,DFE9112E5A56E23C,,
5643571,David Willmore,wopr,EFE193C46F4AC00D,,
5896207,David Willmore,wopr,2358E6E47DABA27F,,
37830997,Andrew Daniels,AHDHome,0000000000000269,,2008-02-03 00:00