public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* gigabit trouble
@ 2004-07-29 16:45 Bart Alewijnse
  2004-07-29 17:29 ` Erik Mouw
  2004-07-29 19:04 ` Francois Romieu
  0 siblings, 2 replies; 11+ messages in thread
From: Bart Alewijnse @ 2004-07-29 16:45 UTC (permalink / raw)
  To: linux-kernel

I just bought two rtl8169 cards, and am having a little trouble.

Setup: 
--
Old computer: Celeron 400, 8139 nic, 8169 nic
New computer: XP 1700, 8139 nic, 8169 nic

The 8139 (100mbit)'s are for internet access, their wires head out to
the switch - the gbit is purely point to point and uses a private
network. (192.168 etc)

I run gentoo on both, which until yesterday was 2.6.7-ck5 (on both),
and currently run 2.6.7-mm6 (again, both), as I saw the suggestion
somewhere it had better support for the card - something about a new
net card inferface that's nicer to interrupts.
--


There's a speed increase, from ~4mb in samba and ~6mb in nfs on my
100mbit cards to a more hard drive flutter limited ~8 to 10.5MB/s on
both.

First problem - that sounds suspiciously like it's hanging around the
100mbit limit. I've squeezed a cable the way
http://www.sql-server-performance.com/jc_gigabit.asp
suggests, and when I run my new computer under winXP, it reports the
link speed as 1gbit; also, it's using the gbit cards for transfer,
I've yanked cables to test.

So, question one - how do I see the link speed under linux, and how,
if at all, do I control it?

(Plus possibly - what's the name of a good non-service direct-network
throughput tester, preferable one that also runs on windows)




