On Sunday 05 of October 2014 14:30:37 Alan DeKok wrote:
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.
Yes, I did, several times :) I have already checked the latest version of sql scripts from freeradius package and I am going to start use Event-Timestamp, it is definitely a better solution.
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.
I thought %S corrected by Acct-Delay-Time of course.
Acct-Delay-Time is the delay between Event-Timestamp and %s.
In mathematical terms: Event-Timestamp = %S - Acct-Delay-Time.
Yes.
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.
Yes, It is clear.
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.
Excuse me, but do not understand. From my point of view I do not see a reason for manipulating Acct-Delay-Time this way and replacing the original value from the request with a new one based on time needed for request processing. If you keep original value, later on, when you query DB, it would be clear when the session started (Event-Timestamp) and how much was the session start packet delayed (Acct-Delay-Time).
You shouldn't be storing Acct-Delay-Time in the database. It's not needed.
Well, we would need to store it from diagnostic reasons. It indicates possible performance problems on the NAS. For exact session start I will start to use Event-Timestamp. Is there a way how to save the original Acct-Delay-Time to DB in buffered-sql mode? Ales