[OGR] Fase 1 afgerond

[Verwijderd]

Van zowel OGR-24 als OGR-25 is Fase 1 afgerond.

Er is uit alle macht geprobeerd de volgende fase klaar te krijgen voor Fase 1 was afgerond, en dat is nog net gelukt.
Helaas betekent dit wel dat er een minimale overstaptijd is:

OGR-P1 stubs worden NIET meer meegeteld als ze na vandaag 0:00 UTC ingeleverd worden!

Iedereen die OGR wil doen zal met spoed moeten overstappen, omdat het technisch niet mogelijk is om zowel punten van OGR-P1 als OGR-P2 in de stats te verwerken. De tot vandaag ingeleverde P2 stubs zullen éénmalig handmatig worden bijgewerkt in de stats. Ik hoop dat jullie er begrip voor hebben dat dat geen optie is meermalen te doen voor de hoeveelheden als bij OGR-P1.
Ik bied vanuit mijn Distributed.net positie excuses aan dat het niet anders is, ik kan het begrijpen dat dit niet de meest handige manier van overstappen is.
Van de andere kant: OGR-P1 heeft 100% bereikt, en op=op.

Hieronder directe links naar clients en proxies voor de meest gebruikte operating systems.

Clients en Proxies

Win32
Proxy 341
Client 490

Mac OSX / Darwin
Proxy 341
Client 490

OS/2
Proxy 341
Client 490

Linux
Proxy 341a
Client 490 (x86/ELF/ulibc)

Overige clients en proxies:
http://www1.distributed.net//download/prerelease.php

[ Voor 5% gewijzigd door Verwijderd op 11-05-2004 19:16 ]

[TGEN]

proxyper-linux-x86-uclibc-341 werkt perfect onder OpenBSD en NetBSD (onder emulatie natuurlijk).

[[eNeRGy]]

TGEN schreef op 11 mei 2004 @ 19:21:
proxyper-linux-x86-uclibc-341 werkt perfect onder OpenBSD en NetBSD (onder emulatie natuurlijk).

grappig, zet maar eens een niet te resolven dns als keyserver erin -> crash

daarom is vanmiddag 341a uitgekomen

[TGEN]

[eNeRGy] schreef op 11 mei 2004 @ 19:37:
[...]

grappig, zet maar eens een niet te resolven dns als keyserver erin -> crash

daarom is vanmiddag 341a uitgekomen

Mja, daar doe ik niet aan he... ik ga niet een beetje testen of ie PIETJEHENKEI.HAHAHAHA als upstream keyserver accepteert... hmm hmm .

[Robinski]

wat wel jammer is, is dat als je in je ini ogr als contestclosed=1 zet
en hij gaat buffers update dit weer terug gezet wordt op 0 (dus contestopen)

[Verwijderd]

Klopt, die setting wordt via de servers verder verspreid.
Straks wordt OGR gedisabled op de keyserver, en zal dat langzaam overgaan naar alle proxies...

TGEN schreef op 11 mei 2004 @ 19:49:
[...]


Mja, daar doe ik niet aan he... ik ga niet een beetje testen of ie PIETJEHENKEI.HAHAHAHA als upstream keyserver accepteert... hmm hmm .

mja, maar als je i.net verbinding er een keer om één of andere reden eventjes uitligt kapte je proxy ermee... Ook als je de settings goed had.

[ Voor 58% gewijzigd door Verwijderd op 11-05-2004 20:11 ]

[Robinski]

Verwijderd schreef op 11 mei 2004 @ 20:09:
Klopt, die setting wordt via de servers verder verspreid.
Straks wordt OGR gedisabled op de keyserver, en zal dat langzaam overgaan naar alle proxies...

ik had het dus over mijn PersonalProxy
wel jammer dat dat dus niet anders kan. was wel handig geweest...
eenmaal op closed worden al me clients omgezet van OGR --> OGRp2

[Verwijderd]

Ik had het dus ook over jouw Personal Proxy server

Je kan misschien de proxy's .ini file op read-only zetten, maar ik zou niet weten of dat neveneffecten heeft.

