[pf4freebsd] Re: Maturity of this port?

[Max Laier]

On Wednesday 26 May 2004 00:29, Simon L. Nielsen wrote:
> On 2004.05.25 22:26:29 +0200, Max Laier wrote:
> > On Tuesday 25 May 2004 08:09, Ryan Verner wrote:
> > > Do update the webpage; I found the commit in freebsd's cvs tree
> >
> > Ya, that's a weak spot. I dislike (read hate) HTML with a passion and
> > just hacked the "pf homepage" together to have something. No actual
> > maintaining ever since. I really have to do something about it.
>
> If you write the content I don't mind doing the markup.. It could also
> be put on the main FreeBSD website, if you like.

This is great news, you will be hearing from me. Thanks for the offer!

> > > I can certainly test it on my own connections, but I'm looking to
> > > replace production-use OpenBSD shapers, and any downtime is a big no-no
> > > (in short, wireless ISP, many customers).  I think I'll look further
> > > into this project for my intended task once ALTQ matures and reaches
> > > the base system; any idea how long that would be?
> >
> > That depends largely on how much (positive) feeback I get on the patches.
> > I have limited testing capabilities and won't release this untested to
> > the world. If I get some promising results *soon* - including successful
> > tests on SMP boxes and possibly GigE NICs (just ask me to mod' the
> > drivers if you can't to it yourself) - I will try to get it in before
> > 5.3R. The import of pf 3.5 will happen before 5.3R in any case.
>
> Do you have any specific things that should be tested, or just I just do
> a simple ruleset and see if it blows up ?
>
> I can probably "abuse" a few of the test servers at work which is both
> SMP and GigE (em/bge based).  I hope to have time to do that sometime
> this week.

I have put both up-to-date em and bge patches on the site. em(4) extracted 
from Pyun YongHyeon's post to the ALTQ-ML and bge(4) from the rofug.ro 
patchset.

If possible test all the tree major disciplines (PRIQ, CBQ and HFSC) with a 
fully open pipe (i.e. bandwidth = 1Gb) and a fairly restricted (child) queue. 
Push some traffic through and see if you get the bandwidth you asked for 
(mind you that pf takes *BIT not *BYTE).

Best test scenario is something like:

Server1(ALTQ) ---[switch]------ Client1
		    |
		    +---------- Client2

On Server1 you have a full default queue (=1Gb or a bit less) and a smaller 
child queue[1]. Then you make the the big one the default and force traffic 
to Client2 through the small one[2]. Then start a download from both clients. 
If that works well (check $pfctl -vvsq output to see dropping in effect) you 
should redefine the small queue to borrow from the parent[3]. With that in 
effect you start a singel download from Client2 (where you should have full 
speed now). Then if that works as it should you start downloading from 
Client1 again and should have the same situation as before (w/o borrow in 
place).

[1] altq on $ext_if bandwidth 1Gb cbq queue { dflt }
	queue dflt bandwidth 100% cbq(default) { small }
	queue small bandwidth  5% cbq

[2] pass out on $ext_if from any to client2 queue small

[3]	queue small bandwidth  5% cbq(borrow)

NOTE: Always disable and reenable pf after changing altqs or they will not be 
setup properly:

$ pfctl -Fa -d; pfctl -ef pf.conf

-- 
Best regards,				| mlaier at freebsd.org
Max Laier				| ICQ #67774661
http://pf4freebsd.love2party.net/	| mlaier at EFnet
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: signature
Url : http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20040916/edcaa8a0/attachment.bin