[ogr]Unable to load any work. Quitting...

[Roel]

Ik heb hier 10 pc'tjes staan met een reborn kaart in. Dat betekend dat iedere keer de harddisk terug naar een beginpunt gaat. Ben beheerder van die computers, dus het sneaky installeren van de koe is het probleem niet
Op alle pc's draait een distributed.net client, OGR.

Wat wel het probleem is zijn de buffers. Omdat er windows ME (niet mijn keuze!) op de computers staat worden ze regelmatig reboot en de buffers waar hij mee bezig was zijn weg. Hij haalt dan weet nieuwe buffers op van de proxy. Dit heeft een tijdje gewerkt, maar 90% van de opgehaalde stubs komen niet terug omdat ze te vaak gereset worden.

Poging 2: De computer van de kassa heeft een share openstaan waar de buffers en de checkpoint-file op staan. Dat werkt redelijk, maar ik krijg af en toe deze melding:

[Jun 21 06:59:59 UTC] Unable to load any work. Quitting...
[Jun 21 06:59:59 UTC] *Break* Shutting down...
[Jun 21 06:59:59 UTC] Shutdown complete.

Ik durf niet te zeggen of de kassa PC dan al aanstaat of niet.
Best irritant, zeker omdat ik dan een paar uur een P4 mis..

Wat ik al bedacht had: Met een loopje kijken of de koe draait en als die niet draait opnieuw opstarten. Het liefste zo verborgen mogenlijk, de meeste mensen die hier komen snappen niet veel van computers

Bestaat er een programma'tje dat dat doet of moet ik zelf iets programmeren?
Mijn programmeer kennis gaat neit verder dan bash en php, daar kom je niet ver mee op Windows

[ColdFusion]

Dat komt omdat de client geen OGR buffer heeft. OGR kent geen randoms. Je moet de client dan eerst 1x starten met -fetch commando: In command naar juiste dir gaan en dan dnetc -fetch

Voor je andere probleem zou ik het niet zo 123 weten. Maar als je bv bij startup eerst het fetch commando laat uitvoeren, is het denk ik ook wel opgelost.

[ Voor 18% gewijzigd door ColdFusion op 21-06-2003 11:54 ]

[Roel]

ColdFusion schreef op 21 June 2003 @ 11:50:
Dat komt omdat de client geen OGR buffer heeft. OGR kent geen randoms. Je moet de client dan eerst 1x starten met -fetch commando: In command naar juiste dir gaan en dan dnetc -fetch

Voor je andere probleem zou ik het niet zo 123 weten.

Wanneer zou ik dan dnetc -fetch moeten doen? De eerst keer worden de buffers gewoon goed aangemaakt, maar 's ochtens als de computer wordt aangezet kan hij zijn buffers niet vinden ofiets...

[ColdFusion]

Als de client gestart wordt en hij kan geen buffer vinden, wat komt door die reborn kaartjes, dan start hij niet. Dus je zou voordat de client gestart wordt het fetch commando moeten laten uitvoeren. Heeft de client toevallig nog wel een buffer, dan kan het fetch commando nog geen kwaad. Zeker als je een eigen proxy hebt draaien daar, zou ik
[ogr]
fetch-workunit-threshold=1
doen, dan is het ergste wat er kan gebeuren, dat de client 1 extra stub ophaalt.

Gebruik je overigens voor die 10 clients, wel allemaal verschillende checkpoint filenames? Dus dat ze niet allemaal naar dezelfde proberen te schrijven? Dat werkt volgens mij niet nl.

[Roel]

ColdFusion schreef op 21 juni 2003 @ 11:58:
Als de client gestart wordt en hij kan geen buffer vinden, wat komt door die reborn kaartjes, dan start hij niet.

De buffers staan dus op het netwerk. Stond toch in m'n verhaaltje?

Dus je zou voordat de client gestart wordt het fetch commando moeten laten uitvoeren. Heeft de client toevallig nog wel een buffer, dan kan het fetch commando nog geen kwaad. Zeker als je een eigen proxy hebt draaien daar, zou ik
[ogr]
fetch-workunit-threshold=1
doen, dan is het ergste wat er kan gebeuren, dat de client 1 extra stub ophaalt.

Dat staat ook in m'n verhaaltje.. 10 clients die 5x per dag een extra stub ophalen en die weggooien en dat 6x in de week is imho een beetje overdreven.