Voor je clients kan je gewoon de project prioriteit aanpassen...

[misc]
project-priority=OGRP2,OGR,RC5-72

[ Voor 26% gewijzigd door Verwijderd op 11-05-2004 20:55 ]

[Wortelsoep]

Verwijderd schreef op 11 mei 2004 @ 19:11:
De tot vandaag ingeleverde P2 stubs zullen éénmalig handmatig worden bijgewerkt in de stats. Ik hoop dat jullie er begrip voor hebben dat dat geen optie is meermalen te doen voor de hoeveelheden als bij OGR-P1.

Wat bedoel je hier precies mee? Dat er geen dagelijkse stats komen voor P2?

PANIIIICCCCC!!!

[Robinski]

Verwijderd schreef op 11 mei 2004 @ 20:54:
Ik had het dus ook over jouw Personal Proxy server

Je kan misschien de proxy's .ini file op read-only zetten, maar ik zou niet weten of dat neveneffecten heeft.

Voor je clients kan je gewoon de project prioriteit aanpassen...

[misc]
project-priority=OGRP2,OGR,RC5-72

tja, ik kan niet altijd bij alle clients, (vrienden, familie)
ik had bij een groot deel de exes al wel geupdate en de prioritiet op OGR, OGR-P2, RC5-72 staan.

dan maar wachten totdat ze bij Distributed.net aanpassen / sluiten

[Verwijderd]

jaja, een beetje bugs gaan lopen openen @ d.net zodat ik er daar nóg een keer naar kan gaan kijken

In ieder geval staat daar een oplossing voor je klaar

[Robinski]

Verwijderd schreef op 11 mei 2004 @ 21:30:
jaja, een beetje bugs gaan lopen openen @ d.net zodat ik er daar nóg een keer naar kan gaan kijken

In ieder geval staat daar een oplossing voor je klaar

tja moet toch wat met me leven

[TGEN]

Robinski schreef op 11 mei 2004 @ 21:39:
[...]


tja moet toch wat met me leven

Je ppstats-'fix' is b0rked.

[[eNeRGy]]

*klop* *klop* *timmer* *timmer* *zaag* *zaag*

http://energy.keyserver.org/pgppstats/

zo klaar

[ Voor 15% gewijzigd door [eNeRGy] op 11-05-2004 22:12 ]

[Robinski]

TGEN schreef op 11 mei 2004 @ 22:10:
[...]


Je ppstats-'fix' is b0rked.

de wat?

[stappel_]

Verwijderd schreef op 11 mei 2004 @ 20:54:
Ik had het dus ook over jouw Personal Proxy server

Je kan misschien de proxy's .ini file op read-only zetten, maar ik zou niet weten of dat neveneffecten heeft.

Voor je clients kan je gewoon de project prioriteit aanpassen...

[misc]
project-priority=OGRP2,OGR,RC5-72

hahahah

moet ik Floppus nog gaan uitleggen hoe een d.net proxy werkt.
je moet de contestclosed op -1 zetten. dan kijk hij nooit meer naar de upstream proxy voor de contestclosed waarde voor dat project. een lokale overrule om te disabelen.

en het is OGR-P2 en niet OGRP2.

[misc]
project-priority=OGR-P2,OGR,RC5-72

[Witlof]

En om het lastig te maken is het bij in de ini-file van de client in de kopjes voor de fetch-instellingen opeens geen - maar een _ dus:

[OGR_P2]

En bij de proxy's weer aan elkaar zonder iets ertussen dus:

[OGRP2]

Wel lastig allemaal hoor Bij RC5-72 was het allemaal hetzelfde wat toch wat beter is.

Oh, en Stappel, komt er nog een extra OGR-P2-Statssysteem uit

[ Voor 31% gewijzigd door Witlof op 11-05-2004 22:30 ]

[Verwijderd]

stappel_ schreef op 11 mei 2004 @ 22:25:
[...]
hahahah

moet ik Floppus nog gaan uitleggen hoe een d.net proxy werkt.
je moet de contestclosed op -1 zetten. dan kijk hij nooit meer naar de upstream proxy voor de contestclosed waarde voor dat project. een lokale overrule om te disabelen.

