Rygl Aleš wrote:
Using (and updating) Acct-Delay-Time is correct when the request proxied and internal processing on the Radius server takes some time or there is a retry. If I use this file buffer for doing proxy then it makes sense of course. But I do not see the point updating it when the file is just being loaded to DB.
Arran and I both explained why it's useful. Perhaps you could read those explanations.
IMHO it matters to store the DB record with correct timestamps (I can use there either Event-Timestamp or %S)
No. Event-Timestamp is time when the event happened. %S is the time when the packet is being processed. It might be a long time after the event. Acct-Delay-Time is the delay between Event-Timestamp and %s. In mathematical terms: Event-Timestamp = %S - Acct-Delay-Time.
In this case the %S is "Sun Oct 5 12:11:21 2014", The delay indicates that it is not on time. When I store it using %S for session start I have to use a correction
The correction is to use Acct-Delay-Time.
The problem is that if there is a huge detail.work file loading it may take some time. Buffered-sql server then updates (or creates if it is not already present in the detail.work file) the Acct-Delay-Time on the time the request was waiting in the detail.work file. If the server manages to load the detail.work file every 20s the Acct-Delay-Time delay stored in DB is then not 10 but 20 or 30s (I am not sure here, it seems to me that previous value is replaced).
Yes. That's exactly how it's supposed to work. You shouldn't be storing Acct-Delay-Time in the database. It's not needed.
Now I see I could use Event-Timestamp and %S and reconstruct the delay from them...
That delay is Acct-Delay-time. Alan DeKok.