[DNet] frequent-threshold-checks instelling

[Verwijderd]

Kan iemand mij vertellen waar de optie frequent-threshold-check (onder [buffers]) voor is?
Heb een tijdje gezocht maar niet exacte betekenis gevonden.
De een heeft als waarde 2, dan ander 4, weer iemand anders had yes

Op dit moment hebben al onze leden de volgende instellingen:

code:

[parameters]
id=[e-mail]

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

[triggers]
restart-on-config-file-change=yes

[display]
progress-indicator=auto-sense

[rc5-72]
fetch-workunit-threshold=15

[networking]
keyserver=proxy.virtualmeadow.nl
autofindkeyserver=no
nofallback=true

Wat handig zou zijn is een configuratie die er voor zorgd dat als de proxy uitvalt de koetjes nog even vooruit kunnen en dus niet uit hun neus gaan staan eten.

[ColdFusion]

Je had natuurlijki gewoon in de configuratie modus van de client kunnen kijken

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) 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.

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).

En om te zorgen dat de koeien niet uitvallen als de proxy uit de lucht is, is gewoon zorgen dat ze een buffer hebben die groot genoeg is dat ze minimaal 1 dag oid voorruit kunnen. Dus de fetch-workunit-threshold hoog genoeg zetten Het kan ook zelfs in uren, dan kijkt de client hoe snel de pc is en bepaald dan hoeveel wu's die nodig heeft voor het tijdsduur dat jij invult. Maar zie daarvoor maar de configuratie modus (rechtermuisknop in de client en dan configuratie).

[Verwijderd]

ColdFusion schreef op 06 juni 2004 @ 22:06:
Je had natuurlijki gewoon in de configuratie modus van de client kunnen kijken

Ja, maar dan moet je wel de link Additional buffer-level checking <=> frequent-threshold-checks kennen

Dus bedankt voor die link

En hoe hoog de fetch-workunit-threshold ook staat, als z'n buff-in op een gegeven moment leeg is en de proxy is down, dan is hij toch voorlopig uitgegraasd of niet?

[ColdFusion]

Nou het voordeel van RC5 is dat er zoiets bestaat als randoms. Dus mocht de buffer leegraken, dan zal de client verder gaan met het grazen van random wu's. Daar zit wel een kleine risico aan. Een andere client ergens op de wereld kan net zo goed precies datzelfde wutje random gedaan hebben. En dat ene wutje telt maar 1x mee. Dus als die client hem eerder inlevert dan jij dat doet, telt hij voor jou niet mee.

Maar in deze fase van RC5 waarin we nu zitten valt dat verlies in de praktijk reuze mee Maar gewoon zorgen dat je proxy altijd bereikbaar is en indien niet, dat hij weer zsm up is, is natuurlijk het beste

[Verwijderd]

nou... Ik heb hier errug weinig aan toe te voegen...

Kan ik met een gerust hart op vakantie

[joh14vers6]

Misschien is het handig om de projectnaam in de topictitel te melden. [RC5-72]

[Verwijderd]

Ohw, dan vind ik onze huidige config wel prima zo
Bedankt ColdFusion!

Prettige vakantie Floppus!
(Was het voor mij maar ook al zover )

joh14vers6 schreef op 06 juni 2004 @ 22:54:
Misschien is het handig om de projectnaam in de topictitel te melden. [RC5-72]

Dit onderwerp gaat niet specifiek over RC5-72, alleen de laatste reactie van ColdFusion.

[ Voor 3% gewijzigd door Verwijderd op 06-06-2004 23:10 ]

[DSmarty]

Topictitel verduidelijkt )