[OGR-25] evaluatie van het project, heeft het zin?

[MarcyDarcy]

Dankzij onze cheatende Oostenrijkse vriend was ik vandaag eens de distributed.net site aan het doorlezen, hopende wat te kunnen vinden over het gecheat.

Helaas kwam ik daar niks van tegen maar ik kwam wel op de statistieken pagina van OGR-25 waar ze enkele grafiekjes hebben gemaakt betreffende het flushgedrag.

Daar staat ondermeer het volgende grafiekje


Rara wat klopt er niet aan?
Het project is op 1 augustus 2000 begonnen en rond 9 december 2000 was men al over de 70% van het totale project heen. Ik weet dat er nog een "second pass" verificatie bestaat, maar zeg nou zelf. Dit is toch wel heel vreemd

_{ook de "second pass" verificatie van OGR-24 is nog niet eens helemaal klaar terwijl die medio augustus 2000 is gestart waarbij het geleidelijk in de komende weken gedaan zou worden}

[Mobster]

Is deze grafiek gebaseerd op werkelijke waardes of is dit een wens van de organisatie. Ik was in de veronderstelling dat er bij het berekenen van een Optimal Golomb Ruler geen bepaalde 'keyspace' was die doorlopen moest worden!?

Hoe kunnen ze dan begrafiekeren dat we nu een al weer een maand of 5 over de 70% zijn?
* Mobster denkt dat er heel veel onduidelijkheden over dit project zijn _helaas

[Verwijderd]

Op maandag 13 mei 2002 20:33 schreef Mobster het volgende:

Hoe kunnen ze dan begrafiekeren dat we nu een al weer een maand of 5 over de 70% zijn?

Geen vijf maar 17 maanden.

Ik heb ooit gehoord dat 30% van wat dagelijks aan OGR binnenkomt, geproduceerd wordt door trojans etc?

/me vindt het sowieso gaar dat er zo snel gecheat kan worden

[stappel_]

Ik doe vanaf het begin al OGR, in het totaal nu 648 alleen al OGR-25, In totaal 5,8P. Alle logfile heb ik nog en tot op heden heb ik slechts 7 keer een dubbele sub gehad. Ja slechts 7 keer een stub die ik al eerder gedaan had. Moet je nagaan hoe groot die keyspace dan wel niet moet zijn. De kans dat ik een dubbele krijg is zeer klein (blijkt uit de praktijk) en dus moet de keyspace enorm groot zijn. Ik denk dat die 70% slechts een deel van de keyspace was die ze op dat moment gemaakt hadden.

[MarcyDarcy]

Da's wel een duidelijk verhaal stappel, zoals ik het dus lees hebben ze het over de uitgegeven data. Toegeven, beetje onduidelijk is het wel. Vooral als het het onderstaande eens leest.

Hieronder een quote uit de .plan van [e-mail]

:: 07-Dec-2001 15:17 (Friday) ::
Good news/bad news:

I have been working on a method to automate the process of determining
when an OGR stub is "completed." That is, when it has been done by two
separate sources who agree on the result. When this is finished, we will
be able to quickly determine which stubs still need to be done, and when
an OGR project can be called complete.

Unfortunately, due to some personal issues, my access to computing resources
will be extremely limited in the near future. As an aside, if you happen
to know of an opening for an HP-UX sysadmin who is willing to travel, drop
me a line. Australia or the US preferred.

Regrettably, I haven't made enough progress yet to be able to recycle
OGR-24 and OGR-25. Being able to recycle is one of our highest priorities,
not only so we can finish OGR-24 and -25, but so we can continue to 26...31.

Dus eigenlijk geven ze gewoon toe dat ze nu niet weten hoever ze zijn?

[stappel_]

Op dinsdag 14 mei 2002 02:21 schreef MarcyDarcy het volgende:
Dus eigenlijk geven ze gewoon toe dat ze nu niet weten hoever ze zijn?

Het is nog veel erger dan je denkt. Ze hebben een aantal problemen.
a) ze hebben geen idee over hoeveel stubs er in OGR-25 zitten. ze hebben ze gemaakt maar er geen copie van gemaakt. er is geen bitmap keyfile zoals bij RC5.
b) ze hebben dezelfde sourcecode gebruikt voor de stub generator en client, maar weten niet of dat wel wiskundig te bewijzen is.
c) er zijn heel veel dubbel flushes geweest (al dan niet cheaters).
d) alle logfiles worden dagelijks/wekelijks op cd gezet. om alle gegevens die ze nodig hebben voor OGR af te maken moeten ze waarschijnlijk de cd's gebruiken.

[MarcyDarcy]

Da's inderdaad erger dan ik dacht.
No offence maar OGR is dan toch niet zo nuttig als dat het lijkt. In zovere dat er al waardes zijn tot en met OGR-150 (zoniet meer).

D.net wilt dus de hele keyspace checken om te bevestigen dat er geen kleinere bestaat dan de waarden die reeds bekend zijn. Maar als d.net d.m.v. de punten die stappel heeft genoemd dit moeilijk zoniet onmogelijk kan aantonen dan is OGR toch helaas verspilde tijd?

Het zou imho heel wat helderheid verschaffen als d.net met een duidelijk verhaal naar buiten komt over het hoe en wat.

[gp500]

ZOU het niet 's wat zijn dat DPC een PUNTENLIJST maakt:

DPC is toch de grootste in ogr/rc5 dus dan heb je wel wat te melden of niet

1: .... etc.


DIT zou D.net heel veel goeds doen en DPC natuurlijk ook.

[Verwijderd]

Op dinsdag 14 mei 2002 12:43 schreef MarcyDarcy het volgende:
In zovere dat er al waardes zijn tot en met OGR-150 (zoniet meer).

Daar wil ik toch even een bedenking bij maken. Het is inderdaad zo dat zulke waardes gevonden zijn (en voor veel hogere waarden dan 150 hoor) en met een beetje pc kun je er vrij snel een pak vinden, want zo moeilijk is dat niet.

Alleen is het de bedoeling dat ie zo kort mogelijk is, en zoals je ook kunt zien in de tabel die je aangeeft : voor waarden > 23 is het nog niet bewezen dat de waarde die daar staat de kortst mogelijke is... vandaar dus de OGR projecten van d.net...