Re: Traffic Shaping not working correctly after ipfw coverted to use pfil_hooks API

On Thu, 21 Oct 2004 15:24:41 +0200, Andre Oppermann <andre_at_freebsd.org> wrote:
> Vincent Poy wrote:
> >
> > Greetings everyone:
> >
> > I've recently updated from a March 6, 2004 -CURRENT to a October 19,
> > 2004 -CURRENT and this appears to have broken my traffic shaping using
> > ipfw/dummynet.  According to /usr/src/UPDATING, these are the changes.
> >
> > 20040817 - IPFW has been converted to use PFIL_HOOKS.
> > 20040827 - PFIL_HOOKS are a fixed part of the network stack now
> > 20040828 - Network stack runs without Giant lock
> > and also GENERIC kernel is now using the 4BSD scheduler instead of the
> > ULE scheduler.
> >
> > I'm on a 6Mbps/608Kbps ADSL connection with a 8 static IP's CIDR/29
> > block so what I am doing is using the FreeBSD box as the router for
> > outgoing packets with traffic shaping limiting the upstream at 480Kbps
> > so that when I upload, the downloads do not slow down.  I have tested
> > and the speeds I get is as follows without traffic shaping:
> >
> > Downloading only: 650KB/sec
> > Uploading only: 65KB/sec
> >
> > When traffic shaping was working correctly, downloading/uploading at
> > the same time with the bandwidth limit at 480Kbps would show 500KB/sec
> > down and 52KB/sec up.
> >
> > However, after the latest -CURRENT upgrade, it will do 200KB/sec down
> > and 52KB/sec up.  If I only download only, then it does show
> > 650KB/sec.  Normally, when I change the bandwidth to a number lower
> > than 480Kbps for the pipe, the download speeds would go up when
> > downloading.  However, I have tried in 10kbps steps down to 350kbps
> > but it still did not top 200KB/sec in downloading.
> 
> Interesting.  I have just looked through the ipfw to pfil_hooks changes
> as they relate to dummynet.  The only change to dummynet is to remove a
> stored pointer to the rtentry.  This doesn't influence the shaping and
> limiting of dummynet in any way.  Other than that the way ipfw gets
> called has changed and thus how dummynet is invoked too.
> 
> Can you verify that all dummynet queues and pipes are in use?  The only
> thing I can imagine is that somehow the dummynet info gets mangled and
> everything goes into the same queue/pipe.  Although that is unlikely.

Yeah, it's weird since I was trying to fine tune the bandwidth size of
the upstream pipe but noticed the download side was now only
delivering 1/3rd the speed it used to no matter what I set the
upstream side to since I'm only using ipfw/dummynet on the upstream
side as the downstream packets go directly from my ISP to the other
machines on the /29.  How do I verify all dummynet queues and pipes
are in use though?   this is the output from ipfw show:

root_at_bigbang [2:45pm][/home/vince] >> ipfw show
00039   42198   13780001 divert 8668 ip from 10.0.0.0/8 to any via xl0
00040      24       3864 divert 8668 ip from 172.16.0.0/12 to any via xl0
00041  339407  102789289 divert 8668 ip from 192.168.0.0/16 to any via xl0
00042     102       5342 divert 8668 ip from 208.201.244.224/29 to
10.0.0.0/8 via xl0
00043       4        188 divert 8668 ip from 208.201.244.224/29 to
172.16.0.0/12 via xl0
00044     300      15126 divert 8668 ip from 208.201.244.224/29 to
192.168.0.0/16 via xl0
00045     102       5342 divert 8668 ip from any to 10.0.0.0/8 via xl0
00046       4        188 divert 8668 ip from any to 172.16.0.0/12 via xl0
00047    2478     725705 divert 8668 ip from any to 192.168.0.0/16 via xl0
00048  213878   49058139 divert 8668 ip from any to 208.201.244.224/29 via xl0
00049 5407521 3326832795 skipto 100 ip from 208.201.244.224/29 to any
00050  680842  218217038 divert 8668 ip from any to any via xl0
00100   78346   20803996 allow ip from any to any via lo0
00200       0          0 deny ip from any to 127.0.0.0/8
00300       0          0 deny ip from 127.0.0.0/8 to any
63000      51       2671 allow ip from any to 10.0.0.0/8 out
63001       2         94 allow ip from any to 172.16.0.0/12 out
63002     431      26717 allow ip from any to 192.168.0.0/16 out
63003   58516    5627106 allow ip from any to 208.201.244.224/29 out
63004 2190398 1646865637 queue 1 tcp from any to any tcpflags ack out
63005     223      19476 queue 2 tcp from any to any dst-port 22,23 out
63006  345875   32423679 queue 2 udp from any to any not dst-port 80,443 out
63007   36129   11266686 queue 3 ip from any to any dst-port 80,443 out
63008   10031    3528577 queue 4 ip from any to any out
65000 3289575 1832553695 allow ip from any to any
65535       1         46 deny ip from any to any

Cheers,
Vince