Hello, When under load RLS performs in a "lumpy" manner. I believe this is (at least in part) because of the waitn_timer for sending NOTIFY requests. This timer is needed because, as the RFCs point out, it is important to buffer up RLS NOTIFY requests so as not to flood the network and client. However, I was wondering if a small change might help smooth out the lumps. What I was thinking of is: - Change the updated flag to be a number between 1 and the value of waitn_time (0 means no update) - Set the flag number based to the core_hash(did, NULL, waitn_time-1)+1 when the rls_presentity record is updated/inserted - Have RLS NOTIFY requests sent each second. After the first second records with the updated flag of value 1 are sent. After the second second records with the updated flag of value 2 are sent. Wrapping back to 1 after waitn_time seconds. This should help smooth out the sending of NOTIFY requests from RLS while still making sure they are buffered and take at most waitn_time seconds to come out. Can anybody see any reason why this won't work? Would there be any objections to me making this change? Regards, Peter -- Peter Dunkley Technical Director Crocodile RCS Ltd