Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Accounting-Off or Accounting-On with AutoStop Enabled


One of the few cases where a single RADIUS transaction can turn into an excessive amount of work on the back end is in processing an Accounting-Off or Accounting-On from a NAS device with many current sessions active. In this case, an accounting stop record is generated for each session. With high-end GGSN and similar devices, which can serve 100,000 users or more, the amount of work the SBRC must do and the number of operations made against an SSR are exceedingly high. In any SLA, this should be considered to be a “failure recovery” case, with the agreement that any transactions being processed during this time are processed on a best-effort basis.

Forwarding Accounting-Off and Accounting-On transactions to a server dedicated to handle such overflow operations can provide an optimal solution to avoid unnecessary user-level outage while the work is being executed.


In general, Accounting-ON or Accounting-OFF typically is processed in one thread per transaction, reliably at approximately 1000 sessions per second on the highest single-CPU performing platforms (3–3.6 GHz). Retries of Accounting-ON or Accounting-OFF must be set so that the same SBR is tried multiple times for the length of the retry period required to terminate the sessions. For instance, if there are 20,000 sessions on a given NAS, the total retry length for the Accounting-ON or Accounting-OFF should be more than 20 seconds. Trying a second SBR in less than 20 seconds results only in duplicate work attempts, which results in conflicts and decreases the total throughput.

If multiple NAS devices may start in tandem—for instance, they are on the same UPS—load balancing each device with different primary and secondary starting points helps balance out the initial spike of work from processing an Accounting-ON.