On Tue, Oct 02, 2007 at 08:46:43PM +0100, Tony Sarendal wrote:
On 9/27/07, Tony Sarendal [EMAIL PROTECTED] wrote:
On 9/27/07, Claudio Jeker [EMAIL PROTECTED] wrote:
...
I hooked up the X4100 to one of our testers and ran some basic tests just to
get
familiar with the tester.
I put
On 10/3/07, Claudio Jeker [EMAIL PROTECTED] wrote:
On Tue, Oct 02, 2007 at 08:46:43PM +0100, Tony Sarendal wrote:
On 9/27/07, Tony Sarendal [EMAIL PROTECTED] wrote:
On 9/27/07, Claudio Jeker [EMAIL PROTECTED] wrote:
...
I hooked up the X4100 to one of our testers and ran some
Claudio Jeker wrote:
Could you add the dmesg of the test box to the website?
Do you have any other network cards you could test? (I'm mostly interested
in bnx but sk, msk, bge and nfe could be interesting as well).
This box if the M2 version also come with nfe cards as well, but there
is
On 10/3/07, Daniel Ouellet [EMAIL PROTECTED] wrote:
Claudio Jeker wrote:
Could you add the dmesg of the test box to the website?
Do you have any other network cards you could test? (I'm mostly
interested
in bnx but sk, msk, bge and nfe could be interesting as well).
This box if the M2
Tony Sarendal wrote:
On 10/3/07, *Daniel Ouellet* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Claudio Jeker wrote:
Could you add the dmesg of the test box to the website?
Do you have any other network cards you could test? (I'm mostly
interested
in bnx but
New set of tests done with AMD64 UP kernel.
http://www.layer17.net/openbsd-router-intro.html
/Tony
On 9/27/07, Tony Sarendal [EMAIL PROTECTED] wrote:
On 9/27/07, Claudio Jeker [EMAIL PROTECTED] wrote:
On Thu, Sep 27, 2007 at 09:54:00AM +0100, Tony Sarendal wrote:
On 9/27/07, Henning Brauer [EMAIL PROTECTED] wrote:
* Tony Sarendal [EMAIL PROTECTED] [2007-09-27 10:36]:
On
On 9/26/07, Stuart Henderson [EMAIL PROTECTED] wrote:
On 2007/09/26 13:50, rezidue wrote:
Order a 4.2 CD and install it as soon as you get it. 4.2 removed
many
bottlenecks in the network stack. In the meanwhile check out for
the ip
ifq len:
# sysctl net.inet.ip.ifq
I decided to pump up maxlen to 8192 to see what would happen and I thought
it actually has stopped the drops. Unfortunately I was under the impression
they had stopped when I believe this was causing the count to not increase:
WARNING: mclpool limit reached; increase kern.maxclusters
I've
On 9/26/07, Tom Bombadil [EMAIL PROTECTED] wrote:
net.inet.ip.ifq.maxlen defines how many packets can be queued in the IP
input queue before further packets are dropped. Packets comming from the
network card are first put into this queue and the actuall IP packet
processing is done later.
* Tony Sarendal [EMAIL PROTECTED] [2007-09-27 10:36]:
On 9/26/07, Tom Bombadil [EMAIL PROTECTED] wrote:
net.inet.ip.ifq.maxlen defines how many packets can be queued in the IP
input queue before further packets are dropped. Packets comming from the
network card are first put into this
On 9/27/07, Henning Brauer [EMAIL PROTECTED] wrote:
* Tony Sarendal [EMAIL PROTECTED] [2007-09-27 10:36]:
On 9/26/07, Tom Bombadil [EMAIL PROTECTED] wrote:
net.inet.ip.ifq.maxlen defines how many packets can be queued in the
IP
input queue before further packets are dropped. Packets
* Tony Sarendal [EMAIL PROTECTED] [2007-09-27 10:59]:
I meant if the input queue length was per physical or logical interface.
neither. there is one per protocol. i. e. typically two (inet and
inet6).
--
Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED]
BS Web Services, http://bsws.de
On 9/27/07, Henning Brauer [EMAIL PROTECTED] wrote:
* Tony Sarendal [EMAIL PROTECTED] [2007-09-27 10:59]:
I meant if the input queue length was per physical or logical interface.
neither. there is one per protocol. i. e. typically two (inet and
inet6).
Very good. My preconfigured
On Thu, Sep 27, 2007 at 09:54:00AM +0100, Tony Sarendal wrote:
On 9/27/07, Henning Brauer [EMAIL PROTECTED] wrote:
* Tony Sarendal [EMAIL PROTECTED] [2007-09-27 10:36]:
On 9/26/07, Tom Bombadil [EMAIL PROTECTED] wrote:
net.inet.ip.ifq.maxlen defines how many packets can be queued in
On 9/27/07, Claudio Jeker [EMAIL PROTECTED] wrote:
On Thu, Sep 27, 2007 at 09:54:00AM +0100, Tony Sarendal wrote:
On 9/27/07, Henning Brauer [EMAIL PROTECTED] wrote:
* Tony Sarendal [EMAIL PROTECTED] [2007-09-27 10:36]:
On 9/26/07, Tom Bombadil [EMAIL PROTECTED] wrote:
What have you looked at? are you running pf? what kind of ruleset?
Tried simplifying it?
--Bryan
On 9/25/07, rezidue [EMAIL PROTECTED] wrote:
I've been having problems with throughput on a box I'm using as an edge
gateway. I can't seem to get it to push out more than 150Mb/sec at about
20k
On Tue, Sep 25, 2007 at 11:57:37PM -0500, rezidue wrote:
I've been having problems with throughput on a box I'm using as an edge
gateway. I can't seem to get it to push out more than 150Mb/sec at about
20k pps. It's a Tyan Thunder K8SR (S2881) board that has two gig broadcom
interfaces on a
On 2007/09/25 23:57, rezidue wrote:
I've been having problems with throughput on a box I'm using as an edge
gateway.
dmesg and vmstat -i might give clues. Also try bsd.mp if you use
bsd (or vice-versa), and Claudio's suggestion of 4.2 is a good one.
Hi Claudio...
What does 'net.inet.ip.ifq.maxlen=256' do for us?
Tried a few 'man', and a few google searches and I wasn't very
successful. Found tons of other posts telling ppl to bump up that
sysctl, but never found what it does exactly.
Cheers,
g.
On Wed, Sep 26, 2007 at 10:48:02AM -0700, Tom Bombadil wrote:
Hi Claudio...
What does 'net.inet.ip.ifq.maxlen=256' do for us?
Tried a few 'man', and a few google searches and I wasn't very
successful. Found tons of other posts telling ppl to bump up that
sysctl, but never found what it
On 2007/09/26 10:48, Tom Bombadil wrote:
What does 'net.inet.ip.ifq.maxlen=256' do for us?
try http://archive.openbsd.nu/?ml=openbsd-techa=2006-10t=2474666
net.inet.ip.ifq.maxlen defines how many packets can be queued in the IP
input queue before further packets are dropped. Packets comming from the
network card are first put into this queue and the actuall IP packet
processing is done later. Gigabit cards with interrupt mitigation may spit
out
Hopefully this makes it through , I've been trying to post comments all day
but they don't seem to make it here.
To Bryan, I wasn't running pf originally when I noticed this problem but I
am now just to block ssh from the outside. I've disabled and re-enabled pf
to see if it affects throughput
For some reason I can't seem to reply to the earlier responses. Hopefully
this gets through.
On 9/26/07, Bryan Irvine [EMAIL PROTECTED] wrote:
What have you looked at? are you running pf? what kind of ruleset?
Tried simplifying it?
--Bryan
I wasn't running pf originally when I
rezidue wrote:
kern.version=OpenBSD 4.0-stable (GENERIC.MP) #0: Thu Mar 15 07:28:19 CST
Just for the hell of it, try running GENERIC, instead of GENERIC.MP.
--Toby.
On 2007/09/26 13:50, rezidue wrote:
Order a 4.2 CD and install it as soon as you get it. 4.2 removed many
bottlenecks in the network stack. In the meanwhile check out for the ip
ifq len:
# sysctl net.inet.ip.ifq
net.inet.ip.ifq.len=0
net.inet.ip.ifq.maxlen=256
I've been having problems with throughput on a box I'm using as an edge
gateway. I can't seem to get it to push out more than 150Mb/sec at about
20k pps. It's a Tyan Thunder K8SR (S2881) board that has two gig broadcom
interfaces on a shared pci-x bus. It's on the bcm5704c chipset and I'm
On Wed, Feb 21, 2007 at 09:39:56AM +0200, Paul Irofti wrote:
I'll send a new dmesg and notify if anything has changed when I get
back.
Got back, it was the graphics card not the mobo, but I did ask him to
test my NIC too and he said it ran just fine (of course I asked for a
specific duplex
Strange, the dmesg I submitted (and the one dmesg shows:) both point to
my configuration before the snapshot update. But the login informs me
that I'm running ``OpenBSD 4.1-beta (GENERIC) #847'' and uname says the
same:
$ uname -rsv
OpenBSD 4.1 GENERIC#847
I've received a new mobo with a vr(4) NIC. Ever since I installed it I'm
getting very slow transfer speeds (i.e. from 7-8 mb/s to 0.3-0.4 mb/s).
I've googled and stfa and found some complaints on the freebsd mailing
lists but wasn't able to find a solution. Is this a known bug? Should I
just buy
On Tue, Feb 20, 2007 at 11:00:07PM +0200, Paul Irofti wrote:
Strange, the dmesg I submitted (and the one dmesg shows:) both point to
my configuration before the snapshot update. But the login informs me
that I'm running ``OpenBSD 4.1-beta (GENERIC) #847'' and uname says the
same:
$ uname
Paul Irofti wrote:
On Tue, Feb 20, 2007 at 11:00:07PM +0200, Paul Irofti wrote:
Strange, the dmesg I submitted (and the one dmesg shows:) both point to
my configuration before the snapshot update. But the login informs me
that I'm running ``OpenBSD 4.1-beta (GENERIC) #847'' and uname says the
On Tue, Feb 20, 2007 at 09:59:49PM -0500, Nick Holland wrote:
First of all, regarding your dmesg: that's a feature, not a bug. The
system attempts to store multiple dmesgs in RAM and keep them after a
reboot. This can be very handy at times, but disconcerting to those
not expecting it. The
34 matches
Mail list logo