en het is OGR-P2 en niet OGRP2.

[misc]
project-priority=OGR-P2,OGR,RC5-72

Klopt Die info had mij inmiddels ook al bereikt... Houdt er wel even rekening mee dat de proxy dan niet alleen meer geen werk meer uitdeelt, maar ook de clients die connecten opdracht geeft de buffers van dat project te trashen.

Normaal is dat om te zorgen dat het netwerk niet belast wordt met aanvragen van clients over projecten die niet meer lopen, maar ik denk dat je mensen wel pissig krijgt als je hun buffers trashed als ze een keer je proxy gebruiken
Gewoon geen buffers voor het betreffende project op je proxy hebben vind ik wat veiliger.

hmmm... wb de OGRP2 / OGR-P2 is het niet helemaal handig dat dat bij client en proxy dan afwijkend is

[ Voor 5% gewijzigd door Verwijderd op 11-05-2004 22:55 ]

[Robinski]

Verwijderd schreef op 11 mei 2004 @ 22:53:
[...]


Klopt Die info had mij inmiddels ook al bereikt... Houdt er wel even rekening mee dat de proxy dan niet alleen meer geen werk meer uitdeelt, maar ook de clients die connecten opdracht geeft de buffers van dat project te trashen.

Normaal is dat om te zorgen dat het netwerk niet belast wordt met aanvragen van clients over projecten die niet meer lopen, maar ik denk dat je mensen wel pissig krijgt als je hun buffers trashed als ze een keer je proxy gebruiken
Gewoon geen buffers voor het betreffende project op je proxy hebben vind ik wat veiliger.

hmmm... wb de OGRP2 / OGR-P2 is het niet helemaal handig dat dat bij client en proxy dan afwijkend is

ik heb inmiddels maar de oplossing van de 0 buffers gekozen totdat straks OGR echt afgelopen is.

en tja OGRp2 overal anders aanduiden is erg handig (NOT)

[Verwijderd]

Als het écht afgelopen is, komt die setting contestclosed=1 vanzelf in je .ini

[Verwijderd]

Verwijderd schreef op 11 mei 2004 @ 23:06:
Als het écht afgelopen is, komt die setting contestclosed=1 vanzelf in je .ini

Wanneer komt de AMD64 client? Als het moet wil ik hem zelf wel compileren

[Jive]

* Jive hoopt dat dutchman gauw kan switchen.

[ColdFusion]

* ColdFusion gaat morgen maar eens aan de slag de handel om te zetten

[Verwijderd]

/me heeft dat vandaag al gedaan en ziet dat er al 27000 stubs door zijn proxy zijn getrokken

bij deze wil ik Pim nog bedanken, hij weet wel waarom

[DSmarty]

De proxies draaien bij mij allemaal nieuwe versies enzo.
De stats zijn er ook, vanaf morgen zal ik statsruns draaien voor OGR-P2

[TGEN]

Verwijderd schreef op 12 mei 2004 @ 00:15:
* TGEN heeft dat vandaag al gedaan en ziet dat er al 27000 stubs door zijn proxy zijn getrokken

bij deze wil ik Pim nog bedanken, hij weet wel waarom

Hehe, late afternoon booty^H^H^H^H^Hphonecalls huh .

[Pim.]

Verwijderd schreef op 12 mei 2004 @ 00:15:
* Pim. heeft dat vandaag al gedaan en ziet dat er al 27000 stubs door zijn proxy zijn getrokken

bij deze wil ik Pim nog bedanken, hij weet wel waarom

No problem

[Mobster]

Helaas is Dutchman nog niet over zodat ik voorlopig maar direct naar dnet flush.
Verder viel me op (helemaal niet belangrijk) dat de OGR-P2 als extensie .ogf heeft meegekregen.

Nog even een vraag ter bevestiging....

Ik werk al een hele tijd met remote buffers. Op de main bak heb ik nu een buffer met OGR-P2, maar moeten mijn andere clients nu ook een update krijgen?

[Jive]

ik flush bij afwezigheid dutchman naar energy.keyserver.org

