[ogr25] buffer vergroten voor ogr25

[Verwijderd]

Ik heb een klein probleem.
Ik kan de komende tijd niet echt veel meer online komen en dus vroeg ik me af als ik de buff-in.ogr kan vergroten van 24 blokjes naar pak een 150 tal.
Is dit mogelijk, en zo ja willen jullie me dan ook vertellen hoe ik dat moet doen?
tnx
[info]
ik heb de faq willen bekijken maar die lag plat, ...
[/info]

[Jeldert]

Gewoon in je dnetc.ini deze regel verandener:
fetch-workunit-threshold=xxx
en dan is xxx het aantal wat je wilt ophalen.

[MarkB]

150 is wel erg veel hoor of je hebt een hele snel proc of je wilt sparen maar dan nog is 150 erg veel.

[Verwijderd]

op proxy.dsmarty.com heeft een subteam wel meer gefetched

zo'n 200.000 dus ik verwacht een flinke flush de komende dagen

[Verwijderd]

Verwijderd schreef op 05 oktober 2002 @ 22:42:
op proxy.dsmarty.com heeft een subteam wel meer gefetched

zo'n 200.000 dus ik verwacht een flinke flush de komende dagen

Ik denk dat iemand over een paar maanden met een paar kilo verlopen paketten zit. Als je er van uitgaat dat er gemiddeld 100 Mnode in een pakket zit, dan heeft ie 20 Pnode... dat is 10% van de DPC totaalscore (of evenveel als de DPC toppers ieder gedaan hebben)

[Verwijderd]

met een hondert paketjes doe ik een 2 tal weken
k weet nie hoelang t gaat zijn da k nie echt veel online ga zijn, dus wil k ff zekerheid hebben dat mn koe blijft draaien
tnx all for the help

[Witlof]

Verwijderd schreef op 05 oktober 2002 @ 22:42:
op proxy.dsmarty.com heeft een subteam wel meer gefetched

zo'n 200.000 dus ik verwacht een flinke flush de komende dagen

Wie was dat:?

Ik kan me herinneren dat bij het overschakelen van RC5 naar OGR meer mensen dachten dat het aantal packets hetzelfde moest zijn maar dat was dus niet zo

Het verlopen van deze pakketjes valt toch trouwens ook wel mee of niet?

[ZeroVince]

Ze verlopen misschien wel, maar aangezien double-flushen geteld wordt kan je er vanuit gaan dat flushen van eventueel verlopen packets ook gewoon mogelijk is. Ik zou uberhaubt wel wat meer verduidelijking willen hebben over het hoe en wat van OGR-25, waarom we de tekening van de voortgang van OGR-25 op de Dnet site eruit ziet alsof OGR-25 al een jaar klaar had moeten zijn, hoe het zit met de OGR-25 core (klopt het mathematisch wel dat je met dezelfde core OGR-24 en OGR-25 kan doen), et cetera.

Will Stappel please stand up?

[FlipFlap]

Ik ben zelf met mijn proxy ook de mist in gegaan. Ik had een buffer van 10.000 bij RC5 (1,5 dag), nu had ik OGR ook op dezelfde manier ingesteld. Ik heb inmiddels de eerste 250 pakketjes erdoor, nog 9.750 te gaan met circa 50MNodes/s. Volgens mij gaat dat nog een week of 30 kosten

[Verwijderd]

Als FlipFlap wil kan ik hier met een extra proxy wel wat bij hem weg halen.
Ik verbruik met mijn sub teampje bijna een 1000 per week dus is die aantal niet zo'n probleem voor mij.

[Verwijderd]

Bij mij vlat het op mijn proxy nog mee. 1500 maar al mijn clients zijn bezig een buffer van 500 pakketjes weg te werken. En dat gaat lekker op een P1 225MHz. Maar ok op mijn XP gaat het wel redelijk. Maar binnen hoeveel tijd moeten die pakketjes weer terug zijn bij D.net vorrdat ze opnieuw uitgegeven worden?

[stappel_]

ZeroVince schreef op 06 oktober 2002 @ 13:44:
Ze verlopen misschien wel, maar aangezien double-flushen geteld wordt kan je er vanuit gaan dat flushen van eventueel verlopen packets ook gewoon mogelijk is. Ik zou uberhaubt wel wat meer verduidelijking willen hebben over het hoe en wat van OGR-25, waarom we de tekening van de voortgang van OGR-25 op de Dnet site eruit ziet alsof OGR-25 al een jaar klaar had moeten zijn, hoe het zit met de OGR-25 core (klopt het mathematisch wel dat je met dezelfde core OGR-24 en OGR-25 kan doen), et cetera.