Second problem - when doing speed tests (dd if=mounted_remote_nfs file
of=local_dev_null bs=10M or the like) my new computer makes funny
noises when doing a 10MB/s transfer. The sound seems to come from the
power supply, of all things. It's a 450watt, which is 100W more than
was previously enough; and I'm temporarily using an ancient TNT for a
vid card. It's not power amount, though possibly power purity and
distribution; it was a relatively cheap power supply. (But then again
- that shouldn't have -this- effect, should it?)

Disturbingly, in such a linux-to-linux speed test, my new computer
froze.As in, in text mode, have the screen freeze and apparently be
half written full of nonsense.

Whereas my old computer, which was doing the exact same thing except
it was sending (and remember, this computer is about a third the cpu
speed) said 10MB/s, lived happily.

What's even stranger is that I don't have this problem - noise or
freezing - when I run my new computer in winXP, where I get
approximately the same speed.

It can't be the power supply as winxp works on the same system and setup;
it can't be a simple case of driver trouble, as the old computer works
with the same driver and card.

The only thing I can think of is my motherboard - it's given me pci
transfer troubles before; I have to hit an exact permutation of
inserted cards to have, say, my sound, network and tv card work
simultaneously in winxp -or- linux. But even that's not the exact
problem right now, as it's the same hardware setup that froze linux
but not xp.

So, question two - what possibly happened there?  Is this a
driver/motherboard coincidence and therefore quite doomed?

Quite frankly, I'm stumped. Any suggestions are welcome.


--Bart Alewijnse

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: gigabit trouble
  2004-07-29 16:45 gigabit trouble Bart Alewijnse
@ 2004-07-29 17:29 ` Erik Mouw
  2004-07-29 19:04 ` Francois Romieu
  1 sibling, 0 replies; 11+ messages in thread
From: Erik Mouw @ 2004-07-29 17:29 UTC (permalink / raw)
  To: Bart Alewijnse; +Cc: linux-kernel

On Thu, Jul 29, 2004 at 06:45:35PM +0200, Bart Alewijnse wrote:
> I just bought two rtl8169 cards, and am having a little trouble.

(Side note: don't know what an rtl8169 costs today, but I'd rather buy
an Intel gigE desktop adapter. Card/driver combination just works
great, no hassle at all.)

> Setup: 
> --
> Old computer: Celeron 400, 8139 nic, 8169 nic
> New computer: XP 1700, 8139 nic, 8169 nic

[...]

> There's a speed increase, from ~4mb in samba and ~6mb in nfs on my
> 100mbit cards to a more hard drive flutter limited ~8 to 10.5MB/s on
> both.

Not spectecular. Even with that kind of hardware you should be able to
do around 20MB/s for NFS (depending on hard drive, of course).

> First problem - that sounds suspiciously like it's hanging around the
> 100mbit limit. I've squeezed a cable the way
> http://www.sql-server-performance.com/jc_gigabit.asp
> suggests, and when I run my new computer under winXP, it reports the
> link speed as 1gbit; also, it's using the gbit cards for transfer,
> I've yanked cables to test.

Gig-ethernet can be a bit picky about cable quality. If the quality is
too low, it will go back too fast ethernet pergormance. Get a straight
Cat 5E cable (i.e.: no cross cable) from your local computershop, that
should just do. Cat 5 usually also works, but is not certified for
gig-ethernet speeds (usually works, if not, use Cat 5E).

> So, question one - how do I see the link speed under linux, and how,
> if at all, do I control it?

Mii-tool or eth-tool.

> Second problem - when doing speed tests (dd if=mounted_remote_nfs file
> of=local_dev_null bs=10M or the like) my new computer makes funny
> noises when doing a 10MB/s transfer. The sound seems to come from the
> power supply, of all things. It's a 450watt, which is 100W more than
> was previously enough; and I'm temporarily using an ancient TNT for a
> vid card. It's not power amount, though possibly power purity and
> distribution; it was a relatively cheap power supply. (But then again
> - that shouldn't have -this- effect, should it?)

I think you're hearing interrupts. Especially with the normal 1500
bytes ethernet MTU and no NAPI, gig-ethernet can send quite some
packets which on their turn will generate quite some interrupts, which
will cause the CPU to do something, which on its turn will cause the
PSU have to put out more power, which you will be able to hear.

> Disturbingly, in such a linux-to-linux speed test, my new computer
> froze.As in, in text mode, have the screen freeze and apparently be
> half written full of nonsense.

What you describe as "nonsense" is most probably a kernel Oops.
Developers are interested in such Oopses, so please mail them to this
mailing list.

> Whereas my old computer, which was doing the exact same thing except
> it was sending (and remember, this computer is about a third the cpu
> speed) said 10MB/s, lived happily.

Different CPU, different compiler flags, different timings, different
things to do. Might be sheer coincidence.

> What's even stranger is that I don't have this problem - noise or
> freezing - when I run my new computer in winXP, where I get
> approximately the same speed.
> 
> It can't be the power supply as winxp works on the same system and setup;
> it can't be a simple case of driver trouble, as the old computer works
> with the same driver and card.

It's not the first time Linux triggers hardware bugs where Windows
doesn't.

> The only thing I can think of is my motherboard - it's given me pci
> transfer troubles before; I have to hit an exact permutation of
> inserted cards to have, say, my sound, network and tv card work
> simultaneously in winxp -or- linux. But even that's not the exact
> problem right now, as it's the same hardware setup that froze linux
> but not xp.

Narrow down the problem. Get out all cards you don't need to reproduce
the problem and try to break the system again.

> So, question two - what possibly happened there?  Is this a
> driver/motherboard coincidence and therefore quite doomed?

No idea, not enough information to tell. See the file REPORTING-BUGS in
your kernel tree and provide more information.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: gigabit trouble
  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
  1 sibling, 1 reply; 11+ messages in thread
From: Francois Romieu @ 2004-07-29 19:04 UTC (permalink / raw)
  To: Bart Alewijnse; +Cc: linux-kernel

Bart Alewijnse <scarfboy@gmail.com> :
[...]
> I run gentoo on both, which until yesterday was 2.6.7-ck5 (on both),
> and currently run 2.6.7-mm6 (again, both), as I saw the suggestion
> somewhere it had better support for the card - something about a new
> net card inferface that's nicer to interrupts.

NAPI support for r8169 is available in recent -mm kernel and there is
a small (though noticeable) optimization wrt to interrupt disabling.

[...]
> So, question one - how do I see the link speed under linux, and how,
> if at all, do I control it?

ethtool

[...]
> Disturbingly, in such a linux-to-linux speed test, my new computer
> froze.As in, in text mode, have the screen freeze and apparently be
> half written full of nonsense.

These messages would be welcome (pen/paper/serial line/image/log file
or whatever).

[...]
> So, question two - what possibly happened there?  Is this a
> driver/motherboard coincidence and therefore quite doomed?
> 
> Quite frankly, I'm stumped. Any suggestions are welcome.

Please provide:
- complete dmesg log from boot up to the point where the card can 
  trnasmit and receive (please check in your log file if the output of
  'dmesg' is truncated)
- cat /proc/interrupts once the card is up
- /sbin/lspci -vx
- /sbin/lsmod

If you have any binary module loaded, please reproduce the issue with
a kernel wherein they have not been loaded.

If you believe that it could be related to hardware, you may want to
run a complete memtest to rule out memory issues.

Reply-to: set to netdev@oss.sgi.com.

--
Ueimor

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: gigabit trouble
  2004-07-29 19:04 ` Francois Romieu
@ 2004-07-29 22:41   ` Bart Alewijnse
  2004-07-30 15:35     ` Bart Alewijnse
       [not found]     ` <b71082d804073008157cf1d6c0@mail.gmail.com>
  0 siblings, 2 replies; 11+ messages in thread
From: Bart Alewijnse @ 2004-07-29 22:41 UTC (permalink / raw)
  To: netdev; +Cc: linux-kernel

I was going to do an exhaustive test, but because my computer stopped
running completely, I'll reply to the one or two bits I can now.

On Thu, 29 Jul 2004 21:04:01 +0200, Francois Romieu
<romieu@fr.zoreil.com> wrote:
> Bart Alewijnse <scarfboy@gmail.com> :
> [...]
> > I run gentoo on both, which until yesterday was 2.6.7-ck5 (on both),
> > and currently run 2.6.7-mm6 (again, both), as I saw the suggestion
> > somewhere it had better support for the card - something about a new
> > net card inferface that's nicer to interrupts.
> 
> NAPI support for r8169 is available in recent -mm kernel and there is
> a small (though noticeable) optimization wrt to interrupt disabling.
Well, I noticed a max of 6500 interrupts/s on eth1 on both computers, with or
without napi - and that 6500 is also the figure of packets per second.
So I'm slightly dubious. (notice 6500 *1500 bytes is about 10MB/s)

> [...]
> > So, question one - how do I see the link speed under linux, and how,
> > if at all, do I control it?
> 
> ethtool
Thanks. That wasn't the problem - the line speed's a gbit.

> [...]
> > Disturbingly, in such a linux-to-linux speed test, my new computer
> > froze.As in, in text mode, have the screen freeze and apparently be
> > half written full of nonsense.
> 
> These messages would be welcome (pen/paper/serial line/image/log file
> or whatever).

No messages, no oops, no log messages that I noticed. 
It was video memory corruption in text mode.

As to the rest, I'll do it when I revive my computer. Right now, I'm
thinking the power supply may be dodgy. I'll see if I can get
a minimum to run off my even older 235Watt. But as a note,
with two cards, two cdroms and a hard drive less, it was still
making the noise. I think it still is now, but since no OS actually
boots completely right now, I can't say for sure.
I'll do a memtest, that makes sense.

--Bart

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: gigabit trouble
  2004-07-29 22:41   ` Bart Alewijnse
@ 2004-07-30 15:35     ` Bart Alewijnse
       [not found]     ` <b71082d804073008157cf1d6c0@mail.gmail.com>
  1 sibling, 0 replies; 11+ messages in thread
From: Bart Alewijnse @ 2004-07-30 15:35 UTC (permalink / raw)
  To: linux-kernel

(I am a moron, and gmail isn't helping. I keep sending this stuff to
people, not the list. Sorry.)


On Fri, 30 Jul 2004 00:41:03 +0200, Bart Alewijnse <scarfboy@gmail.com> wrote:
> I was going to do an exhaustive test, but because my computer stopped
> running completely, I'll reply to the one or two bits I can now.

...which was unrelated. Although I can't get the noise anymore
now either. I'm not too happy, I like my problems reproducable.
Of course, in the course of tring to fix the nonbootability, I changed
a bunch of things. Hrm.
I'll try getting it back later.

> > > So, question one - how do I see the link speed under linux, and how,
> > > if at all, do I control it?
> >
> > ethtool
> Thanks. That wasn't the problem - the line speed's a gbit.

Definately. I've now seen speeds up to 22MB/s, but only in pure
network benching (netio), and only with udp, although I guess
that makes a some sense.

(Also, for some reason it makes a respectable difference which
computer I run the netio server on. I mean, netio measures
speed both ways on one run, and it's different depending on
where I run it. I guess that suggests io limiting)

So the hanging around ten MB/s was just coincidence - it still
does it in both nfs and samba, but I guess it's io limited
*somewhere*, but trying to figure out why doesn't belong
in this list, I guess. Or maybe it does; I've always wondered
why samba hangs around 3, 4, 5, maybe 6 MB/s on a 100mbit
link - which with netio shows that it can go at 11MB/s, its full
speed - and even nfs rarely tops above eight. On my friend's
setup too, and he *does* have respectable hardware in his
server:)

I assume the 20MB/s top speed on my gbit cards is io limiting,
and possibly the fact that they're 32bit cards in 33mhz slots.
Still, it's far from impressive. Any suggestions (on where to
go) about improving it?

Anyhow, thanks for the help so far.

--Bart Alewijnse

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: gigabit trouble
       [not found]       ` <20040730205412.A15669@electric-eye.fr.zoreil.com>
@ 2004-07-30 21:03         ` Bart Alewijnse
  2004-07-30 21:41           ` Francois Romieu
  0 siblings, 1 reply; 11+ messages in thread
From: Bart Alewijnse @ 2004-07-30 21:03 UTC (permalink / raw)
  To: Francois Romieu; +Cc: netdev, linux-kernel

You are aware that this is a celeron at 400 mhz, and not whatever 400
is or possibly isn't in that annoying new naming scheme? (Just
checking...)

Both systems are not overclocked, so are stable in that respect. The
nonbooting thing was a loose ground wire touching my hard drive
jumpers, making it think it was a slave. I'm surprised winxp managed
to do anything at all. I've used both these systems for ages, never
had any real trouble except for the strange pci slot/irq problems in
my new computer, but that was mostly a work-or-not thing - although it
also increases pci latency. I'm still not sure whether it's a card
that's in there, a card that was in there, (I replaced my sound card,
and can suddently get a much lower midi-to-wave playing latency - but
the sound card has been known to click and pop randomly over several
reconfigurations the last few days) or just a screwy motherboard. I
should hope it's not the last, it's a brand board.

