Greetings,
The default values are based on 100 MB/s fxp driver. Luigi did heaps of
work a few years ago on this, and arrived at these values after lots of
testing (i think). (I also remember reading some interesting stuff where he
had fxp and a 3com card and was testing to see how many frame
I have the following rules:
$fwcmd add 600 pipe 602 src-ip 192.168.0.0/24 out
$fwcmd add 601 pipe 603 dst-ip 192.168.0.0/24 in
$fwcmd pipe 602 config mask src-ip 0x00ff bw 128Kbit/s queue 10KBytes
$fwcmd pipe 603 config mask dst-ip 0x00ff bw 128Kbit/s queue 10KBytes
And my test speed fr
In 2003, Jonathan Lemon added initial support for direct dispatch of
netisr handlers from the calling thread, as part of his DARPA/NAI Labs
contract in the DARPA CHATS research program. Over the last two years
since then, Sam Leffler and I have worked to refine this implementation,
removing
On Wed, Oct 05, 2005 at 02:24:20PM +0200, Ferdinand Goldmann wrote:
F> >In one case, we had a system acting as a router. It was a Dell PowerEdge
F> >2650, with two dual "server" adapters. each were on separate PCI busses.
F> >3 were "lan" links, and one was a "wan" link. The lan links were
F> >r
Ferdinand Goldmann wrote:
944mbps is a very good value, anyway. What we see in our setup are
throuput rates around 300mbps or below. When testing with tcpspray,
throughput hardly exceeded 13MB/s.
Increasing MTU should help to get better results, as long all devices in
network support jumbo fr
On Oct 5, 2005, at 7:21 AM, Ferdinand Goldmann wrote:
In one case, we had a system acting as a router. It was a Dell
PowerEdge 2650, with two dual "server" adapters. each were on
separate PCI busses. 3 were "lan" links, and one was a "wan" link.
The lan links were receiving about 300mbps
Kevin Day wrote:
In one case, we had a system acting as a router. It was a Dell PowerEdge
2650, with two dual "server" adapters. each were on separate PCI busses.
3 were "lan" links, and one was a "wan" link. The lan links were
receiving about 300mbps each, all going out the "wan" link at near
Kevin Day wrote:
In one case, we had a system acting as a router. It was a Dell PowerEdge
2650, with two dual "server" adapters. each were on separate PCI busses.
3 were "lan" links, and one was a "wan" link. The lan links were
receiving about 300mbps each, all going out the "wan" link at near
Andrew, Max,
exactly after one year I see if_bridge(4) having the same problem
with ng_ether(4) as old bridge(4) had. The problem is that packets
flowed thru ng_ether miss bridge processing. The problem is explained
well in this mail:
http://lists.freebsd.org/mailman/htdig/freebsd-net/2004-Ma
Jeremie Le Hen wrote:
em0: Missed Packets = 39
em0: Receive No Buffers = 2458
"Receive No Buffers" grows when polling is enabled and it's somewhat
a normal behaviour.
After running with polling enabled for two hours, the statistics were:
em0: Missed Packets = 2159959
em0: Receive No Buffers
[ Charset UTF-8 unsupported, converting... ]
> > Would an official person care to chime in about putting together a card/chip
> > vs. em(4) bugs matrix?
No sense, because bugs depend not on/only
card/chip, but at least load.
In my expierence quality of em interface
depends on quantity of ipfw rule
Darren Pilgrim wrote:
I'd be interested in finding out the specific chips with which people are
(not) having success. As em(4) supports an entire family of products,
rather than a single chip, it may be that some chips have quirks or other
gotchas the driver needs to address. It certainly woul
Hi,
(This doesn't seem to be AMD64-specific, so I think it
should be moved to the -net mailing list.)
Olaf Greve <[EMAIL PROTECTED]> wrote:
> [Setting up two machines with fall-back]
>
> Primary server:
> - Runs FreeBSD 5.4-Release AMD64
> - Connected to outside world via NIC 1 @ a real IP
John-Mark Gurney wrote:
Ragnar Lonn wrote this message on Tue, Oct 04, 2005 at 18:58 +0200:
Ceri Davies wrote:
I only call it "wrong" as it didn't agree with Archie's article or my
expectations, hence the quotes - I realise that it's subjective.
It just seems to me that packets leavi
14 matches
Mail list logo
