Re: How to setup polling on 'bge' interface
A few points: - Polling and SMP are compatible in 6.1. In fact, they were compatible in earlier versions too; basically it's just the compile-time check that had to be fixed. - You may have to adjust some parameters in the kern.polling sysctl tree - specifically, kern.polling.burst_max, kern.polling.each_burst and kern.polling.user_frac might need tweaking. - The polling feedback algorithm does not work very well if your workload is focused largely on per-packet tasks (such as routing or bridging). You'll find that there is still idle CPU time at the point you start dropping packets. I have some work in progress to address this, but it's not yet committed. - Polling's major advantage is the avoidance of livelock on UP systems, and not improved performance. What level of traffic are you putting through this box? Is it routing/ bridging, or an endpoint like a web server? It's an endpoint with no more than 1k pkts/s in normal condition. Almost all traffic is UDP. I really intend to avoid locking my system in a high load situation. -- Att., Marcelo Gardini ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to setup polling on 'bge' interface
The limited testing I've done on a Sun V20z at work suggests that you can get better routing throughput in interrupt mode than polling mode. YMMV and this is before tweaking the polling parameters. (My testing also suggests that I don't really need to do any tweaking because the limiting factor is the gigabit interfaces rather than the V20z). I've noticed a higher (and variable) RTT with polling mode activated, without tweaking any parameters. This might not apply to bge, but the adaptive polling + fast interrupt changes that I made to if_em earlier in the year were a huge win over the standard polling code in terms of CPU utilization and packets per second. I think it also survived a load that caused normal polling to essentially livelock the machine. And, it had the advantage of automatically adapting to bursty loads. -- Att., Marcelo Gardini ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to setup polling on 'bge' interface
Marcelo Gardini do Amaral wrote: The limited testing I've done on a Sun V20z at work suggests that you can get better routing throughput in interrupt mode than polling mode. YMMV and this is before tweaking the polling parameters. (My testing also suggests that I don't really need to do any tweaking because the limiting factor is the gigabit interfaces rather than the V20z). I've noticed a higher (and variable) RTT with polling mode activated, without tweaking any parameters. Yes, the RTT will vary based on whether the interface has to wait a full tick or only a partial tick for the polling loop to become active. Adaptive polling eliminates most of this variance. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to setup polling on 'bge' interface
On Wed, 2006-Jul-19 22:38:56 -0400, Ed Maste wrote: - You may have to adjust some parameters in the kern.polling sysctl tree - specifically, kern.polling.burst_max, kern.polling.each_burst and kern.polling.user_frac might need tweaking. Note that increasing kern.polling.burst_max and kern.polling.each_burst will also increase the number of soft interrupts. - The polling feedback algorithm does not work very well if your workload is focused largely on per-packet tasks (such as routing or bridging). You'll find that there is still idle CPU time at the point you start dropping packets. I have some work in progress to address this, but it's not yet committed. I thought setting kern.polling.idle_poll would allow the CPU to utilise all idle time. The downside is that the system always shows as 100% utilised so it's very difficult to know how busy the system actually is. - Polling's major advantage is the avoidance of livelock on UP systems, and not improved performance. The limited testing I've done on a Sun V20z at work suggests that you can get better routing throughput in interrupt mode than polling mode. YMMV and this is before tweaking the polling parameters. (My testing also suggests that I don't really need to do any tweaking because the limiting factor is the gigabit interfaces rather than the V20z). -- Peter Jeremy pgpMPGKdXFs4w.pgp Description: PGP signature
Re: How to setup polling on 'bge' interface
Peter Jeremy wrote: On Wed, 2006-Jul-19 22:38:56 -0400, Ed Maste wrote: - You may have to adjust some parameters in the kern.polling sysctl tree - specifically, kern.polling.burst_max, kern.polling.each_burst and kern.polling.user_frac might need tweaking. Note that increasing kern.polling.burst_max and kern.polling.each_burst will also increase the number of soft interrupts. - The polling feedback algorithm does not work very well if your workload is focused largely on per-packet tasks (such as routing or bridging). You'll find that there is still idle CPU time at the point you start dropping packets. I have some work in progress to address this, but it's not yet committed. I thought setting kern.polling.idle_poll would allow the CPU to utilise all idle time. The downside is that the system always shows as 100% utilised so it's very difficult to know how busy the system actually is. - Polling's major advantage is the avoidance of livelock on UP systems, and not improved performance. The limited testing I've done on a Sun V20z at work suggests that you can get better routing throughput in interrupt mode than polling mode. YMMV and this is before tweaking the polling parameters. (My testing also suggests that I don't really need to do any tweaking because the limiting factor is the gigabit interfaces rather than the V20z). This might not apply to bge, but the adaptive polling + fast interrupt changes that I made to if_em earlier in the year were a huge win over the standard polling code in terms of CPU utilization and packets per second. I think it also survived a load that caused normal polling to essentially livelock the machine. And, it had the advantage of automatically adapting to bursty loads. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to setup polling on 'bge' interface
On Tue, Jul 11, 2006 at 04:09:08PM -0300, Marcelo Gardini do Amaral wrote: Hi, I'm trying to setup polling in my box. [...] But I always get some packet loss. A few points: - Polling and SMP are compatible in 6.1. In fact, they were compatible in earlier versions too; basically it's just the compile-time check that had to be fixed. - You may have to adjust some parameters in the kern.polling sysctl tree - specifically, kern.polling.burst_max, kern.polling.each_burst and kern.polling.user_frac might need tweaking. - The polling feedback algorithm does not work very well if your workload is focused largely on per-packet tasks (such as routing or bridging). You'll find that there is still idle CPU time at the point you start dropping packets. I have some work in progress to address this, but it's not yet committed. - Polling's major advantage is the avoidance of livelock on UP systems, and not improved performance. What level of traffic are you putting through this box? Is it routing/ bridging, or an endpoint like a web server? Ed Maste ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
How to setup polling on 'bge' interface
Hi, I'm trying to setup polling in my box. I'm using these options: options DEVICE_POLLING options HZ=1000 and in the rc.conf: ifconfig_bge0=inet xxx.xxx.xxx.xxx/xx polling media 1000baseTX mediaopt full-duplex But I always get some packet loss. I'm using FreeBSD 6.1 and SMP option in the kernel. I saw something about polling and SMP [1] but I ran 'config' and 'make' without any problem. Am I forgetting something else? [1] http://info.iet.unipi.it/~luigi/polling/ -- Att., Marcelo Gardini Registro .br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
