Hoe na eind RC5 direct OGR doen?

Pagina: 1
Acties:

  • Witlof
  • Registratie: Mei 2000
  • Laatst online: 08:20
Aangezien er toch al flink wat koeien grazen voor Division Eindhoven is het eigenlijk wel verstandig nu het einde van RC5 toch wel in zicht begint te raken dat we geen tijd verliezen met het overschakelen naar OGR.

Hoewel ik toch al een tijdje meeloop met dit koeien gebeuren weet ik toch niet hoe ik precies de ini-file moet configgen zodat ik na RC5 direct over op OGR ga zonder iets aan te passen. Ook wil ik niet ieder packetje steeds versturen maar na bv 250 blokjes of meer, afhankelijk van de snelheid van de PC.

Zijn de instellingen ook clientversie gevoelig? Dus niet dat het op 8015 wel werkt en op 8007 bv niet? Altijd fijn om van te voren te weten zodat er rekening mee gehouden kan worden.

Wie helpt mij op weg? In de search staat alleen iets over direct overstappen van RC5 naar OGR maar dat is nog niet de bedoeling zolang we nog niet in de top 10 staan ;) Alvast bedankt! :)

Verwijderd

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

zoiets??

  • Witlof
  • Registratie: Mei 2000
  • Laatst online: 08:20
Je maar dan nog iets met buffer updates of zo. Als ik die op 0 zet dan doet hij zowel OGR als RC5. Een andere optie is als er steeds iets klaar is de buffers te laten update maar dat ben ik niet van plan omdat er dan wel erg vaak verbinding wordt gemaakt met de proxy.

  • Jeldert
  • Registratie: Juni 2001
  • Niet online

Jeldert

Rozijntjes

[rc5]
preferred-blocksize=33
fetch-workunit-threshold=1000

En dan die 1000 veranderen in hoeveel je er wilt.

Juist


  • Witlof
  • Registratie: Mei 2000
  • Laatst online: 08:20
En voor OGR? Niets invullen of wat?

  • NightBird
  • Registratie: Januari 2000
  • Laatst online: 21:56

NightBird

DPC-Crew Coding
Op vrijdag 01 maart 2002 20:04 schreef Witlof het volgende:
En voor OGR? Niets invullen of wat?
Gewoon een aantal instellen wat je er wilt hebben .. moet je OGR kenners voor hebben ..

WatHoorJeWaar · Asobakken
Eerdere projecten: Leading Courses · Brandstof-zoeker.nl · Voertuig-zoeker.nl


  • [eNeRGy]
  • Registratie: November 1999
  • Laatst online: 24-04-2025
50 OGR blokjes is genoeg voor weken geloof ik

  • stok
  • Registratie: Oktober 2000
  • Niet online
Op vrijdag 01 maart 2002 20:13 schreef [eNeRGy] het volgende:
50 OGR blokjes is genoeg voor weken geloof ik
jups
Maanden als je een 486 aan het grazen hebt :P

  • Witlof
  • Registratie: Mei 2000
  • Laatst online: 08:20
Zoiets heb ik nu maar nu doet de client na het aantal RC5 blokjes wat in de buffer zit de OGR stubbs. Als beide buffers leeg zijn gaat die updaten en begint de client weer met RC5 maar daarna weer OGR. Ik wil dus dat de client 1 project draait maar zodra RC5 is afgelopen dat er door gegaan wordt met OGR.

Iets zegt mij dat de instelling voor dit probleem hier ergens mee te maken heeft:

[buffers]
frequent-threshold-checks=?

Maar wat moet het zijn? Of heeft bovenstaande alleen met Dial-in te maken?

Verwijderd

Maargoed om nu al 50 OGR blokjes te bewaren heeft ook weinig zin. Als je pas over 90 dagen eraan begint zijn ze alweer waardeloos. Kan je toch beter handmatig alles even overzetten op het moment dat RC5 klaar is.

Verwijderd

Op zaterdag 02 maart 2002 09:43 schreef elbundy het volgende:
Maargoed om nu al 50 OGR blokjes te bewaren heeft ook weinig zin. Als je pas over 90 dagen eraan begint zijn ze alweer waardeloos. Kan je toch beter handmatig alles even overzetten op het moment dat RC5 klaar is.
volgens mij heeft ogr geen verloop datum, die blijven dus wel geldig

  • NightBird
  • Registratie: Januari 2000
  • Laatst online: 21:56

NightBird

DPC-Crew Coding
Op vrijdag 01 maart 2002 20:23 schreef Witlof het volgende:
Iets zegt mij dat de instelling voor dit probleem hier ergens mee te maken heeft:

[buffers]
frequent-threshold-checks=?

Maar wat moet het zijn? Of heeft bovenstaande alleen met Dial-in te maken?
Hier staan ze allemaal op 2 .. dan doetie dus alleen OGR als de RC5 buffer leeg is, dus een extra backupje, in plaats van random te staan grazen. En als je vaak genoeg online bent vultie het allemaal gewoon aan.

WatHoorJeWaar · Asobakken
Eerdere projecten: Leading Courses · Brandstof-zoeker.nl · Voertuig-zoeker.nl


  • Witlof
  • Registratie: Mei 2000
  • Laatst online: 08:20
Mo-Bees, jij zei toch dat jouw koeien na RC5 meteen over op OGR gingen? Hoe ziet dan je ini-file eruit?

  • Witlof
  • Registratie: Mei 2000
  • Laatst online: 08:20
Op zaterdag 02 maart 2002 10:03 schreef NightBird het volgende:

[..]

Hier staan ze allemaal op 2 .. dan doetie dus alleen OGR als de RC5 buffer leeg is, dus een extra backupje, in plaats van random te staan grazen. En als je vaak genoeg online bent vultie het allemaal gewoon aan.
Aangezien ik die buffers zelf niet kan update omdat ik niet vaak genoeg bij de PC's in de buurt kom wil ik dus eigenlijk een optie hebben die alleen RC5 doet maar als er geen RC5 blokjes meer zijn doordat het project is afgelopen of geen verbinding is met internet dat die dan pas OGR gaat doen en niet eerder.
Optie 0 zou hiervoor in aanmerking komen maar als iedere member van mijn team dit in zou stellen zou mijn verbinding continu open staan voor alle koeien wat ik liever niet heb als je begrijpt wat ik bedoel :)

  • Witlof
  • Registratie: Mei 2000
  • Laatst online: 08:20
Ik heb nu wat gevonden in de client:
Additional buffer-level checking:

The following options are extensions to normal threshold management and are
not usually necessary:
0) no additional buffer-level checking. (default)
1) ensure that there is always work available.
2) ensure that all completed work is kept flushed.
3) both 1) and 2). (implied if 'Dialup detection options' are enabled)
4) update on per-project buffer exhaustion.

Options 1, 2 and 3 will cause the client to frequently check buffers levels.
(Frequency/interval is determined by the 'Buffer-level check interval' option)
You might want to use them if you have a single computer with a network
connection "feeding" other clients via a common set of buffers, or if you
want to ensure that completed work is flushed immediately.
Option 4 is a hint to the client to work on a single project as long as
possible (updating per-project buffers individually), rather than loop through
all active/enabled projects (one combined update per pass).
Dat moet het dus zijn, optie 4 :)
Pagina: 1