On 08/27/2014 02:55 PM, Andrew Stitcher wrote:
> On Wed, 2014-08-27 at 13:39 -0400, Michael Goulish wrote:
>>
>> conclusion
>> =============================================================
>>
>>
>> Using the proton engine interface  (in C)  I am seeing two 
>> aspects of credit management that can strongly affect 
>> throughput.
>>
>>
>> The first is "credit stall".  If you frequently allow the credit 
>> available to the sender to drop to zero, so that he has to cool
>> his heels waiting for more, that can have a very strong effect
>> even in my simple test case, in which the receiver is granting 
>> new credit as quickly as possible, and is serving only 1 sender.
>>
>>
>> The second effect is "credit replenishment amortization".
>> It looks like the granting of new credit is kind of an expensive 
>> operation.  If you do it too frequently, that will also have a 
>> noticeable effect on throughput.
> 
> So my conclusion looking at the graphs for these tests would be that you
> will get the vast majority of benefit by using an initial credit of 40
> and replenishing with 20 at 20.

Funny, those are the exact numbers I chose for the default in Dispatch
(based on Mick's conclusion).

I think the 'amortization' effect will be fairly independent of local
conditions whereas the outstanding credit value will be primarily tied
to network latency (i.e. you will want a larger window for networks with
higher latency).

> 
> Of this only applies under the exact circumstances of these tests, until
> we have more data points. I'd suspect it must also depend on the message
> size too.
> 
> Andrew
> 
> 
> 

Reply via email to