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