All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Alewijnse <scarfboy@gmail.com>
To: netdev@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: gigabit trouble
Date: Tue, 3 Aug 2004 14:32:07 +0200	[thread overview]
Message-ID: <b71082d804080305322753a703@mail.gmail.com> (raw)
In-Reply-To: <20040803094842.B4911@electric-eye.fr.zoreil.com>

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

Quite simply a 'netio -s' on one computer, and a 'netio -u
192.168.1.whichever' on the other.  I was monitoring with 'vmstat 1'
for hardware stuff and bmon to see the actual speed and had a ssh
open.

The things I've been fiddling with recently to see if it'd make a difference:
- Renicing of ksoftirqc to anything between -5 and -17, I don't
remember exactly.
- Disabling tcp window scaling. I read somewhere that that may help
throughhput, but it may be a stupid move.
- Some barely thought about (I did read the following:
http://lists.samba.org/archive/samba/2003-December/077198.html)
window memory buffer size changes, with a 'so that that at least won't
be a bottleneck' angle:
--------------------
echo 400000 > /proc/sys/net/core/wmem_default
echo 512000 > /proc/sys/net/core/wmem_max
echo 400000 > /proc/sys/net/core/rmem_default
echo 512000 > /proc/sys/net/core/rmem_max
echo 98304 512000 640000 > /proc/sys/net/ipv4/tcp_mem
echo 98304 512000 640000 > /proc/sys/net/ipv4/tcp_wmem
echo 98304 512000 640000 > /proc/sys/net/ipv4/tcp_rmem
echo 98304 512000 640000 > /proc/sys/net/ipv4/tcp_mem
-----------


It seems that windows (in which I have jumbo frames on) doesn' quite
need as many interrupts, although I'm not sure that was for the same
speed, as I had another kernel panic (attached, this one has a small
visible trace). I was running the windows version of netio as a
server, and doing a client test with udp.

--Bart Alewijnse

[-- Attachment #2: panic3.gif --]
[-- Type: image/gif, Size: 95552 bytes --]

  reply	other threads:[~2004-08-03 12:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-29 16:45 gigabit trouble Bart Alewijnse
2004-07-29 17:29 ` Erik Mouw
2004-07-29 19:04 ` Francois Romieu
2004-07-29 22:41   ` Bart Alewijnse
2004-07-30 15:15     ` Bart Alewijnse
2004-07-30 18:54       ` Francois Romieu
2004-07-30 21:03         ` Bart Alewijnse
2004-07-30 21:41           ` Francois Romieu
2004-07-31 19:51             ` Bart Alewijnse
2004-07-31 21:18               ` Francois Romieu
2004-08-01 19:03                 ` Bart Alewijnse
2004-08-03  2:47                   ` Bart Alewijnse
2004-08-03  7:48                     ` Francois Romieu
2004-08-03 12:32                       ` Bart Alewijnse [this message]
2004-07-30 15:35     ` Bart Alewijnse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b71082d804080305322753a703@mail.gmail.com \
    --to=scarfboy@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.