Anyhow, on transmit from the celeron box, under extreme benchy
circumstrances, I've seen it around 16Kints/s on transmit and 13k on
receive. But under everyday nfs/samba, 6400 is about the best it does
either way.

The maximum amount of interrupts/s I've seen so far 22302 (including
the 1000 in the kernel timer, 'course). Nothing much else changes,
except the context switches raising from an idle 10~30 to 1000~1500
to, sometimes 30000. Actually, using netio seems to busy the system
completely:

# top -d 0.5 | grep Cpu\(
Cpu(s):  8.8% us, 36.8% sy,  0.0% ni,  1.5% id,  0.0% wa, 13.2% hi, 39.7% si
Cpu(s):  7.5% us, 38.8% sy,  0.0% ni,  0.0% id,  0.0% wa, 14.9% hi, 38.8% si
Cpu(s):  5.7% us, 41.4% sy,  0.0% ni,  0.0% id,  0.0% wa, 14.9% hi, 37.9% si
Cpu(s):  5.0% us, 44.0% sy,  0.0% ni,  0.0% id,  0.0% wa, 14.5% hi, 36.5% si
Cpu(s):  4.4% us, 50.5% sy,  0.0% ni,  1.1% id,  0.0% wa, 12.1% hi, 31.9% si
Cpu(s):  3.8% us, 50.9% sy,  0.0% ni,  0.0% id,  0.0% wa, 17.0% hi, 28.3% si

But a to-winxp smb file transfer, hangin around 7, 8MB/s, doesn't:
Cpu(s):  3.8% us, 50.0% sy,  0.0% ni, 17.9% id,  0.0% wa,  7.5% hi, 20.8% si
Cpu(s):  5.0% us, 43.0% sy,  0.0% ni, 27.0% id,  0.0% wa,  7.0% hi, 18.0% si
Cpu(s):  4.8% us, 40.4% sy,  0.0% ni, 29.8% id,  0.0% wa,  5.8% hi, 19.2% si
Cpu(s):  5.1% us, 43.9% sy,  0.0% ni, 26.5% id,  0.0% wa,  5.1% hi, 19.4% si
Cpu(s):  5.3% us, 42.5% sy,  0.0% ni, 26.5% id,  0.0% wa,  6.2% hi, 19.5% si
Cpu(s):  5.9% us, 43.1% sy,  0.0% ni, 25.5% id,  1.0% wa,  5.9% hi, 18.6% si
Cpu(s):  4.6% us, 41.7% sy,  0.0% ni, 25.9% id,  0.0% wa,  5.6% hi, 22.2% si
Cpu(s):  6.2% us, 44.6% sy,  0.0% ni, 23.2% id,  0.0% wa,  5.4% hi, 20.5% si
Cpu(s):  4.2% us, 34.7% sy,  0.0% ni, 38.9% id,  0.0% wa,  5.3% hi, 16.8% si

It's not too consistent all over either; windows netio transmits
slowly when packet sizes are >1k (the mtu?), as low as 5MB/s, while
the receive speed for the same packet size goes at ~22MB


Ooh, finally, a proper kernel pan --er, bug, it says. On my old
computer this time.
I know, incidentally, that the memory works; I recently did a three-hour memtest
on this computer. Picture here:
http://www.scarfboy.com/other/panic-30jul.gif

This may be due to fiddling with said wmem, etc values, I set some of them
considerably larger. I did get a few percent apparent speed increase,
incidentally, though that may have been wishful thinking.

I guess I should try >= 2.6.8-rc2-mm1 next?

