On Sun, 5 Dec 2004, Bruno Lague wrote:
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:
I 've been working on a few changes to radrelay, mainly regarding making the sleep time configurable and adding a few more things. The changes have been made in radsqlrelay initialy but they 'll go in radrelay also. That won't change your numbers but at least make a few things configurable.
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.
Well, NR_SLOTS does not really matter if your accounting is quick enhough. Try commenting out the ms_sleep() between the do_send() calls.
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.
That's normal it's an I/O bound application.
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?
threading sound like an idea yes. Another idea is to get load-balancing code inside freeradius. Then you could do something like the following:
accounting {
loadbalance {
relay_detail1
relay_detail2
relay_detail3
}
}
radrelay relay_detail1
radrelay relay_detail2
radrelay relay_detail3That way you don't need to change much (apart from a few changes to the server core) and you increase the overall performance by parallelizing radrelay and the detail module.
thanks, -Bruno
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Kostas Kalevras Network Operations Center [EMAIL PROTECTED] National Technical University of Athens, Greece Work Phone: +30 210 7721861 'Go back to the shadow' Gandalf
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
