OGR en proxylog: waar staan die getallen voor?

[Pastinakel]

Twee regels uit de console-log van mijn d.net-proxy:

2001-01-14 00:39:57,rc564 r=26487/30000, d=65751/100000, 5.9 Mkeys/sec, tot=45182
2001-01-14 00:39:57,ogr r=29970/30000, d=8/50000, 2.8 Mnodes/sec, tot=6 stubs

Van RC5 weet ik dat de getallen 65751/100000 staan voor de buff-out en dat elk getal staan voor dat getal maal 2^28 keys. Met behulp van de aangegeven snelheid kan ik dan berekenen wanneer ik de 100000 ga halen. Ik weet niet of het precies klopt wat ik hier zeg maar de voorspellingen kloppen altijd heel redelijk .

Hoe zit dat met OGR? Voor hoeveel nodes staan die getallen? Ofwel: hoe kan ik (net als bij RC5) met deze getallen het moment berekenen dat de flush-drempel bereikt wordt?

[Verwijderd]

Op zondag 14 januari 2001 01:51 schreef Niep het volgende:
2001-01-14 00:39:57,ogr r=29970/30000, d=8/50000, 2.8 Mnodes/sec, tot=6 stubs

Hoe zit dat met OGR? Voor hoeveel nodes staan die getallen? Ofwel: hoe kan ik (net als bij RC5) met deze getallen het moment berekenen dat de flush-drempel bereikt wordt?

De getallen zijn precies hetzelfde als bij RC5. Bij RC5 is z'n getal een block, bij OGR is z'n getal een stub. Echter heeft een stub GEEN vaste grote. Dit kan ergens tussen de 5Gnodes en de 500Gnodes liggen.

Die 8 stubs in je out buffer kunnen dus 40Gnodes zijn, of in totaal 4Tnodes. Dat kan je op een proxy niet zien. Moet je in de log files kijken.

En mag ik even vragen waarom er 30 DUIZEND stubs in de inbuffer zitten. Je hebt er in de hele leven niet zoveel nodig. Shit dit is meer dan een keyproxy van d.net soms heeft.

Met 15Ghz aan machines heb je ongeveer 100 stubs per dag nodig. Dus of je hebt een heel groot machine park van 650Ghz of je hebt voor 750 dagen aan stubs liggen als je een 1Ghz machine hebt.

[Pastinakel]

Ach ja, die getallen heb ik ingevoerd voordat ik me uberhaupt met OGR ging bezighouden. Is inderdaad een stompzinnige hoeveelheid maar ik zou niet weten hoe ik ze nu weer kwijt zou moeten raken...Tegen de tijd dat mensen zich daadwerkelijk op OGR gaan storten, pas ik die getallen wel weer aan.

Dat stubs een variabele hoeveelheid nodes vertegenwoordigen, wist ik. Maar de proxy kan met deze getallen toch ook een snelheid in Mnodes/sec berekenen? Blijkbaar weet de proxy meer dan dattie in z'n console-log wegschrijft...

Een manier zou inderdaad zijn naar de OGR-logs te kijken, daar een snelheid uit te destileren en vervolgens een voorspelling uit te rekenen. Errrug omslachtig...

[[eNeRGy]]

ik heb 1 van de drukste OGR proxy's en ik heb maar 2500 stubs op voorraad.. ruim voldoende

[FReaKaNDeLL]

Op zondag 14 januari 2001 02:44 schreef [eNeRGy] het volgende:
ik heb 1 van de drukste OGR proxy's en ik heb maar 2500 stubs op voorraad.. ruim voldoende

k d8 op d.net gelezen te hebben dat OGR25 stubs binnen 2 wkn truggekeert moeten zijn, omdat je anders kans hebt dat ze opnieuw worden uitgedeeld, dus als k jou was zou ik er iets minder op voorraad hebbe (tenzij je wel heeeeeeeeeel druk bezocht bent )

[Pastinakel]

Jaja, ik heb toch al toegegeven dat het een stompzinnig aantal was? Ik heb het al teruggezet naar 80 en de buffer gooi ik nog wel weg...

Heeft iemand inmiddels een oplossing voor de oorspronkelijke vraag namelijk hoe je die getallen uit de OGR-regels in de console-log kan omzetten naar nodes?

[[eNeRGy]]

Op zondag 14 januari 2001 03:15 schreef oVeRLoaD het volgende:

[..]
k d8 op d.net gelezen te hebben dat OGR25 stubs binnen 2 wkn truggekeert moeten zijn, omdat je anders kans hebt dat ze opnieuw worden uitgedeeld, dus als k jou was zou ik er iets minder op voorraad hebbe (tenzij je wel heeeeeeeeeel druk bezocht bent )

Ehm, ik ben zo'n beetje de OGR Proxy van DPC.. dus maak je maar niet druk hoor

[[eNeRGy]]

Op zondag 14 januari 2001 03:25 schreef Niep het volgende:
Jaja, ik heb toch al toegegeven dat het een stompzinnig aantal was? Ik heb het al teruggezet naar 80 en de buffer gooi ik nog wel weg...

Heeft iemand inmiddels een oplossing voor de oorspronkelijke vraag namelijk hoe je die getallen uit de OGR-regels in de console-log kan omzetten naar nodes?

Ehm, gewoon het getal dat er staat even berekenen

Nou ok, ik geef even een voorbeeldje:

Ik doe 110 dagen mee, om mijn gemiddelde rate te berekenen moet ik het volgende doen:

code:

select sum(count) / (60 * 60 * 24 * 110) from OGR_log where email=28;

Daar komt dan uit: 955060.. dit is dus nodes/sec

Je ziet dat ik aan het aantal niks veranderd heb, want het is dus al in nodes

[[eNeRGy]]

oops

[Pastinakel]

OK bedankt voor de hulp & uitleg.

OGR is voor mij weer een stukje inzichtelijker geworden.

Achteraf snap ik nu ook waarom m'n perproxy er een week over heeft gedaan z'n OGR-inbuffers vol te krijgen .