Similar to external authentication and accounting, the fixed overhead per proxied transaction is approximately the value of one regular request/response pair, either authentication or accounting. This is because it takes about the same amount of time to parse the incoming RADIUS packet and generate a response as it does to generate a downstream packet and parse the response.
When the block is set as 0 in the .pro file [Acct] section, SBRC returns an ACK for the proxy accounting transactions and then passes the transaction state to a proxy thread (which is controlled by Max-Proxy-Threads). These functions are similar to MaxConcurrent. Unlike the relationship between Max-Acct-Threads and MaxConcurrent for external accounting, when it goes to proxy downstream, a RADIUS transaction is subsequently handled by the Max-Proxy-Thread pool for the response. So, the Acct Thread hands off the work to the Proxy Thread entirely, and the initial thread is free to handle another request. In general, the proxy threads may be larger than the Max–Acct-Threads, unless the external latency of the back end is higher than the external latency of the downstream, in which case they should be about equal.
When the block is not set to 0, the authentication or accounting thread handles everything and waits for the proxied response, and the number of threads must be related to the latency of the downstream (unless spooled accounting is used). See the SBR Carrier Reference Guide for information on configuring the Max-Proxy-Threads parameter.