> Kostas Kalevras <[EMAIL PROTECTED]> wrote:
> > That value should be configurable at some point. It was selected
> > somewhat large so that radrelay didn't create problems to slow
> > radius servers when it started sending a large detail file.
>
> It should instead send packets as fast as the server responds.
>
> > You can safely make it as small as you want. radrelay is single
> > threaded and serialized so there 's not much to worry about
> > (although the single threading should change also).
>
> I don't see any benefit in having it threaded. See the updated
> "radclient" for code which keeps track of many packets simultaneously,
> and does it for a controlled maximum rate. That code could probably be
> re-used in radrelay.
>
> Alan DeKok.
Hi,
a few notes on tests I did to transfer a large backlog of accounting
request from server RS1 to RS2:
1. Using radrelay, the best I could achieve is about 50 packets/sec,
with the following two changes:
# sdiff -s radrelay.c radrelay.c.backupOriginal
tv.tv_usec = 1000; | tv.tv_usec = 25000;
ms_sleep(1); | ms_sleep(140);
I also tried various values of NR_SLOTS, but it doesn't change the overall
time it takes to transfer a large backlog of accounting requests.
Note that the CPU on RS1 (running the radrelay instance that is processing
the backlog) still takes less than 1% of CPU, with or without the above
changes.
2. With radclient, I got the following results, using it unchanged:
#radclient -c 4600 -f afew -r 5 -t 1 192.168.12.80 acct pwtest
- v1.72 (the one in freeradius 1.0.1): 87.9 pkts/sec
- v1.76 (from Dec 3 CVS snapshot) : 86.7 pkts/sec
==> about the same for v72 & v76, but definitely faster than radrelay.
btw, when using the -n option in 1.76, the best rate goes down to 50 pq/sec,
just like radrelay (even when using a large number, say -n 100, or -n 200).
It seems to be due to the fact that "select(0, NULL, NULL, NULL, &tv)"
sleeps
for a minimal time. This time appears to be 10 ms on the two platforms I
used
for testing (one Linux/I386, one SUN Solaris/UltraSPARC-II 296MHz)
3. Results in (1) and (2) above are way below my target of 200 packets/sec,
and way below what radiusd can take from a NAS.
That 200 p/s rate is needed to keep up with my NAS (which can sustain
that 200 p/s for a few hours), and avoid accumulating a backlog when
both RS1 and RS2 are up.
So, threading of radrelay sounds like a must. Agree, or are there other
configuration parameters I can try?
thanks,
-Bruno
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
