Acct-Delay-Time attribute in buffered-sql server mode

Rygl Aleš ales at rygl.net
Sun Oct 5 16:37:07 CEST 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20141005/a0096d2d/attachment-0001.html>


More information about the Freeradius-Users mailing list