[jboss-jira] [JBoss JIRA] Closed: (JGRP-481) Send replenishments sooner: after min_credits bytes have been received *not* after max_credits - min_credits have been received

[Bela Ban (JIRA)]

     [ http://jira.jboss.com/jira/browse/JGRP-481?page=all ]

Bela Ban closed JGRP-481.
-------------------------

    Resolution: Won't Fix

The whole point of SFC is that we do block. Frequent short blockings reduce the message loss rate, therefore lead to fewer retransmissions. If we introduced min_credits, we'd be more or less the same as FC.
In 2.6 and later, we need to see whether FC or SFC gets better performance with multi-core nodes in a fast/low-latency network, and pick the faster protocol as default flow control.

> Send replenishments sooner: after min_credits bytes have been received *not* after max_credits - min_credits have been received
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-481
>                 URL: http://jira.jboss.com/jira/browse/JGRP-481
>             Project: JGroups
>          Issue Type: Sub-task
>    Affects Versions: 2.4.1 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5
>
>
> 2) #1 alone will hurt performance in a steady-state system. If A and B are sending messages to each other, with a config of max_credits = 1,000,000 and min_credits=100,000, B will send A 900,000 credits when it has read that many. It will take a while for the credit replenishment to reach A (since B is also sending), so A will send 100,000 more and begin blocking. It will then get the 900,000 credit replenishment, send 900,000 and begin blocking again. Under the old system it would have gotten 1,000,000 bytes -- now it only gets 900,000.
> Solution to that is to change the meaning of min_credits. Currently, receiver sends credit when it has received_bytes >= (max_credits - min_credits). If min_credits is 100,000, credits will only be sent when the sender is almost out. The standard value of min_threshold=0.10 is very conservative, but was needed because the more frequently replenishment messages with no set number of bytes get sent, the more likely the sender is to get too many credits and OOME.
> If credit replenishment messages only give the number of bytes the receiver has read, then there is no OOME risk. Therefore, sending replenishment messages frequently makes sense. So, I propose the receiver should send credit when received_bytes >= min_credits, rather than the current approach of sending when received_bytes >= max_credit - min_credit.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira