Date: Sat, 29 Nov 2008 08:26:57 -0800 (PST) From: David Roseman <david_5073@yahoo.com> To: =?iso-8859-1?Q?Sebastian_Tymk=F3w?= <sebastian.tymkow@gmail.com> Cc: freebsd-isp@freebsd.org, Marcello Barreto <marcello@linconet.com.br>, freebsd-pf@freebsd.org Subject: Re: PF + ALTQ - Bandwidth per customer Message-ID: <425805.11833.qm@web38505.mail.mud.yahoo.com> In-Reply-To: <692660060811290748i33059137g3977e51f692d8340@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Is top-posting allowed here? This product has been around longer than ALTQ and pf. So its unlikely that they threw away something that has always been superior to ALTQ to=20 replace it with ALTQ. The release notes go back to 1996. They also claim to have re-written the FreeBSD bridging code to gain 40% in performance.=20 http://www.etinc.com/release.notes RED and CBQ were technologies championed by Cisco. They're designed to work on CPU-starved routers. Cisco had a big problem because their routers were designed to move packets and they didn't have any cpu power available for intelligent processing required for packet shaping. So they designed these brain-dead "leaky bucket" and CBQ models to work on their cpu-starved= routers in the 90s. Inexplicably, these silly techniques were copied and p= ut into pubic operating systems, and people still use them to save what amounts to pennies compared to the new business they can attract with a better network. If you'd read the white papers you'd know its not a queue-based product and its totally custom. Window shaping is really the most important technology to reduce the amount of traffic in a nework. Slowing servers naturally without having to queue data makes a dramatic change in the delay patterns of a large network. Imagine 1000 servers sending 3000 bytes per window instead of 32K. The backup queue depths are dramatically= =20 reduced even without specific bandwidth limits per customer. It also has a traffic monitor that is indispensable in tracking down=20 DOS attacks, worms and out of control servers. I'd pay $500. just for the m= onitor. I have a problem, I fire up the monitor and bingo, I find the=20 problem. I think you can buy the lowest priced license and still use the monitor and gather statistics no matter how large your network is. David --- On Sat, 11/29/08, Sebastian Tymk=F3w <sebastian.tymkow@gmail.com> wrote= : > From: Sebastian Tymk=F3w <sebastian.tymkow@gmail.com> > Subject: Re: PF + ALTQ - Bandwidth per customer > To: david_5073@yahoo.com > Cc: freebsd-pf@freebsd.org, freebsd-isp@freebsd.org, "Marcello Barreto" <= marcello@linconet.com.br> > Date: Saturday, November 29, 2008, 10:48 AM > Hello, >=20 > Why do you think it's unrealiable technology ? > I think system that you propose rely on this technology ;) > Most of this use bsd/linux/unix on board with own solutions > and than they're > packed into the box > with cute web interface. > Of course I can be wrong... >=20 > Best regards, >=20 > Shamrock >=20 > 2008/11/29 David Roseman <david_5073@yahoo.com> >=20 > > > > > > > > --- On Mon, 11/24/08, Marcello Barreto > <marcello@linconet.com.br> wrote: > > > > > From: Marcello Barreto > <marcello@linconet.com.br> > > > Subject: PF + ALTQ - Bandwidth per customer > > > To: freebsd-pf@freebsd.org, > freebsd-isp@freebsd.org > > > Date: Monday, November 24, 2008, 4:04 PM > > > Hello Folks, > > > I believe you have heard this several > times, but I'm > > > new to FreeBSD and i'm trying to change my > bandwidth > > > control from Linux (iptables + TC + iproute) to > Freebsd (PF > > > + ALTQ). > > > I read about PF and I was very interested > on it, but I > > > want to limit the bandwidth (Download and Upload) > from each > > > customer behind a router (Obviously, FreeBSD with > PF.).. > > > There are several networks and a lot of > customers, and with > > > my rules, only what I got was each customer > sharing the same > > > queue... > > > > > > There are my rules: > > > altq on $external cbq queue {def_up, def_up300, > def_up450, > > > def_up600, def_up1000} > > > altq on $internal cbq queue {def_down, > def_down300, > > > def_down450, def_down600, def_down1000} > > > > > > queue def_up bandwidth 10% cbq(default) > > > queue def_down bandwidth 10% cbq(default) > > > > > > queue def_up300 bandwidth 128Kb cbq(red) > > > queue def_up450 bandwidth 200Kb cbq(red) > > > queue def_up600 bandwidth 300Kb cbq(red) > > > queue def_up1000 bandwidth 500Kb cbq(red) > > > > > > queue def_down300 bandwidth 300Kb cbq(red) > > > queue def_down450 bandwidth 450Kb cbq(red) > > > queue def_down600 bandwidth 600Kb cbq(red) > > > queue def_down1000 bandwidth 1024Kb cbq(red) > > > > > > > > > pass in quick inet proto {tcp, udp} from > <mylocalnet> > > > to any queue def_down300 > > > pass out quick inet proto {tcp, udp} from > > > <mylocalnet> to any queue def_up300 > > > > > > > You should consider a commercial product rather than > relying on > > old and somewhat unreliable technology. We've been > able to squeeze a > > lot more customers onto our network for a $3500. > investment. It paid for > > itself in 2 months. We have a dual-core 2.33Ghz system > passing 95Mb/s > > with 12000 rules in place and it runs at about 10%. > The latest version is > > truly amazing. > > > > http://www.etinc.com > > > > > > Regards, > > > > David =0A=0A=0A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?425805.11833.qm>