On 2016-06-09 8:47 PM, Jed Clear wrote:
> Thanks for the replies so far. Looks like I’ll have to wait until Saturday
> to test further. Starting with an L2 bridge seems like a good baseline to
> try. Although will probably take the easier step of just NAT w/o rules first.
At it's most basic, an l2 bridge can be created using -
ifconfig bridge0 create
ifconfig bridge0 addm vr0 addm vr1 up
There are a number of options and settings but the defaults work pretty
well in most setups .
You may want to consult ifconfig -
https://www.freebsd.org/cgi/man.cgi?query=ifconfig&apropos=0&sektion=0&manpath=FreeBSD+9.0-RELEASE&arch=default&format=html
> Switching to pfsense or a 6501 were already further down my option list, so
> agree with those.
>
> Had not considered just a change to pf, but will mull over. Although if I’m
> going to learn a new syntax, might as well get the pretty interface to go
> with it (pfsense) assuming I can get the performance.
pf works well for l3 stuff - I quite like it.
>
>
> With the current set up, I ran top during the download. Never got lower than
> 25% idle time on the CPU. ~30% system and and 40+% interrupt. 384M (of
> 512M) Free on memory, so no issue there. So doesn’t seem to be pegging the
> CPU with my full rule set.
That's interesting. The relationship between cpu use and throughput is
pretty linear. You should be able to 'peg' your cpu unless something
(ipfw?) is somehow throttling. You don't have, by chance, 'options
DUMMYNET' configured?
It might also be an tcp-ack-prioritization issue. You did mention that
your uplink speed was kind of crappy. Uplink saturation will affect
downlink speed if tcp acks aren't getting upstream quickly enough.
Maybe ipfw is somehow exacerbating that.
If the l2 bridge thing works and you're able to peg your net5501 cpu
then, notwithstanding vr driver fixes you're probably at the limit.
BUGS
The vr driver always copies transmit mbuf chains into longword-aligned
buffers prior to transmission in order to pacify the Rhine chips. If
buffers are not aligned correctly, the chip will round the supplied
buffer address and begin DMAing from the wrong location. This buffer
copying impairs transmit performance on slower systems but cannot be
avoided. On faster machines (e.g. a Pentium II), the performance
impact
is much less noticeable.
>
> -Jed
>
> On Jun 8, 2016, at 8:18 PM, Jed Clear wrote:
>
>> I just climbed out of the bronze age of home networking (DSL) and now have
>> "75Mbps service” from $BIG_CABLE_CO (iron age?). Before the DSL was the
>> bottle neck. Now it appears the 5501 is the bottle neck. My net5501-70 has
>> long been running nanobsd (FreeBSD 9.3-R) and ipfw as my perimeter
>> router-firewall-nat. While I’m not expecting 75, especially in the evening,
>> it’s not even close. Note all the speeds mentioned are download speeds in
>> Mbps. The upload is much worse, but not bothered by that in this exercise.
>>
>> When the cable modem was first brought up, a laptop directly on it pulled 56
>> with one of the speed test sites. The cable modem channel power and SNR
>> don’t look bad. Putting the 5501 in-line dropped the speed to the 30s.
>> Some googling later and I discover FreeBSD’s polling feature. So I added
>> options DEVICE_POLLING to the kernel config (HZ was already 1000), baked a
>> new image, set all the interfaces to polling and … it dropped like a rock to
>> 5 Mbps. Flipping off polling on the three interfaces brought it back to the
>> 30s.
>>
>> I tried the built in “simple” firewall rule set, and that did modestly
>> better than my, perhaps overly complicated, rule set. It got around 44. I
>> will work that later.
>>
>> Anyway I’m a bit baffled by the negative results when enabling polling. And
>> any other advice on improving the performance through the 5501 would be
>> appreciated. I haven’t given up on self help, but need a break from google
>> for a bit so will appeal to the collective wisdom of soekris-tech.
>>
>> Thanks,
>>
>> -Jed
>>
>> PS: To add insult to injury, I just repeated the directly connected laptop
>> experiment and clocked over 90. :-(
>>
>> ___
>> Soekris-tech mailing list
>> Soekris-tech@lists.soekris.com
>> http://lists.soekris.com/mailman/listinfo/soekris-tech
>>
> ___
> Soekris-tech mailing list
> Soekris-tech@lists.soekris.com
> http://lists.soekris.com/mailman/listinfo/soekris-tech
___
Soekris-tech mailing list
Soekris-tech@lists.soekris.com
http://lists.soekris.com/mailman/listinfo/soekris-tech