--Bart Alewijnse

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: gigabit trouble
  2004-07-30 21:03         ` Bart Alewijnse
@ 2004-07-30 21:41           ` Francois Romieu
  2004-07-31 19:51             ` Bart Alewijnse
  0 siblings, 1 reply; 11+ messages in thread
From: Francois Romieu @ 2004-07-30 21:41 UTC (permalink / raw)
  To: Bart Alewijnse; +Cc: netdev, linux-kernel

Bart Alewijnse <scarfboy@gmail.com> :
> You are aware that this is a celeron at 400 mhz, and not whatever 400
> is or possibly isn't in that annoying new naming scheme? (Just
> checking...)

Yes. It is good enough to handle some network traffic.

[...]
> Anyhow, on transmit from the celeron box, under extreme benchy
> circumstrances, I've seen it around 16Kints/s on transmit and 13k on
> receive. But under everyday nfs/samba, 6400 is about the best it does
> either way.

The figures does not seem bad.

I am curious: which chipset does the motherboard include ?
An 'lspci -vx' sums it quite well.

[...]
> This may be due to fiddling with said wmem, etc values, I set some of them

It should not.

> considerably larger. I did get a few percent apparent speed increase,
> incidentally, though that may have been wishful thinking.
> 
> I guess I should try >= 2.6.8-rc2-mm1 next?

Please. Do not compile in preempt/ipv6/smp. SMP is supposed to be safe
but you do not need it and it will not make your r8169 faster if you have
only one CPU. I'd welcome a 'vmstat 1' output as it gives the bi/bo.

--
Ueimor

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: gigabit trouble
  2004-07-30 21:41           ` Francois Romieu
@ 2004-07-31 19:51             ` Bart Alewijnse
  2004-07-31 21:18               ` Francois Romieu
  0 siblings, 1 reply; 11+ messages in thread
From: Bart Alewijnse @ 2004-07-31 19:51 UTC (permalink / raw)
  To: netdev, linux-kernel

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

On Fri, 30 Jul 2004 23:41:20 +0200, Francois Romieu
<romieu@fr.zoreil.com> wrote:
> [...]
> > Anyhow, on transmit from the celeron box, under extreme benchy
> > circumstrances, I've seen it around 16Kints/s on transmit and 13k on
> > receive. But under everyday nfs/samba, 6400 is about the best it does
> > either way.
> 
> The figures does not seem bad.
Except they're about a factor 1.2 to 1.7 faster than my 100mbit, in practical
(network filesystem) application. That's very short of spectacular.

> I am curious: which chipset does the motherboard include ?
> An 'lspci -vx' sums it quite well.
Ermm... VIA, I believe it was called Apollo Pro. VT82C693.
But as the rest may matter, the full lspci -vx listing's attached.

> [...]
> > This may be due to fiddling with said wmem, etc values, I set some of them
> It should not.
If my computer did what it should do, would I be here?:)

> > considerably larger. I did get a few percent apparent speed increase,
> > incidentally, though that may have been wishful thinking.
> >
> > I guess I should try >= 2.6.8-rc2-mm1 next?
> 
> Please. Do not compile in preempt/ipv6/smp. SMP is supposed to be safe
> but you do not need it and it will not make your r8169 faster if you have
> only one CPU. I'd welcome a 'vmstat 1' output as it gives the bi/bo.
ipv6 was nonsense anyhow (and I think loaded as a module), smp was force
of habit as something kernely ages back wanted it. But is there really no
point to preempting in a server?

Right, both computers now run 2.6.8-rc2-mm1. It's better. Roughly
speaking, the top *benchmark* speeds, rouding slightly up, are:
udp: 33MB/s (using ~26Kints) one way, 12MB/s (9Kints/s) the other, 
tcp: 22MB/s (16Kints)one way, 12MB/s (9Kints/s) the other. 

(The 9Kints ca be 12 when the packet size is 1K or 2K)

Oddly enough, the slow direction is sending from my new computer
(XP1700, KT333, 1GB ram) to my old (both running linux and the
mentioned kernel). I'm fairly sure this is due to the fact that my
asus motherboard is crap, and I guess I'll have to settle for it,
unless one of you is very good at black magic. Because trust me, the
way hardware and chooses not to work, apparently based on slots and/or
irq's is just *weird*. Bah.

Practical speeds increased far less dramatically. nfs now sustains at
10MB/s, with the occasional 12. Samba increased less, about half a meg
a second, it sustains speeds slightly over 8MB/s, to both linux and
windows.
I guess no network filesystems focuses on speed? I mean, I did always
wonder why nfs and samba on 100mbit transfers averaged around half the
line speed, and that's counting large files (no tcp startup to blame).

I don't suppose any of you know a good windows nfs client.

I guess I'll have to settle for this. I'm just annoyed that the 'giga'
is basically a joke,  especially on my setup.


--Bart Alewijnse

[-- Attachment #2: lspci-vx.txt --]
[-- Type: text/plain, Size: 3651 bytes --]

0000:00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev 06)
	Flags: bus master, medium devsel, latency 0
	Memory at dc000000 (32-bit, prefetchable)
	Capabilities: [a0] AGP version 1.0
00: 06 11 91 06 06 00 90 a2 06 00 00 06 00 00 00 00
10: 08 00 00 dc 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00

0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode])
	Flags: bus master, 66Mhz, medium devsel, latency 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
00: 06 11 98 85 07 00 20 22 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 00 00
20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00

0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South] (rev 11)
	Subsystem: VIA Technologies, Inc. VT82C596/A/B PCI to ISA Bridge
	Flags: bus master, stepping, medium devsel, latency 0
00: 06 11 96 05 87 00 00 02 11 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
	Flags: bus master, medium devsel, latency 32
	I/O ports at e000 [size=16]
00: 06 11 71 05 07 00 80 02 06 8a 01 01 00 20 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00

0000:00:07.3 Host bridge: VIA Technologies, Inc. VT82C596 Power Management (rev 20)
	Flags: medium devsel
00: 06 11 51 30 00 00 80 02 20 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

0000:00:09.0 VGA compatible controller: S3 Inc. 86c325 [ViRGE] (rev 06) (prog-if 00 [VGA])
	Flags: bus master, medium devsel, latency 32, IRQ 15
	Memory at d8000000 (32-bit, non-prefetchable)
00: 33 53 31 56 07 00 00 02 06 00 00 03 00 20 00 00
10: 00 00 00 d8 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0f 01 04 ff

0000:00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
	Subsystem: Realtek Semiconductor Co., Ltd. RT8139
	Flags: bus master, medium devsel, latency 32, IRQ 11
	I/O ports at e800
	Memory at df001000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [50] Power Management version 2
