OGR settings

[Witlof]

Aangezien RC5-64 afgelopen is zijn veel mensen over op OGR. Nu is er alleen een probleem. Vele members vullen dezelfde waarde in voor OGR als RC5. Hierdoor zijn er verschillende buffers leeg getrokken door mensen die niet weten voor hoeveel jaren ze nu op voorraad hebben.

Even ter verduidelijking. 1 packet bij RC5 was 1 tot 32 blocks. Dit stond redelijk vast en een aantal van zo'n 500 packets kon ruim 5K zijn waarmee je op een snelle PC een aantal dagen vooruit kon.
OGR packets heten stubs maar die stubs zijn in grote zo varierend dat er geen touw aan vast te knopen is. 500 stubs OGR kan al genoeg zijn voor een paar weken.

Let dus op en laat de eerste paar dagen gewoon een klein aantal fetchen zodat je kan zien hoeveel je ongeveer per dag doet om dan te kijken wat de beste settings zijn.

ik vertel dit omdat er mensen met een proxy dachten dat ze een voorraad aan moesten leggen van 40.000 stubs op de proxy van een subteam wat zo'n 8K aan RC5-64 blokjes deed

Strax zit iedereen zonder OGR-werk omdat er nu massaal wordt overgestapt. Flush dus met maten

[Verwijderd]

Tnx voor de Tip!!!!!
kben er niu 968 aan het laaien, en daar kan ik dus wel ff mee voor uit.Ik gebruik hem toch niet want ik ga een week op vakantie naar griekenland , zan zal ik um (zoals gebruikelijk) aan laten staan.

[stappel_]

Een goed gemiddelde is 10 stubs/units per dag op een 800Mhz machine.

[Witlof]

* Witlof dacht wel hier meer mensen mee te kunnen helpen voordat de helft van DPC zonder zat

[Krypt]

Thanks... ben ook net over met 2 pc's.. had um al bijna op 100 stubs gezet
Zit nu op 10.. 1x per dag vind ik wel goed..

[Mobster]

Goed punt Witlof.

Ik ben sowieso benieuwd hoeveel mensen RC5, OGR hebben staan. Ik ben bang dat veel mensen OGR=0 hebben en die machines staan dadelijk niets te doen

[Robinski]

hm... toch maar proxy van 2000 naar 100 verdanderd na het lezen van dit

[Robinski]

hebben jullie ook nog wat stubs

edit:

Waarom drukte ik net niet gewoon op edit????

[Mobster]

Andere vraag en opmerking.

Gebruik voor Athlon systemen de 463 client. Deze is veruit de snelste voor Athlon systemen!

Vraagje: Kan je voor OGR ook buffers halen via de mail?

[CBA]

Kan je ongeveer een voorbeeld geven van een standaard computer hoe snel die OGR doet, heb vroeger wel es OGR gedaan, maar toen was m'n client niet optimaal, dat ik kan weten ongeveer per computer hoeveel stubs ik moet binnenhalen.

[Mar]

Wat mist hier nog in dnet.ini voor OGR? de .exe start nu wel maar sluit ook weer meteen af

[parameters]
id=[e-mail]

[display]
detached=no
progress-indicator=on

[ogr]


[misc]
project-priority=OGR,DES=0,CSC=0,RC5=0

[networking]
dialup-watcher=passive

[Dutchman!]

Misschien dat hij een leeg kopje onder OGR niet pakt, zet er iets als fetch-workunit-threshold=32 onder.

[crisp]

Mobster schreef op 27 september 2002 @ 08:48:
Andere vraag en opmerking.

Gebruik voor Athlon systemen de 463 client. Deze is veruit de snelste voor Athlon systemen!

Vraagje: Kan je voor OGR ook buffers halen via de mail?

yep, mailtje sturen naar [e-mail] met in de body:

code:

contest=ogr
numblocks=xx

waar xx het aantal stubs is wat je wilt hebben

[Verwijderd]

grrrr, m'n novell client (v2.8015-469-CTR-01051421) wil ook geen OGR pakketjes pakken ...

Sterker nog, hij gaat gewoon random RC5 pakketjes proberen, terwijl er duidelijk RC5=0 in de config staat:

[misc]
project-priority=OGR,DES=0,CSC=0,RC5=0

Ook geprobeerd met DSMarty's proxy, maar no success ...

Anybody?

[stappel_]

Verwijderd schreef op 27 september 2002 @ 10:38:
grrrr, m'n novell client (v2.8015-469-CTR-01051421) wil ook geen OGR pakketjes pakken ...

Sterker nog, hij gaat gewoon random RC5 pakketjes proberen, terwijl er duidelijk RC5=0 in de config staat:

[misc]
project-priority=OGR,DES=0,CSC=0,RC5=0

Ook geprobeerd met DSMarty's proxy, maar no success ...

Anybody?

er is besloten dat alleen "high-end" systemen OGR mogen doen. Die beslissing ligt bij D.net. Ook de definitie high-end ligt bij hun. misschien dat je wat meer kan vinden in de faq-o-matic. van d.net

[Jeldert]

Hmm, dus alleen snelle pc's mogen OGR doen? Wa's dat nou voor domme beslissing. Ben blij dat ik geen OGR doe als ik dit hoor.

[Verwijderd]

De grens ligt wel erg laag hoor:

OGR may be automatically disabled for non-preemptive operating environments running on low(er)-end hardware.
The current OS and CPU combinations where this automatic disabling is currently effective (subject to change) are as follows:


RISC OS/ARM: (if the client is not being preemptively tasked)
all
MacOS/68k
all 680x0 processors
MacOS/PPC:
PPC601
Windows16/x86:
386-class, 486-class, 586-class (incl. Cx6x86 and K5)
NetWare/x86:
all

Dat is in ieder geval niet de oorzaak van mijn Novell probleempje

[Mobster]

Thankx crisp Daar heb ik wat aan.

Dan nog een ander vraagje. Ik werk met remote buffers. Stel dat ik de clients 1x per dag met mijn systeem (waar de buffers staan) wil laten connecten hoeveel stubs moet ik die pc's dan laten fetchen? Uitgaande van gemiddeld 1 GHz systemen....

[stappel_]

Verwijderd schreef op 27 september 2002 @ 10:57:
De grens ligt wel erg laag hoor:
[...]
Dat is in ieder geval niet de oorzaak van mijn Novell probleempje

en waarom niet? Novell staat ook in je lijstje hoor: NetWare/x86:

[Verwijderd]

Sorry, ik had het precies andersom gelezen

't zijn in ieder geval dual 1266Mhz P3 bakkies met Netware6, 'k ga wel een ander projectje doen ...

met RC5 gingen ze als een speer

[stappel_]

Verwijderd schreef op 27 september 2002 @ 11:40:
Sorry, ik had het precies andersom gelezen

't zijn in ieder geval dual 1266Mhz P3 bakkies met Netware6, 'k ga wel een ander projectje doen ...

met RC5 gingen ze als een speer

ze staan bij mij al jaren met de oude v2.7012 clients te draaien. met die nieuwe had ik alleen maar problemen met performance onder novell. arcserver hangen, login timeouts, etc.