[Verwijderd]

Mobster schreef op 12 mei 2004 @ 08:55:
Ik werk al een hele tijd met remote buffers. Op de main bak heb ik nu een buffer met OGR-P2, maar moeten mijn andere clients nu ook een update krijgen?

Jazeker

[Verwijderd]

Mobster schreef op 12 mei 2004 @ 08:55:
Helaas is Dutchman nog niet over zodat ik voorlopig maar direct naar dnet flush.
Verder viel me op (helemaal niet belangrijk) dat de OGR-P2 als extensie .ogf heeft meegekregen.

Nog even een vraag ter bevestiging....

Ik werk al een hele tijd met remote buffers. Op de main bak heb ik nu een buffer met OGR-P2, maar moeten mijn andere clients nu ook een update krijgen?

remote buffer ?? is een proxy geen betere oplossing voor jouw?

[Mobster]

Proxy is nu te veel werk. Maakte voorheen niet uit, want ik kwam niet door de firewall en moest alles met de hand flushen. Nu zou het wel makkelijker zijn, maar ik ben bang dat mijn dagen bij mijn huidige baas geteld zijn dus heb niet zo veel zin om er heel veel tijd in te steken

Ik update nu maar gewoon bij een dnet keyserver en wat zie ik?

[May 12 07:54:31 UTC] The keyserver says: OGR work is available again.
[May 12 07:54:39 UTC] OGR: Retrieved 100 packets from server.
[May 12 07:54:41 UTC] OGR-P2: Retrieved 27 packets from server.
[May 12 07:54:41 UTC] OGR: Sent 2 packets (244.93 stats units) to server.

Ik krijg gewoon weer OGR werk binnen???

[Verwijderd]

zo te zien wel ja ??

maar een proxy is niet veel werk hoor en je hebt dan altijd een voorraadje klaar staan voor je koetjes

[ColdFusion]

Voor mensen die ppstats draaien en graag de buffer levels van OGR P2 willen zien op de server.html:

Open ppstats-ogr-7.2.pl

Zoek naar het onderdeel

code:

# Collect the stats from the proxy log files.

Daar een stukje onder vind je de regel

code:

if ($project eq "ogr") {

Dit was bij mij line 608, maar dat kan verschillen. Ik heb eea versleuteld aan ppstats.
Iig moet "ogr" dus "ogrp2" worden en de bufferlevels van OGR P2 worden weergegeven

[ph3n1x]

dus vannacht was de laatste nacht met ogr-p1 stubs.
heb er net nog wat doorgestuurt, en deze bak moet ook nog upgedate gaan worden
k heb er helaas weer eens overheen gelezen. ahh wel, dan maar een kleine vertraging. we staat toch redelijk goed op schema.

[Mobster]

* Mobster ruikt ruimte om in te lopen Al 4 bakken overgezet

[YakuzA]

ph3n1x schreef op 12 mei 2004 @ 16:07:
dus vannacht was de laatste nacht met ogr-p1 stubs.
heb er net nog wat doorgestuurt, en deze bak moet ook nog upgedate gaan worden
k heb er helaas weer eens overheen gelezen. ahh wel, dan maar een kleine vertraging. we staat toch redelijk goed op schema.

Er is bij dnet zelf ook niet een uniforme limiet gesteld, dus gewoon ASAP flushen en omzetten gewoon

[ph3n1x]

net ff de update gedaan, en een update van mn buffers.
dit weekend nog eens een extra bak aan de gang gaan zetten. Onze waarde collega's van Los Alcoholicos hebben het weer op ons gemunt

Yakuza, tns voor de hulp. Nu hopen dat ik niks kwijt ben.

[stappel_]

tering wat een karwei. al 38 bakken gedaan, met de hand.

maar wat gaan die stubs ook snel. nu al 412 gedaan vandaag.

[budi]

Nu maar hopen dat deze 490 ook meteen de officiele client wordt en er geen bugs worden gevonden, anders kunnen we weer al die servers en PC's af.... Ach, doe ik nog wat leuks op mijn werk

[Mobster]

Weer even een vraagje.

Zoals eerder gemeld werk ik met remote buffers. Om de een of andere reden krijg ik ook 'gewone' OGR binnen op die bak. Nu heb ik op alle clients de prio gezet op OGR-P2, OGR, RC5-72=0 en van beide OGR-contests haalt elke remote client 2 blokjes op.

Nu vraag ik me af of een remote client eerst OGR-P2 update en dus verder crunched of na een lege .ogf verder gaat aan .ogr en pas daarna remote update.

Iemand die daar iets definitiefs over kan zeggen???

[stappel_]

Mobster schreef op 12 mei 2004 @ 21:35:
Weer even een vraagje.

Zoals eerder gemeld werk ik met remote buffers. Om de een of andere reden krijg ik ook 'gewone' OGR binnen op die bak. Nu heb ik op alle clients de prio gezet op OGR-P2, OGR, RC5-72=0 en van beide OGR-contests haalt elke remote client 2 blokjes op.

Nu vraag ik me af of een remote client eerst OGR-P2 update en dus verder crunched of na een lege .ogf verder gaat aan .ogr en pas daarna remote update.

Iemand die daar iets definitiefs over kan zeggen???

dat ligt aan de frequent-threshold-checks waarde, of wel de Additional buffer-level checking.

OGR-p2 is voor de client een geheel verschillend project en heeft voor hem niks te maken met OGR. Als je geen waarde in de .ini heb staan zal hij hetvolgende doen: eerst het eerste project zijn lokale buffer opmaken, en dan het volgende project lokaal tot de laatste lokale buffer leeg is. dan gaat hij contact zoeken met de server of remote buffer voor een update op alle projecten.

andere opties die je kan instellen zijn:

1) fetch/flush all buffers if any in-buffer is not full.
2) fetch/flush all buffers if any out-buffer is not empty.
3) both 1) and 2). (implied if 'Dialup detection options' are enabled)
4) fetch/flush all buffers if any in-buffer is empty.