00: ec 10 39 81 07 00 90 02 10 00 00 02 00 20 00 00
10: 01 e8 00 00 00 10 00 df 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 39 81
30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 20 40

0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
	Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet
	Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 10
	I/O ports at ec00 [size=de000000]
	Memory at df000000 (32-bit, non-prefetchable) [size=256]
	Expansion ROM at 00010000 [disabled]
	Capabilities: [dc] Power Management version 2
00: ec 10 69 81 07 00 b0 02 10 00 00 02 08 20 00 00
10: 01 ec 00 00 00 00 00 df 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 69 81
30: 00 00 00 de dc 00 00 00 00 00 00 00 0a 01 20 40


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: gigabit trouble
  2004-07-31 19:51             ` Bart Alewijnse
@ 2004-07-31 21:18               ` Francois Romieu
  2004-08-01 19:03                 ` Bart Alewijnse
  0 siblings, 1 reply; 11+ messages in thread
From: Francois Romieu @ 2004-07-31 21:18 UTC (permalink / raw)
  To: Bart Alewijnse; +Cc: netdev, linux-kernel

Bart Alewijnse <scarfboy@gmail.com> :
[...]
> of habit as something kernely ages back wanted it. But is there really no
> point to preempting in a server?

I don't know: I have no URL for the figures at hand.

> Right, both computers now run 2.6.8-rc2-mm1. It's better. Roughly
> speaking, the top *benchmark* speeds, rouding slightly up, are:
> udp: 33MB/s (using ~26Kints) one way, 12MB/s (9Kints/s) the other, 
> tcp: 22MB/s (16Kints)one way, 12MB/s (9Kints/s) the other. 
> 
> (The 9Kints ca be 12 when the packet size is 1K or 2K)

Can you give a try to a napi version of the module (it is a compile-time
option) ?
You may want higher {r/w}mem_max as well as renicing ksoftirqd with
a strongly < 0 value on the celeron client.

> Oddly enough, the slow direction is sending from my new computer
> (XP1700, KT333, 1GB ram) to my old (both running linux and the
> mentioned kernel). I'm fairly sure this is due to the fact that my

The r8169 driver has been reported to be faster on Rx than on Tx so your
observation makes sense.

[...]
> I guess I'll have to settle for this. I'm just annoyed that the 'giga'
> is basically a joke,  especially on my setup.

It should be possible to make things slightly better for the celeron box
as a client. I'll cook up a patch.

Would you be kind enough to do some ftp transfer test where the celeron
box retrieves data and send the 'vmstat 1' output of the client during
the test ?

--
Ueimor

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: gigabit trouble
  2004-07-31 21:18               ` Francois Romieu
@ 2004-08-01 19:03                 ` Bart Alewijnse
       [not found]                   ` <b71082d804080219476103bd47@mail.gmail.com>
  0 siblings, 1 reply; 11+ messages in thread
From: Bart Alewijnse @ 2004-08-01 19:03 UTC (permalink / raw)
  To: netdev, linux-kernel

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

On Sat, 31 Jul 2004 23:18:36 +0200, Francois Romieu
<romieu@fr.zoreil.com> wrote:
> > Right, both computers now run 2.6.8-rc2-mm1. It's better. Roughly
> > speaking, the top *benchmark* speeds, rouding slightly up, are:
> > udp: 33MB/s (using ~26Kints) one way, 12MB/s (9Kints/s) the other,
> > tcp: 22MB/s (16Kints)one way, 12MB/s (9Kints/s) the other.
> >
> > (The 9Kints ca be 12 when the packet size is 1K or 2K)
> 
> Can you give a try to a napi version of the module (it is a compile-time
> option) ?
> You may want higher {r/w}mem_max as well as renicing ksoftirqd with
> a strongly < 0 value on the celeron client.
That's with NAPI on both. I notice r/wmem has an effect, but it's not much.
Although on my new computer it seems moot as there's something weird
going on with interrupts with my botherboard.

> > Oddly enough, the slow direction is sending from my new computer
> > (XP1700, KT333, 1GB ram) to my old (both running linux and the
> > mentioned kernel). I'm fairly sure this is due to the fact that my
> 
> The r8169 driver has been reported to be faster on Rx than on Tx so your
> observation makes sense.

How does that make sense? When one side receives, the other sends, hrm?
They're two identical cards, it should be entirely symmetrical assuming
equal hardware - not faster on the years older hardware.


> [...]
> > I guess I'll have to settle for this. I'm just annoyed that the 'giga'
> > is basically a joke,  especially on my setup.
> 
> It should be possible to make things slightly better for the celeron box
> as a client. I'll cook up a patch.

The celeron box is the server, that's the entire point. Anyhow, it's
much faster in transmission than my new computer right now due to said
mobo problem, so I *want* it as the server.


> Would you be kind enough to do some ftp transfer test where the celeron
> box retrieves data and send the 'vmstat 1' output of the client during
> the test ?

Sure, but I can tell you right now with reasonable certaintly that my
new computer
won't top 9000interrupts/sec, i.e. 9000 packets per second, and therefore do
the 12MB/s at most, and probably less; interruptwise, my new computer
is the bottleneck, and I'm guessing UDP is faster because TCP is
limited by the amount of packets, or in the other direction ACKs, it
can send per second.

Transfers to the celeron are a relatively pointless measure because
of my new computer being horribly interrupt limited at the moment. 
That may have started when I installed the gbit card, but mostly because it
disturbs the mobo's precious and unguessable hardware balance. I'll try figuring
out if I can solve it, but basically it just involves swapping around
cards until it
works better, so that'ld take a while.

Attached are the vmstats for an ftp and nfs transfer, as measured from
my old computer (the nfs and ftp server). Both were going at a pretty
low speed, sub-9000 packets; this may have to do with drive
fragmentation, my hard drives are rather full at the moment.

Also, the logs on the client (my new computer) while sending data to
my old one. These were made at a different time, and I believe the
transfer rate was better (6MB for ftp, 9MB for nfs) than for the
-to-old- logs, which were worse, and varied more.

--Bart