Will Stappel please stand up?

OGR pakketjes heeft een houdbaarheidsdatum die gelijk is aan die van RC5. Echter zijn er zoveel pakketjes dat ik in de 700+ dagen dat ik nu mee doe, en 59000+ stubs heb gedaan, nog geen dubbele heb gehad. We zijn dus nog steeds met de eerste run van OGR-25 bezig.

Wil iedereen die heel veel stubs heeft gehaalt deze niet weggooien. OGR verlangt dat alle stubs twee keer doorgerekend zijn door twee verschillende email addressen. Al geven ze de gehele range aan stubs nog een keer uit, als je je stub afmaakt en opstuurt krijg je altijd je stats punten, ook al is hij verlopen en net daarvoor door iemand ingeleverd. Je krijgt altijd je credits! Inleveren dus

Over de voortgang (en dit is van horen zeggen van iemand die er dicht bij staat).
OGR is moeilijker dan ze dachten. Er zijn een aantal problemen.
- OGR24 is voor twee runs uitgegeven. alle resultaten zijn zo goed als binnen. Ze krijgen echter nog steeds stubs binnen van systemen die in het begin ogr geladen hebben, maar toen direct op RC5 gezet zijn. Tevens is de disk waarop de database stond stuk. Nu hebben ze netjes altijd een backup gemaakt dus er is niks verloren. echter is er tot nu toe niemand op gestaan die tijd genoeg heeft om die database te herstellen en daarna uit te zoeken welke stubs er nog missen. Het gaat om een sybase database van +- 6Gb. het is meer een tijdskwestie dus.

- OGR25 heeft andere problemen. Ze weten niet 100% of met de core van OGR24 ook de juiste resultaten voor OGR25 naar boven komen. Dat proberen ze nu te bewijzen en dat zit dus bijna alle tijd in.
Tevens zat er in de 8012 versie een bug die een deel van de resultaten ongeldig heeft gemaakt. Dat is gewoon hun fout. Ze willen echter de resultaten wel gebruiken als backup controle. Dus het is niet geheel voor niks dat stukje.

Nou het uitzoeken van de progessie/voortgang. Dat ligt moeilijk en voor een deel zijn wij (=eindgebruikers) er zelf schuldig aan. Ze moeten alle stubs anders opslaan in de database dan bij RC5. Bij RC5 hadden ze een bitmap waar elke bit een blockje was. Bij OGR kan dat niet. Ze moeten dus alle details opslaan in de database en dat levert records op die wel 60bytes beslaan. al die details moeten ze dus gebruiken bij het bepalen van de voortgang. En nu komt het schuld plaatje. Wij willen elke dag stats zien en zij durven dus de stats box niet zo zwaar te belasten met het uitzoek werk. Ze zijn bang om het stuk te maken. Er waren namelijk heel veel problemen met sybase op deze machine.

Nu ligt hun prioriteit bij (in een volgorde die ik de laatste dagen heb opgepikt bij hun, dus het is mijn volgorde en misschien ook die van hun)
a) een nieuwe client voor RC5-72 plus nieuwe proxy (welke trouwens op port 2072 komt te hangen, RC5-56 was 2056, RC5-64 was 2064, etc)
b) alle problemen, vragen, etc van de eindgebruikers afhandelen.
c) dan komt er een extra core voor ECM ( RSA factoring )
d) de wiskundigen proberen nu tevens te bewijzen dat de OGR-25 core nog steeds correcte output levert.
e) aanpakken overige problemen, zoals plotsellinge rechtzaken, etc
f) het bepalen of OGR al klaar is.

Dus OGR staat laag bij hun op de lijst. Maar OGR heeft wel waarde hoor. Niet stoppen dus.

[Mobster]

Bedankt stappel_ voor deze zeer uitvoerige uitleg!

Crunchen blijft dus het devies!

[AlvaK]

Hey Stappel, kun je ons niet toevallig wat vaker op de hoogte houden van zulke ontwikkelingen op D.net?

Ik vind het erg interessante info, aangezien ik maar wat graag weer RC5 ga doen ipv OGR.

[Mobster]

Zit ik daar een hele draad door te lezen. Zie ik al één na laatste een reactie van mezelf?! Da's ook raar. Check ik de datum, AHA!