Re: RX (download) limit problem

On Thu, 9 Jun 2005, Bruce Ashfield wrote:

> I've been digging around for over a week now and am either too slow
> to find what I need in the docs or via google, so I thought I'd stop lurking
> and see
> if anyone can either help me, or slap me in the head.
>
> I've been seeing a strange problem with my 5.4-STABLE freebsd
> firewall/router
> for about a month now and I can't for the life of me explain (or fix) it.
>
> It can be summed up as: "any type of download seems to be limited at less
> than
> 30 kB/s". I'm normally seeing around 26 kB/s and sometimes a bit higher. I'm
>
> connecting to a known high bandwidth public site as my performance test.
> Internal
> transfers on my LAN work fine, but nothing out of the firewall (either from
> a machine
> behind it or the firewall itself) can get a decent rate.
>
> I suspect my FreeBSD config, since my linux box (when directly connected) or
> an
> openBSD box are seeing transfers rates in excess of 200kB/s when fetching
> the same file.
>
> I'm running pppoe over a 3 meg DSL loop, using ipfilter and ipnat as my
> weapons
> of choice. I'm willing to try alternatives (i.e. pf), but I don't think it
> is my configurations
> for ipfilter and/or ipnat that are the problems. I've tried turning them
> down to almost
> nothing and haven't seen any changes at all in the limit.
>
> The closest thing I found that describes a similar problem is:
> http://freebsdaddicts.org/forum/viewtopic.php?id=575
>
> But trying what is suggested in that thread didn't help at all.
>
> In talking to some openBSD guys we had a theory that it might be something
> like
> the upload and download being kept symmetric and hence so low on the
> download
> side. In openBSD I've seen it solved using altq's but I can't find an
> equivalent in
> freeBSD without going to pf as my packet filter.
>
> ifconfig shows:
>
> fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> options=8<VLAN_MTU>
> inet6 fe80::202:b3ff:fe24:3797%fxp0 prefixlen 64 scopeid 0x1
> ether 00:02:b3:24:37:97
> media: Ethernet autoselect (10baseT/UTP)
> status: active
> fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> options=8<VLAN_MTU>
> inet6 fe80::202:b3ff:fe24:8182%fxp1 prefixlen 64 scopeid 0x2
> inet 10.*.*.* netmask 0xff000000 broadcast 10.255.255.255<http://10.255.255.255>
> ether 00:02:b3:24:81:82
> media: Ethernet autoselect (10baseT/UTP)
> status: active
> plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
> inet 127.0.0.1 <http://127.0.0.1> netmask 0xff000000
> tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1452
> inet 66.*.*.* --> 66.*.*.* netmask 0xffffff00
> Opened by PID 242
>
> I've tried everything from forcing full-duplex media, to tweaking any any
> every
> suggested tcp setting I could get at, none have an impact on the limit. I'll
> leave
> those details out for now in the interest of not too long an email.
>
> Right now I'd be happy enough with RTFM and/or someone else who at least
> recognizes the problem.

Interesting problem. This report however, does not belong on this list 
(stable_at_ or net_at_ might be more appropriate ones). May I suggest doing 
performance testing without any of the NAT/firewall rules in place? The 
asym nature of your DSL loop doesn't matter unless you are saturating your 
link both ways; downloads only go as fast as packets can get ACK'ed.

I would be willing to elaborate off list.

Andy

/*  Andre Guibert de Bruet  * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */
/*   Code poet / Sysadmin   * 636f 656b 2e79 5320 7379 6461 696d 2e6e */
/*   GSM: +1 734 846 8758   * 5520 494e 2058 6c73 7565 6874 002e 0000 */
/* WWW: siliconlandmark.com *      Tormenting bytes since 1980.       */