I've just committed a new feature to the v3.1.x branch. It's called "queue_priority" for the thread pool. The idea is to allow the administrator to control how the server behaves in overload conditions. When a back-end database goes down, or 10K users log in at once, the server can't process packets as fast as they come in. This is "overload". The usual method of dealing with overload is to put the extra packets into a queue for later processing. But the question is, how should the queue be organized? In v3.0 and earlier, the queue had fixed behaviour. In v3.1.x, it is configurable. The 3 options are: time order packets by when they are received Note that replies from a home server are ordered by when the *original* packet came in, so they are prioritized. default Order by listener type proxy > auth > acct > detail > coa Packets from the same listener are ordered by "time". eap Order by ongoing EAP sessions. EAP authentication takes multiple rounds. This priority ensures that EAP sessions which are "further along" in the authentication process are handled with a higher priority. Packets with the same eap priority are ordered by "default" The "default" order is pretty much what was in 3.0 and earlier. If anyone has suggestions for additional prioritization methods, I'd be interested in hearing them. Alan DeKok.