• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

What buffer-level checking should I use in RC5?

mechBgon

Super Moderator<br>Elite Member
OK, maybe those who run pProxies can help me with this one...

I used to run the client with frequent buffer-level checking, which kept all work units flushed and kept the in-buffer full. A couple of times, people whose pProxy I was using mentioned that the client was making connection every 30 seconds even though it didn't need to... &quot;going through the motions.&quot; I have since disabled additional buffer-level checking so as to not bog down Mika's, but I was wondering if there's a happy medium where the client will send each work unit as it's completed, but won't harass the pProxy every 30 seconds. Looking at the client's menu, I see the following:


distributed.net client configuration: Buffer and Buffer Update Options
--------------------------------------------------------------------------

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 &quot;feeding&quot; 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).

Default Setting: 0
Current Setting: 0
New Setting --> 0


It sounds like #2 is what I want, but is the client going to try to connect every 30 seconds? There was also some question that in the incident I mentioned, my client was trying to connect every 30 seconds because I had ordered it to buffer more work units than it was allowed to have, making it want to fetch them but then slap its own hand away, so to speak. Any insights are appreciated! 🙂
 
Mechbegon, I'm not where I can check the config options, but this looks interesting

<< (Frequency/interval is determined by the 'Buffer-level check interval' option) >>


Can you find out where this is set, and what the default is?
 
Joe O has got it. Set it to 2, then look for the Frequency Interval setting. It is in hours:minutes, so set it to however long you want it to wait. 0:30 would be thirty minutes.

If I understand it correctly, it would then update every 30 minutes.

In the config, it's option 2, Buffer and Buffer Update options, then option 9 for the additional buffer level options, option 10 for the Interval 🙂
 
Option 3 should be OK, IF you are not trying to buffer more than 500 Packets.
When you exceed 500 packets (the built in client limit) and are still wanting more Work Units that is where the problem starts.
For instance my 850 is sitting here with 439 work units in 142 packets, a little over 3 WUs per packet on average.
If I wanted to keep say, 2000 work units in the buffer, and the proxy was giving me those little fragment 1-2-3-4 WU packets, it would fill only to ~1500 WU (500 packets at the 3 WU/packet average)
Because the client still desires more work units, it hits the proxy wanting more. The proxy says &quot;your full so I won't give you any more&quot;
30 seconds later, the client makes the same request and so on...
Of course when we have the clients requesting 32 WU (2^33) packets, and they are available from the proxy, this doesn't happen. 🙂


I don't know how accurate this all is, but it makes sense until a better explanation comes along.
viz
 
Back
Top