loss etc... It's not normal the CPU usage to stay
low while requests are queueing one after another to be processed...
Sincerely,
Borislav Dimitrov
e-mail: b.dimit...@ngsystems.net
GSM: 0888 51 55 45; 0889 28 54 57
NG Systems
Lavele 32 str, fl: 4,
Sofia, Bulgaria
On 23.12.2009, at 1
.net
GSM: 0888 51 55 45; 0889 28 54 57
NG Systems
Лавеле 32, ет: 4,
София, България
On 23.12.2009, at 15:43, Borislav Dimitrov wrote:
In radiusd.conf:
# THREAD POOL CONFIGURATION
thread pool {
start_servers = 1
max_servers = 1
min_spare_servers = 1
max_spare_ser
running well
how I set the thread pool to better concurrency?
2009/12/23 Borislav Dimitrov
Hi,
This question has been answered many times on this ML. I myself have
(at least tried) answered it two times. Here're some of my previous
messages:
Msg1:
Hi,
I've already tried to
ge stays low (< 5%), check your thread pool
settings and increase them to achieve better concurrency.
Sincerely,
Borislav Dimitrov
e-mail: b.dimit...@ngsystems.net
GSM: 0888 51 55 45; 0889 28 54 57
NG Systems
Lavele 32 str, fl: 4,
Sofia, Bulgaria
On 23.12.2009, at 15:10, Alisson wrote:
hi
Hi,
I've already tried to answer a similar question some time ago (and I'm
probably not the only one) but anyways...
The cause of the problems probably is some delay or packet loss or
something like that. Notice the Acct-Delay-Time value increasing as
the NAS retries to send the "lost" acco
Hi,
Frankly, I don't remember exactly your previous post (and don't have
the time to dig them up now) but here are some things that you should
check:
1) Is your Perl compiled with multi threading support (perl -V | grep
multi) # ...useithreads=undef/define
If your Perl i multi threaded, the
Hi,
I had similar problem ("radiusd: error while loading shared
libraries: libfreeradius-radius-2.1.5.so") several times these
days... just a few hours ago as well. Issuing a ldconfig on GNU /
Linux after installation from source fixes the problem for me. Not
source editing, version repl
Hi,
As far as I can see, the people on the list have provided you with a
lot of very useful suggestions on what could cause the problem. As I
said earlier (let me clarify) and to help you narrow things a little
bit - it's probably due to the RADIUS response timing out hence the
NAS compla
FIrst of all, have you enabled VSA on the NAS? A lot of VSAs for
different vendors are already supported. Check the dictionary files.
It's them that you should edit, if you need to at all. First check the
dictionary file in etc/raddb - it only includes various dictionary
files from (say /us
esh p
wrote:
Thanks. How to configure it?
On Mon, Apr 27, 2009 at 1:29 PM, Borislav Dimitrov > wrote:
Hi there,
I may be mistaken but... these are log message on the NAS aren't they?
If this is the case, I've experienced similar behavior with Cisco
VoIP routers (RADIUS Serv
Hi there,
I may be mistaken but... these are log message on the NAS aren't they?
If this is the case, I've experienced similar behavior with Cisco VoIP
routers (RADIUS Server DEAD and then... ALIVE). This happens if you
haven't properly enabled concurrency in FreeRADIUS - the CPU usage
stay
On 22.04.2009, at 13:23, Alan DeKok wrote:
Apostolos Pantsiopoulos wrote:
If any changes are to be made to the current
implementation to support multiple interpreters (one per thread)
would they show up in a 2.1.x release or a future one (2.2.x or
something)?
They will show up in the next
I noticed this version mismatch too: radiusd -v returns 2.1.5 when
built from the 2.1.4 tarball.
On 22.04.2009, at 17:25, Alan DeKok wrote:
John Dennis wrote:
I'd like to package up the current release but I can't because the
current tar files have version problems. What is currently on the
Hi,
Kalik's advices are very good - just to add some words:
Certainly such a failover is achieved on the client side. NAS's have
options to do that. On Cisco VoIP routers e.g.you can do it with the
RADIUS groups. You can have broadcast groups to achieve redundancy -
send the requests to mul
I hope this implementation will satisfy Borislav too. Will he be
able to
instantiate different perl scripts for different needs?
So, when do I start testing :)
Hi,
Yes, being able to instantiate and use several rlm_perl instances with
different scripts to take care of different circumsta
Hi,
On 15.04.2009, at 20:31, Alan DeKok wrote:
Borislav Dimitrov wrote:
Anyways my main trouble is being unable to use multiple rlm_perl
instances like this (I've put the comments to illustrate the
flexibility
of using *_clones which is now gone):
Ah... OK. That was *not* the inte
7;t work with 2.1.4 although my perl is compiled with
ithreads and multiplicity etc
On 15.04.2009, at 11:11, Alan DeKok wrote:
Borislav Dimitrov wrote:
I just subscribed so I won't be able to quote properly but I hope at
least the message is associated with the right thread (I found it
on the
w
. I am getting
the feeling that I am loosing in parallelism.
I understand that there may some benefits in the current
implementation (2.1.x) such as less threads, smaller memory
footprint etc. but why change something that has been tested
and working in the first place?
Borislav Dimitrov wrote
Hello,
I just subscribed so I won't be able to quote properly but I hope at
least the message is associated with the right thread (I found it on
the web archive of the mailing list). I've been using FreeRADIUS for
about 4 year now and it is a wonderful product - there's no question
why yo
Hello,
I just subscribed so I won't be able to quote properly but I hope at
least the message is associated with the right thread (I found it on
the web archive of the mailing list). I've been using FreeRADIUS for
about 4 year now and it is a wonderful product - there's no question
why yo
20 matches
Mail list logo