[-- Attachment #2: ftp-put-to-old-computer__lin-mm-to-lin-mm_larger --]
[-- Type: application/octet-stream, Size: 4268 bytes --]

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  0      0  48532  29648 175464    0    0   101    31  273   169 15  2 80  2
 0  0      0  48532  29648 175468    0    0     0     0 1007     9  0  1 99  0
 1  0      0  45796  29648 178212    0    0     0     0 2873    35  2 33 65  0
 1  0      0  39216  29648 184532    0    0     0     0 5131    36  7 76 17  0
 1  0      0  32820  29648 191348    0    0     0     0 4938    52  7 77 16  0
 0  1      0  28788  29908 195028    0    0     0  4628 3276    41  4 47 26 23
 1  1      0  24308  29908 199020    0    0     0  8656 4211    40  8 90  0  2
 1  0      0  20596  29908 202724    0    0     0  6500 3964   257  6 94  0  0
 1  0      0  13940  29908 209404    0    0     0     0 5994    14  8 92  0  0
 1  0      0   7216  29908 216116    0    0     0     8 5996    12  6 94  0  0
 1  0      0   2408  29840 221084    0    0     0     8 5931    28  8 92  0  0
 1  0      0   2856  29740 221320    0    0     0  1184 5574    51  5 95  0  0
 1  1      0   2536  30400 221400    0    0     0  6524 4886    90  6 94  0  0
 1  2      0   2856  30276 221580    0    0     0  7780 4279    73  7 93  0  0
 1  2      0   2408  30248 222368    0    0     0  6368 4251    73  5 95  0  0
 1  2      0   2244  29904 223260    0    0     0  6344 4952    68  6 94  0  0
 1  2      0   3116  29636 222960    0    0     0  5244 4163    81  8 92  0  0
 1  1      0   2472  29528 223968    0    0     0  5664 4731   101  7 93  0  0
 1  0      0   2920  29416 224020    0    0     0  1268 5124   194  6 94  0  0
 1  0      0   2984  29132 224628    0    0     0   636 5825    40  8 92  0  0
 1  0      0   2280  28944 225796    0    0     0  6668 4807    73  6 94  0  0
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 2  0      0   2260  28668 226352    0    0     0  3976 4973    77  7 93  0  0
 1  0      0   2408  28420 226664    0    0     0  5320 4514    96  6 94  0  0
 1  1      0   2664  28368 226480    0    0     0 19264 3261    44  6 94  0  0
 1  1      0   2476  28288 226732    0    0     0 16184 2124   252  7 93  0  0
 1  0      0   2920  28056 226968    0    0     0   536 3898    67  7 93  0  0
 1  0      0   2804  27696 227700    0    0     0     8 5863    53  6 94  0  0
 1  0      0   2984  27504 227928    0    0     0     8 5929    70  7 93  0  0
 1  0      0   2920  27008 228648    0    0     0     4 5949    53  9 91  0  0
 1  0      0   2408  26840 229468    0    0     0  1436 5543    50  6 94  0  0
 2  0      0   2792  26808 228560    0    0     0 35532 3685    46  8 92  0  0
 1  1      0   3064  26716 228916    0    0     0     0 2085   217  8 92  0  0
 1  0      0   2984  26520 229572    0    0     0   160 3751    69  6 94  0  0
 1  0      0   2536  26352 230324    0    0     0     8 5953    50  8 92  0  0
 1  0      0   2920  24116 232332    0    0     0     8 5894    53  7 93  0  0
 1  0      0   3048  22420 234180    0    0     0     4 5945    48  6 94  0  0
 1  0      0   3112  21064 235396    0    0     0  1348 5476    55  7 91  2  0
 1  1      0   1944  20572 236508    0    0     0 35652 3628    52  6 94  0  0
 0  2      0   2132  20056 237048    0    0  1064     0 1125   150  7 22  0 70
 1  1      0   3188  18984 236408    0    0   224     0 1077   108 61 10  0 29
 0  0      0   4616  18984 236408    0    0     0   144 1034    34  2  2 83 13
 0  0      0   4616  18984 236408    0    0     0     0 1006    10  0  0 100  0
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  0      0 178516  18984  63676    0    0     0     0 1009    12  0 33 67  0
 0  0      0 177572  20180  63680    0    0    48  1192 1033    73  1  4 70 25
 0  0      0 177572  20180  63680    0    0     0     0 1008    10  0  0 100  0
 0  0      0 177892  20216  63680    0    0     0  1124 1224    39  0  3 40 57
 0  0      0 177892  20216  63684    0    0     0     0 1067    13  0  1 85 14
 0  0      0 177892  20220  63688    0    0     8     0 1011    16  0  0 99  1

[-- Attachment #3: nfs-to-old-computer__lin-mm-to-lin-mm --]
[-- Type: application/octet-stream, Size: 4139 bytes --]

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  0      0 178240  20360  63688    0    0   101    33  276   169 15  2 80  2
 0  0      0 178240  20400  63696    0    0     8    68 1019    27  0  1 96  3
 0  0      0 178240  20400  63696    0    0     0     0 1006     8  0  0 100  0
 0  0      0 178240  20400  63696    0    0     0     0 1008    14  0  0 100  0
 0  0      0 178240  20400  63696    0    0     0     0 1004    12  0  0 100  0
 0  0      0 178240  20400  63696    0    0     0     0 1005    14  0  0 100  0
 0  0      0 178240  20412  63696    0    0     0    20 1011    20  0  0 100  0
 0  0      0 178176  20460  63696    0    0     4    72 1024    37  0  0 99  1
 1  0      0 171012  20468  70512    0    0     0     0 2589   222  0 75 25  0
 1  0      0 162244  20476  79280    0    0     0     0 5497   289  0 100  0  0
 1  0      0 153732  20484  88048    0    0     0     0 5618  1214  0 100  0  0
 1  1      0 145540  21016  95280    0    0     0  5848 4887   528  1 99  0  0
 1  1      0 139268  21020 101552    0    0     0  5276 4414  1260  0 100  0  0
 1  2      0 132228  21028 108656    0    0     0  2828 4992  5500  0 100  0  0
 1  2      0 125380  21036 115408    0    0     0  4320 4885  6024  0 100  0  0
 1  2      0 119044  21040 121840    0    0     0  5760 5352  5829  0 100  0  0
 1  2      0 113988  21048 126832    0    0     0  6196 4268  4731  1 99  0  0
 2  1      0 109764  21052 130888    0    0     0  5224 4011  3766  0 64  0 36
 1  0      0 103876  21056 136812    0    0     0  7876 4831  5618  0 100  0  0
 1  0      0  96516  21064 143916    0    0     0     0 5529  6671  0 100  0  0
 1  0      0  91332  21068 149068    0    0     0  9348 3804  4864  0 100  0  0
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 2  1      0  82948  21076 157064    0    0     0  6724 6287  7503  0 100  0  0
 1  1      0  79364  21356 159848    0    0     0 36220 1967  2719  0 100  0  0
 1  1      0  76228  21360 163336    0    0     0     0 2064  3335  0 100  0  0
 1  0      0  71620  21364 168224    0    0     0   280 3422  4576  1 99  0  0
 1  0      0  67716  21424 172092    0    0     0 10808 3681  3775  0 56  0 44
 1  0      0  59396  21432 180284    0    0     0     0 6356  7676  0 100  0  0
 1  0      0  51012  21440 188536    0    0     0     0 6379  7739  0 100  0  0
 1  0      0  42628  21448 196836    0    0     0     0 6465  7772  0 100  0  0
 1  1      0  35460  21532 203256    0    0     0 33336 4836  5986  0 100  0  0
 1  1      0  32196  21536 206852    0    0     0     0 2180  3430  0 100  0  0
 1  0      0  27908  21540 211252    0    0     0   376 3021  4165  0 100  0  0
 1  0      0  19652  21548 219428    0    0     0     4 6154  7661  0 100  0  0
 1  0      0  11524  21556 227504    0    0     0     4 6416  7563  0 100  0  0
 1  0      0   3128  21564 235772    0    0     0     0 6432  7746  1 99  0  0
 3  0      0   2352  17428 240988    0    0     0  3604 5411  5982  0 100  0  0
 0  2      0   2816  16080 241064    0    0     0 32860 4643  3364  0 85  0 15
 2  1      0   2832  15604 241944    0    0     0   292 2091  2591  0 84  0 16
 2  1      0   2600  14836 243504    0    0     0  3640 3358  4167  0 100  0  0
 2  0      0   2856  13836 244664    0    0     0  5796 4396  1931  0 100  0  0
 0  1      0   2224  13532 245740    0    0     0  4224 2970  2312  0 35  0 65
 0  1      0   3060  13404 244828    0    0     0  8028 1660    52  0  5  0 95
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 2  0      0   2736  13380 245708    0    0     0  3148 3310  2317  0 42  0 58
 1  0      0   2856  12616 246500    0    0     0     0 6892  5792  0 100  0  0
 1  1      0   2732  12396 247544    0    0     0  2624 6287  1131  0 100  0  0
 1  1      0   2536  12100 248196    0    0     0 11404 3940   251  0 100  0  0

[-- Attachment #4: clientlog-ftpput --]
[-- Type: application/octet-stream, Size: 3635 bytes --]

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  0      0 198312  70336 258240    0    0   299    85 1536   767  8  6 78  8
 0  0      0 198228  70336 258308    0    0    68     0 1437   463  3  1 94  2
 0  0      0 198228  70336 258308    0    0     0     0 2013  1589 11  6 83  0
 0  1      0 196652  70388 259820    0    0  1506    92 2329   540  2  3 87  8
 0  0      0 190240  70392 266208    0    0  6414     0 6567   808  0 11 84  5
 0  0      0 183604  70400 272864    0    0  6662     0 6618   814  0 10 84  6
 0  0      0 179236  70404 277212    0    0  4357     0 5303  1305  6 10 81  3
 0  0      0 175024  70408 281424    0    0  4228     0 4545   712  1  7 89  3
 0  0      0 167832  70428 288136    0    0  6718    20 7369  1026  8 13 73  6
 0  0      0 160492  70432 294796    0    0  6663     0 6648   906  0  9 85  5
 0  0      0 153236  70440 301384    0    0  6534     0 6612   905  1 11 83  5
 0  0      0 145748  70448 308108    0    0  6791     0 6696   926  1 11 81  7
 0  0      0 142612  70448 310964    0    0  2818     0 3477   648  1  5 92  2
 0  0      0 142612  70460 310952    0    0     0    20 1112   500  0  0 100  0
 0  0      0 135956  70468 316996    0    0  6022     0 6129   856  1 10 84  5
 0  0      0 128724  70472 323520    0    0  6535     0 6670   888  1 13 80  6
 0  0      0 121364  70480 330176    0    0  6662     0 6606   894  0 11 83  6
 0  0      0 114004  70488 336832    0    0  6663     0 6678   925  1 12 81  6
 0  0      0 107156  70504 342936    0    0  6150    20 6360   867  1 10 82  6
 0  0      0 104340  70508 345516    0    0  2562     0 3200   685  1  5 91  3
 0  0      0 101396  70508 348168    0    0  2691     0 3338   645  0  3 95  2
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 2  0      0  94164  70516 354756    0    0  6534     0 6698   904  1 11 82  6
 0  0      0  86740  70524 361412    0    0  6663     0 6668   935  4 12 77  6
 0  0      0  79380  70540 368060    0    0  6662    20 6651   897  1 11 83  5
 0  0      0  72020  70548 374716    0    0  6663     0 6685   903  1 11 82  6
 0  0      0  66720  70552 379676    0    0  4997     0 5777   871  2  8 85  4
 1  0      0  64148  70556 381984    0    0  2306     0 3309  1039  5  6 87  2
 0  0      0  60764  70556 385044    0    0  3075     0 4013   631  1  6 91  2
 0  0      0  53404  70576 391688    0    0  6662    20 7302  1390  5 15 74  6
 1  0      0  46412  70580 398008    0    0  6278     0 6824  1459  6 15 75  4
 0  0      0  46412  70580 398008    0    0     0     0 1191   400  1  1 98  0
 0  0      0  46412  70580 398008    0    0     0     0 1091   396  0  1 99  0
 0  0      0  46412  70580 398008    0    0     0     0 1113   436  1  0 99  0
 0  0      0  46412  70592 397996    0    0     0    20 1127   563  2  0 98  0
 0  0      0  46412  70592 397996    0    0     0     0 1171   617  3  1 96  0
 0  0      0  46428  70592 397996    0    0     0     0 1300   580  3  1 96  0
 0  0      0  46428  70592 397996    0    0     0     0 1097   409  1  0 99  0
 0  0      0  46428  70592 397996    0    0     0     0 1203   804  5  1 94  0
 0  0      0  46300  70640 398016    0    0     0   112 1236  1273 11  3 86  0
 0  0      0  46300  70640 398016    0    0     0     0 1568  1574 13  4 83  0
 0  0      0  46620  70640 398016    0    0     0     0 2298  1439 12  6 82  0
 0  0      0  46648  70640 398016    0    0     0     0 1408   908  5  2 93  0

[-- Attachment #5: clientlog-nfsput --]
[-- Type: application/octet-stream, Size: 4266 bytes --]

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  0      0  16776 292012 166988    0    0   276    87 1521   770  8  6 78  8
 0  0      0  16748 292012 166988    0    0     0     0 1476   416  3  1 96  0
 0  0      0  16748 292012 166988    0    0     0     0 2640  1564 12  6 82  0
 0  0      0  16748 292012 166988    0    0     0     0 1104   426  1  0 99  0
 0  0      0  16748 292012 166988    0    0     0     0 1219   435  1  1 98  0
 0  1      0  15356 292052 168308    0    0   744    80 1259   488  1  2 93  4
 0  1      0   5036 286580 184524    0    0  9476     0 1284   622  3 14  0 83
 0  1      0   4588 275636 198868    0    0  9348     0 1301   664  4 17  0 79
 0  1      0   4972 269376 206352    0    0  4625     0 1263   564  1  8  0 91
 1  1      0   5248 264268 212208    0    0  3725     0 1495   687  5  8  0 87
 1  1      0   5292 238764 243764    0    0 19358    16 2129  1886 16 38  0 47
 0  1      0   5164 212332 274888    0    0 19613     8 2160  1023  7 36  0 57
 0  1      0   5008 199712 289140    0    0 14739     0 3938   921  6 32  0 62
 0  1      0   5344 180980 312020    0    0 18578     0 8116  1149  6 44  0 49
 0  1      0   4960 173048 322876    0    0  8852     0 7988  1086  4 25  0 71
 0  1      0   5360 163640 334188    0    0  8474     0 6578  1012  5 22  0 73
 0  2      0   5288 154676 346280    0    0  9730     4 4463   915  4 23  0 72
 0  2      0   5348 145140 358332    0    0  7812    12 7056  1168  4 25  0 71
 0  1      0   5368 139152 366564    0    0  5065     0 7798  1062  3 18  0 79
 0  1      0   5012 133780 372820    0    0  3855     0 7854   995  3 18  0 79
 0  1      0   5012 130208 377004    0    0  2571     0 7841   967  3 14  0 83
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  1      0   5136 128292 379056    0    0  1161     0 7270  2039 12 16  0 72
 0  1      0   4760 120656 388392    0    0  5904     0 4059   805  4 15  0 81
 0  2      0   5536 111688 397496    0    0  5762    12 4195   899  3 15  0 82
 1  1      0   5528 108032 401764    0    0  2721     4 3605   851  3 11  0 86
 0  1      0   5276 100952 410204    0    0  5243     0 7641  1045  2 20  0 78
 0  1      0   4636  95532 417188    0    0  4289     0 7621  1042  3 15  0 81
 0  1      0   5612  90808 421436    0    0  2781     0 7609  1053  2 14  0 84
 0  1      0   5276  80724 433696    0    0  7256     4 7748  1093  3 22  0 74
 0  0      0   4908  69872 446044    0    0  7533    20 5074   948  4 17 61 17
 0  0      0   4908  69872 446044    0    0     0     0 3803   610  0  3 97  0
 0  0      0   4908  69872 446044    0    0     0     0 5064   713  1  3 96  0
 0  0      0   4972  69872 446044    0    0     0     0 6978   864  0  8 92  0
 0  0      0   5164  69872 446044    0    0     0     0 7493   914  0  6 94  0
 0  0      0   5164  69884 446032    0    0     0    20 1207   419  1  1 98  0
 0  0      0   6380  69884 446032    0    0     0     0 4992   712  0  6 94  0
 0  0      0   6508  69884 446032    0    0     0     0 7394   915  0  5 95  0
 0  0      0   6572  69884 446032    0    0     0     0 3858   619  1  5 94  0
 0  0      0   6636  69884 446100    0    0    12     0 5700   820  1  4 94  1
 0  0      0   7600  69928 446056    0    0     0   104 5860   783  1  7 92  0
 0  0      0   8116  69928 446056    0    0     0     0 5489   762  3  6 91  0
 0  0      0   8440  69928 446056    0    0     0     0 6020   852  1  6 93  0
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 1  0      0   8568  69928 446056    0    0     0     0 5433   822  1  5 94  0
 0  0      0  10488  69944 446040    0    0     7     0 2099   728  4  6 86  4
 0  0      0  10480  69956 446096    0    0     0    20 1224   952  4  1 95  0
 0  0      0  10480  69956 446096    0    0     0     0 1283   465  2  1 97  0
 0  0      0 199252  69956 257600    0    0     0     0 1779  1300  9  7 84  0
 0  0      0 199252  69956 257600    0    0     0     0 1445  1205 19  4 77  0

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: gigabit trouble
       [not found]                   ` <b71082d804080219476103bd47@mail.gmail.com>
@ 2004-08-03  7:48                     ` Francois Romieu
  0 siblings, 0 replies; 11+ messages in thread
From: Francois Romieu @ 2004-08-03  7:48 UTC (permalink / raw)
  To: Bart Alewijnse; +Cc: netdev, linux-kernel

Bart Alewijnse <scarfboy@gmail.com> :
[...]
> The panic looks a lot like the last one; same kernel (napi still
> enabled for the 8169). Image attached.

The irq rate are strangely high for a napi version of the r8169 driver.

Can you describe your test commands so that I reproduce these here ?

--
Ueimor

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2004-08-03  7:51 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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:35     ` Bart Alewijnse
     [not found]     ` <b71082d804073008157cf1d6c0@mail.gmail.com>
     [not found]       ` <20040730205412.A15669@electric-eye.fr.zoreil.com>
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
     [not found]                   ` <b71082d804080219476103bd47@mail.gmail.com>
2004-08-03  7:48                     ` Francois Romieu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox