I'm no expert, but I imagine the problem is because the net processing
of FreeBSD is not pipelined enough. We are now able to affordably throw
many gigabytes of RAM into a machine, as well 2 to 8 CPUs. So why not
allow for big buffers and multiple processing steps?
I be happy to give up a
Old Synopsis: error while compiling with device ath_rate_amrr
New Synopsis: [build] error while compiling with device ath_rate_amrr
Responsible-Changed-From-To: freebsd-net->sam
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Jul 6 09:17:46 UTC 2008
Responsible-Changed-Why:
Over to
Synopsis: It is not visible passing packets in tcpdump
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Jul 6 09:16:38 UTC 2008
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=122685
__
Old Synopsis: Server failure due to netgraph mpd and dhcpclient
New Synopsis: [netgraph] Server failure due to netgraph mpd and dhcpclient
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Jul 6 09:09:28 UTC 2008
Responsible-Change
On Sat, Jul 5, 2008 at 2:03 AM, Paul <[EMAIL PROTECTED]> wrote:
> I tried all of this :/ still, 256/512 descriptors seem to work the best.
> Happy to let you log into the machine and fiddle around if you want :)
I think you need to ktr the packet processing time. Standard gigabit
max at ~1488095
On Sat, 5 Jul 2008, Paul wrote:
ULE + PREEMPTION for non SMP no major differences with SMP with ULE/4BSD and
preemption ON/OFF
32 bit UP test coming up with new cpu and I'm installing dragonfly sometime
this weekend :] UP: 1mpps in one direction with no firewall/no routing table
is not too