je kan dus twee dingen doen. of OGR=0 zetten of een andere waarde voor de buffer-level checking.

[Verwijderd]

Ik zou eigenlijk gewoon iedereen aanraden om OGR alvast uit te schakelen in de .ini files. Als het project definitief gestopt wordt, komt dat uiteindelijk via de proxy's wel bij de client terecht, maar dat is nog steeds zonde van die paar OGR stubs die dan niet meer in te leveren zijn.

Gisteren is de laatste verificatie gedaan, en ALLE OGR-P1 stubs zijn nu definitief binnen en gecheckt. Er is op dit moment dus geen andere reden dat er nog OGR wordt geaccepteerd dan om users de kans geven om over te stappen.

Zoals je kan zien zijn alle OGR-stubs op de full-proxies al weggehaald, dus mensen zouden alleen nog buffers binnen kunnen krijgen voor OGR van perproxies.
http://n0cgi.distributed.net/ogr-proxyinfo.html

[ColdFusion]

Ik heb op onze proxy gisteren contestclosed=-1 voor OGR gedaan OGR P2 here we come

[X-G]

Owh. godverdomme

Heb ik net bijna dik 555 bloks OGR 24 klaarliggen, en ik kom met die bak niet voor 23 mei online ...

[BwO]

Het actief draaien van OGR-24 was toch al verboden X-G.

[ColdFusion]

555 stubs OGR-24 is misschien net 5T Dus waar lig je wakker van

[YakuzA]

ColdFusion schreef op 13 mei 2004 @ 14:31:
555 stubs OGR-24 is misschien net 5T Dus waar lig je wakker van

voor sommige mensen is dat natuurlijk veel heh

[Jive]

* Jive heeft ook zijn perproxy ini's aangepast ..
DES2/CSC/RC5-64/OGR staan nu op contestclosed=-1

[X-G]

ColdFusion schreef op 13 mei 2004 @ 14:31:
555 stubs OGR-24 is misschien net 5T Dus waar lig je wakker van

Dan had ik over de 50.000 gezeten, toch lekker dacht ik zo .
Maar ik was dat aan het draaien omdat me SoB blokje al op 100% zit... dus ff wachten tot weer internet