Gebruik je overigens voor die 10 clients, wel allemaal verschillende checkpoint filenames? Dus dat ze niet allemaal naar dezelfde proberen te schrijven? Dat werkt volgens mij niet nl.

Jep, 10 verschillende buff-in's, buff-outs en checkpoint namen.

[ColdFusion]

Oh okee, ik dacht dat je met een shared buffer werkte. Ze hebben dus ook allemaal nog eens hun eigen buffer. Hoe groot is die buffer? Als die gewoon die gewoon zeg 3 (afhankelijk van hoe snel die dingen zijn), moeten die iig nooit leeg kunnen zijn als je
frequent-threshold-checks=1
hebt ingesteld bv.
Zeker icm een checkpoint file, waarbij die die stub dus ook niet weg zou moeten gooien, maar netjes verder moet gaan.

Hmm als bovenstaande het geval is, vind ik het vreemd waarom die dan toch geen werk kan vinden. Staan de clients wel lokaal op de pc's? Het zou kunnen dat de dnet client misschien sneller gestart is, als dat de netwerk verbindingen op gang zijn misschien?

[Roel]

ColdFusion schreef op 21 June 2003 @ 12:08:
Oh okee, ik dacht dat je met een shared buffer werkte. Ze hebben dus ook allemaal nog eens hun eigen buffer. Hoe groot is die buffer? Als die gewoon die gewoon zeg 3 (afhankelijk van hoe snel die dingen zijn), moeten die iig nooit leeg kunnen zijn als je
frequent-threshold-checks=1
hebt ingesteld bv.
Zeker icm een checkpoint file, waarbij die die stub dus ook niet weg zou moeten gooien, maar netjes verder moet gaan.

Hmm als bovenstaande het geval is, vind ik het vreemd waarom die dan toch geen werk kan vinden. Staan de clients wel lokaal op de pc's? Het zou kunnen dat de dnet client misschien sneller gestart is, als dat de netwerk verbindingen op gang zijn misschien?

Hmm, dat laatste kan idd de oorzaak zijn. Hij staat op 2 buffers ingesteld, meer dan genoeg, gok ik?

Ik zal eens kijken wat ie met frequent-threshold-checks=1 doet..

[ColdFusion]

Roel schreef op 21 June 2003 @ 12:34:
Hmm, dat laatste kan idd de oorzaak zijn. Hij staat op 2 buffers ingesteld, meer dan genoeg, gok ik?

Ligt eraan wat voor PC's en of het OGR-24 of 25 is. Een OGR 25 stubs is al snel 200 su's. Mijn celly 750 bv doet daar hooguit maar 2 stubs per dag. Dus dan is het zeker genoeg. Maar ook omdat je daar zelf een proxy hebt draaien is 2 wel voldoende.

Ik zal eens kijken wat ie met frequent-threshold-checks=1 doet..

Die instelling betekend dat hij zodra hij ook maar 1 stub af heeft, verbinding maakt met de proxy om een fetch/flush actie te doen. Stel je bv 2 in, dan doettie dat pas na 2 voltooide stubs etc.

[Roel]

Maargoed, het aantal stubs is het probleem niet, denk ik. Hij geeft aan helemaal geen buffers te kunnen vinden, denk ik?

[ColdFusion]

Nee idd, ik zou eens kijken naar datgeen ik eerder zei; dat de client eerder gestart is als dat de netwerkverbinding gereed is. Dat is eigenlijk het enige wat ik nu zo kan bedenken.

Je zou eens kunnen proberen eventueel de clients ook op de share te zetten, en dan in startup de link via de netshare naar de client.

[[eNeRGy]]

Heb je misschien een nieuwere client geinstalleerd? want de rc5-72 clients hebben andere buffers voor ogr dan de rc5-64 clients

[Roel]

[eNeRGy] schreef op 21 June 2003 @ 13:32:
Heb je misschien een nieuwere client geinstalleerd? want de rc5-72 clients hebben andere buffers voor ogr dan de rc5-64 clients

Nope, overal dezelfde client met dezelfde buffers...

ColdFusion schreef op 21 June 2003 @ 13:21:
Je zou eens kunnen proberen eventueel de clients ook op de share te zetten, en dan in startup de link via de netshare naar de client.

Dat ga ik eens proberen...