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