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