[parisc-linux] C110 builtin nic slow?

[parisc-linux] C110 builtin nic slow?

[Joel Soete]

Hi all,

Here are the devices found on my c110 box:
Found devices:
1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, 0x7, 0xb
2. SkyHawk 100/120 FW-SCSI (4) at 0xf3f8c000 [8/12], versions 0x1f, 0x0, 
0x89
3. Raven T' Core BA (11) at 0xffd00000 [8/16], versions 0x32, 0x0, 0x81, 
  additional addresses: 0xffd0c000 0xffc00000
4. Raven T' Core Centronics (10) at 0xffd02000 [8/16/0], versions 0x32, 
0x0, 0x74,  additional addresses: 0xffd01000 0xffd03000
5. Raven T' Audio (10) at 0xffd04000 [8/16/1], versions 0x32, 0x0, 0x7b
6. Raven T' Lasi Core RS-232 (10) at 0xffd05000 [8/16/4], versions 0x32, 
0x0, 0x8c
7. Raven T' Core SCSI (10) at 0xffd06000 [8/16/5], versions 0x32, 0x0, 0x82
8. Raven T' Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x32, 
0x0, 0x8a
9. Raven T' Core PS/2 Port (10) at 0xffd08000 [8/16/7], versions 0x32, 
0x0, 0x84
10. Raven T' Core PS/2 Port (10) at 0xffd08100 [8/16/8], versions 0x32, 
0x0, 0x84
11. Raven T' Core PC Floppy (10) at 0xffd0a000 [8/16/10], versions 0x32, 
0x0, 0x83
12. Raven T' Wax BA (11) at 0xffe00000 [8/20], versions 0x1e, 0x0, 0x8e, 
  additional addresses: 0xffe03000 0xffe06000
13. Raven T' Wax HIL (10) at 0xffe01000 [8/20/1], versions 0x1e, 0x0, 0x73
14. Raven T' Wax RS-232 (10) at 0xffe02000 [8/20/2], versions 0x1e, 0x0, 
0x8c
15. Raven T' Wax EISA BA (11) at 0xfc000000 [8/20/5], versions 0x1e, 
0x0, 0x90,  additional addresses: 0xffc88400 0xf4000000
16. U2-IOA BC GSC+ Port (7) at 0xf3fbf000 [8/63], versions 0x501, 0x1, 
0xc,  additional addresses: 0xf3f80000
17. U2-IOA BC Runway Port (12) at 0xfff8a000 [10], versions 0x580, 0x7, 0xb
18. Raven T' GSC Core Graphics (10) at 0xf4000000 [10/16], versions 
0x32, 0x0, 0x85,  additional addresses: 0xf0069000
19. U2-IOA BC GSC+ Port (7) at 0xf3fff000 [10/63], versions 0x501, 0x1, 0xc
20. Raven 120 T' (0) at 0xfffa0000 [32], versions 0x58e, 0x0, 0x4
21. Memory (1) at 0xfffb1000 [49], versions 0x49, 0x0, 0x9
CPU(s): 1 x PA7200 (PCX-T') at 120.000000 MHz

And, at the office, I use to obtain around nice 1Mb/s when I do such 
rsync or ftp between my b180 connected via a hub.

But here at home, I connect the builtin nic of my c110 with a 
cross-cable to my pc (proxy) and I just obtain 50kb/s (whatever the 
kernel I boot 2.4 or 2.6) (ie 20 time less then with a another pc 
connected in place of the c110). Is it possible to improve the 
performance of this builtin nic?

Thanks in advance,
	Joel

Re: [parisc-linux] C110 builtin nic slow?

[Grant Grundler]

On Sun, Oct 26, 2003 at 04:49:04PM +0000, Joel Soete wrote:
> 8. Raven T' Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x32, 
> 0x0, 0x8a

This is a 10Mb link.

> And, at the office, I use to obtain around nice 1Mb/s when I do such 
> rsync or ftp between my b180 connected via a hub.

Which protocol?

> But here at home, I connect the builtin nic of my c110 with a 
> cross-cable to my pc (proxy) and I just obtain 50kb/s (whatever the 
> kernel I boot 2.4 or 2.6) (ie 20 time less then with a another pc 
> connected in place of the c110). Is it possible to improve the 
> performance of this builtin nic?

Earlier this year I exchanged email with someone on linux-ia64 list with
a similar sounding problem. They were trying to NFS mount some exported
by the ia64-linux server but perf was ~80KB/s vs 50MB/s (1000BT) across
the same link to another ia64-linux box. We never found the root cause
since netperf demonstrated the UDP throughput was > 50MB/s (expected)
in the same config. I could only guess it was something in the NFS
stack having to do with 16K pages.

But thinking about this more, I'm wondering if some kernel code is
accessing misaligned data someplace in the networking stack.
The arguments I've heard is this is expected behavior.

Joel,
1) Can you verify dmesg has no misaligned data access reports?
2) Can you clarify how you are measuring performance?
   (ie which protocols and which tools?)
3) Can you setup/run netperf or httperf with the PC to verify whatever
   protocol you are using basically works?

grant

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Hi Grant,

Grant Grundler wrote:
> On Sun, Oct 26, 2003 at 04:49:04PM +0000, Joel Soete wrote:
> 
>>8. Raven T' Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x32, 
>>0x0, 0x8a
> 
> 
> This is a 10Mb link.
> 
Yes ;)
> 
>>And, at the office, I use to obtain around nice 1Mb/s when I do such 
>>rsync or ftp between my b180 connected via a hub.
> 
> 
> Which protocol?
> 

ftp (ncftp), rsync, scp

> 
>>But here at home, I connect the builtin nic of my c110 with a 
>>cross-cable to my pc (proxy) and I just obtain 50kb/s (whatever the 
>>kernel I boot 2.4 or 2.6) (ie 20 time less then with a another pc 
>>connected in place of the c110). Is it possible to improve the 
>>performance of this builtin nic?
> 
> 
> Earlier this year I exchanged email with someone on linux-ia64 list with
> a similar sounding problem. They were trying to NFS mount some exported
> by the ia64-linux server but perf was ~80KB/s vs 50MB/s (1000BT) across
> the same link to another ia64-linux box. We never found the root cause
> since netperf demonstrated the UDP throughput was > 50MB/s (expected)
> in the same config. I could only guess it was something in the NFS
> stack having to do with 16K pages.
> 

Well all kernel tested since now (2.4 or 2.6) were well configured to 
support NFS (even if exports file is empty). I can try to remove this 
support?

> But thinking about this more, I'm wondering if some kernel code is
> accessing misaligned data someplace in the networking stack.
> The arguments I've heard is this is expected behavior.
> 
> Joel,
> 1) Can you verify dmesg has no misaligned data access reports?

Unfortunately no such a messages :(

> 2) Can you clarify how you are measuring performance?
>    (ie which protocols and which tools?)

what ever the protocol I use (ftp, rsync, scp) they report their own 
stat which are very low and correspond to the results of gkrellm (iptraf 
seems to lock the trafic).

hm another strange thing: I just compressed the my last kernel 2.4 
sources (about 30Mb) and on my pc I get it with scp from the c110: scp 
and gkrellm showing a rate of about 150Kb/s. Then remove the file on the 
c110 and on this i grab the same file with scp (also) and this time scp 
amd gkrellm showing  togehter a rate a about 50Kb/s. That is get now put 
show same results (i mean on pc put to c110: rate about 50Kb/s; on c110 
put to pc: rate about 150Kb/s).

That say. I also try to re-do the same test with ncftp which seems to 
show the same results excepted that 'put' from c110 to pc 'stail' after 
only one hundred Kb (and I installed the same ftp server on each ie:
ii  ftpd           0.17-16        FTP server
ii  tftpd          0.17-10        Internet trivial file transfer 
protocol serv).



> 3) Can you setup/run netperf or httperf with the PC to verify whatever
>    protocol you are using basically works?

I try to install the non-free (?) dpkg on my pc but:
sid:/home/jso/work # netperf -t UDP_STREAM
UDP UNIDIRECTIONAL SEND TEST to localhost
udp_send: data send error: Message too long
sid:/home/jso/work # netperf -t UDP_STREAM -f m
UDP UNIDIRECTIONAL SEND TEST to localhost
udp_send: data send error: Message too long
sid:/home/jso/work # netperf -t TCP_RR
TCP REQUEST/RESPONSE TEST to localhost
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

16384  87380  1        1       9.99     15980.06
16384  87380
sid:/home/jso/work # netperf -t UDP_RR
UDP REQUEST/RESPONSE TEST to localhost
Local /Remote
Socket Size   Request  Resp.   Elapsed  Trans.
Send   Recv   Size     Size    Time     Rate
bytes  Bytes  bytes    bytes   secs.    per sec

65535  65535  1        1       10.00    27145.26
65535  65535

hmm may be should I try to rebuild the very last src (from hp).
More over the pkg is not available for parisc but I trust it would just 
be rebuild for this platform?

(i just haven't enough time to do it right now, sorry)

The few I can let iptraf running it didn't show's me any udp trafic :(
  Statistics for eth1
Total:     5350    4077724        2411     459794        2939    3617930
IP:        5350    4002824        2411     426040        2939    3576784
TCP:       5350    4002824        2411     426040        2939    3576784
UDP:          0          0           0          0           0          0
ICMP:         0          0           0          0           0          0
Other IP:     0          0           0          0           0          0
Non-IP:       0          0           0          0           0          0


Thanks for help,
	Joel

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Hi Grant,

Sorry to answer to my mail but

> That say. I also try to re-do the same test with ncftp which seems to 
> show the same results excepted that 'put' from c110 to pc 'stail' after 
> only one hundred Kb (and I installed the same ftp server on each ie:
> ii  ftpd           0.17-16        FTP server
> ii  tftpd          0.17-10        Internet trivial file transfer 
> protocol serv).
> 

How may I find and reset the speed setup of a nic (I mean which 10 or 
100 Mb, half or full duplex)?

In a second though I just remember that the pc boot first (i need 
minicom console to boot c110) then latter the c110. So it could be that 
the first one is set in 100 half as default (no connection at boot time) 
and the second 10 half?

Thanks,
	Joel

Re: [parisc-linux] C110 builtin nic slow?

[Grant Grundler]

On Sun, Oct 26, 2003 at 09:10:44PM +0000, Joel Soete wrote:
> How may I find and reset the speed setup of a nic (I mean which 10 or 
> 100 Mb, half or full duplex)?

ethtool?

> In a second though I just remember that the pc boot first (i need 
> minicom console to boot c110) then latter the c110. So it could be that 
> the first one is set in 100 half as default (no connection at boot time) 
> and the second 10 half?

shouldn't matter unless auto-negotiation is broken for one driver or
the other. If they are point-to-point, I expect the negotiation
to take place when the link is brought up with the second NIC.

grant

Re: [parisc-linux] C110 builtin nic slow?

[Matthew Wilcox]

On Mon, Oct 27, 2003 at 12:39:11PM -0700, Grant Grundler wrote:
> On Sun, Oct 26, 2003 at 09:10:44PM +0000, Joel Soete wrote:
> > How may I find and reset the speed setup of a nic (I mean which 10 or 
> > 100 Mb, half or full duplex)?
> 
> ethtool?

I know the lasi_82596 driver doesn't support ethtool yet.

Someone who was interested and had time & the right machine could do some
serious work on lasi_82596:

 - Get rid of "static struct net_device *netdevs[MAX_DRIVERS];"
 - Make it work on peecees and 680x0 too and then get rid of the original
   82596 driver.
 - Add ethtool support.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Grant, Matthew,

>>
>>On Sun, Oct 26, 2003 at 09:10:44PM +0000, Joel Soete wrote:
>> How may I find and reset the speed setup of a nic (I mean which 10 or

>> 100 Mb, half or full duplex)?
>
>ethtool?
>
I will check on my own pc (hp cards but don't remember the model)

hmm I test here with a 3C905B (on an hp vectra) but:
# ethtool eth0
Settings for eth0:
No data available

???

(same results on a b180 with eth0: Digital DS21143 Tulip rev 65 [last kernel
2.4.21])

>> In a second though I just remember that the pc boot first (i need 
>> minicom console to boot c110) then latter the c110. So it could be that

>> the first one is set in 100 half as default (no connection at boot time)

>> and the second 10 half?
>
>shouldn't matter unless auto-negotiation is broken for one driver or 
>the other. If they are point-to-point,

It is a cross-cable

> I expect the negotiation to take place when the link is brought up with

>the second NIC.

I am curious to see if ethtool works for my pc's nic to check the behaviour
on this side.

Thanks for all info,
    Joel



-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.

http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Hi all,

Sorry for this auto-answer but don't see how better follow-up without 
breacking thread?


Joel Soete wrote:
> Grant, Matthew,
> 
> 
> I will check on my own pc (hp cards but don't remember the model)
> 
> hmm I test here with a 3C905B (on an hp vectra) but:
> # ethtool eth0
> Settings for eth0:
> No data available
> 
> ???
> 
> (same results on a b180 with eth0: Digital DS21143 Tulip rev 65 [last kernel
> 2.4.21])
> 
And unfortunately no better results:
[...]
hp100: eth0: Busmaster mode enabled.
hp100: eth0: HP J2585B at 0xe400, IRQ 10, PCI bus, 32k SRAM (rx/tx 75%).
hp100: eth0: Adapter is attached to 10Mb/s network.
[...]

hmm I don't find the second nic in may dmesg (I just know that is also 
an hp but a bit older)?

Anyway:
  # ethtool eth1
Settings for eth1:
No data available
  # ethtool eth0
Settings for eth0:
No data available

Any idea (may be switching the two interfaces: I mean just change 
interfaces)?

Thanks again for your attention,
	Joel

Re: [parisc-linux] C110 builtin nic slow?

[Matthew Wilcox]

On Tue, Oct 28, 2003 at 07:32:29PM +0000, Joel Soete wrote:
> Anyway:
>  # ethtool eth1
> Settings for eth1:
> No data available
>  # ethtool eth0
> Settings for eth0:
> No data available
> 
> Any idea (may be switching the two interfaces: I mean just change 
> interfaces)?

As I said, the lasi_82596 driver doesn't support ethtool.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

>As I said, the lasi_82596 driver doesn't support ethtool.

My bad: confusing lasi and lasi_82596; sorry for my misunderstanding and
thanks for clarification ;)

Joel


-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.

http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] C110 builtin nic slow?

[Grant Grundler]

On Sun, Oct 26, 2003 at 08:40:52PM +0000, Joel Soete wrote:
> hmm may be should I try to rebuild the very last src (from hp).

netperf home is netperf.org.

> More over the pkg is not available for parisc but I trust it would just 
> be rebuild for this platform?

It does run/build on parisc. I've used it before.

Note that with B180, I can only get about 1MB/s throughput max.
With C3000 I get about 5 or 6 MB/s 100BT link.
Your network performance numbers are pretty far off from that
but there might be other factors involved.

I expect mem copy routines are saturating the CPU and thrashing
the data cache.  The tulip driver copies the entire buffer from
where the card DMA'd to the skbuff in order to "bias" the buffer
by 2 bytes. This avoids un-aligned data access in the "common" TCP case.
Adding "unaligned access" macros to the "common" networking code
path has been discussed and rejected (again) in the past month or so.
Linus himself has rejected such proposals in the past too.

If you twiddle the tulip driver to NOT copy all the data for
packets > 512 bytes, the kernel will tell you when/where the network
stack makes unaligned accesses. You can fix those and keep that as
a local patch. I'd be interested in hearing the netperf (or httperf)
numbers with such a patch when compared to the current behavior.

thanks,
grant

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Hello Grant,

> netperf home is netperf.org.

Yes I check and the sources in debian (non-free tree) are the last one alailable
near netperf.org.

> It does run/build on parisc. I've used it before.

Yes, I check it at the office on a b180 :) (dpkg-buildpackage after
an apt-get source netperf; i don't see why it is not pre-build, well doesn't
matter)

>Note that with B180, I can only get about 1MB/s throughput max.
The same here at the office.

>With C3000 I get about 5 or 6 MB/s 100BT link.
What's up, if you connect it via a 10BT hub (but don't reboot and don't
restart or reset the interface). That should be what hapen on my pc box
(but I couldn't verify).

>Your network performance numbers are pretty far off from that but
>there might be other factors involved.

Well trying to help to fix fdisk in 2.6, I don't have time to install netperf
on my C110, sorry.
Any way, a big part of the problem should come from the bad auto-configuration:
As explained before, I start up first my pc (to get a minicom 'console').
As it is setup with auto-negociation and the c110 is not yet pw up, the
nic should be set at 100/full-duplex. Then when I boot the c110, the nic
is setup with the best of its availability: 10/half-duplex.

That seems to be confirm when I launch '/etc/init.d/networking stop and
latter start (restart don't seems to have same effect but again I couldn't
verify yet) on the pc,then I can log peack of 350k/s (that is already better
but that should be the limit of the adsl at this moment).
Another limits seems then to come from squid's caching which drop down flow
to about 100K/s.

So I still have to test ft without squid on the pc, with midle and big size
file, with get and put with various protocol from the two platform to confirm
this hypothesis (obvioulsy another way would be to use a 100bt router or
switch, but I couldn't get any one, and it would need to much time for me
to learn this
os).


>I expect mem copy routines are saturating the CPU and thrashing
>the data cache.  The tulip driver copies the entire buffer from
>where the card DMA'd to the skbuff in order to "bias" the buffer
>by 2 bytes. This avoids un-aligned data access in the "common" TCP case.
>Adding "unaligned access" macros to the "common" networking code
>path has been discussed and rejected (again) in the past month or so.
>Linus himself has rejected such proposals in the past to.
>
>If you twiddle the tulip driver to NOT copy all the data for
>packets > 512 bytes, the kernel will tell you when/where the network
>stack makes unaligned accesses. You can fix those and keep that as
>a local patch. I'd be interested in hearing the netperf (or httperf)
>numbers with such a patch when compared to the current behavior.
>
Ok I will try it first.

>thanks,
>grant
>
Thanks to your attention,
    Joel





-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.

http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Sorry for auto-reply but I just remember that on the c110 the builtin nic
is:
"8. Raven T' Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x32,

0x0, 0x8a"
ie a Lasi_82596 (as Matthew mentioned in a previous mail).

That you look for that stuff in that code :)

Joel


>-- Original Message --
>From: "Joel Soete" <soete.joel@tiscali.be>
>To: "Grant Grundler" <grundler@parisc-linux.org>
>Cc: "parisc-linux" <parisc-linux@lists.parisc-linux.org>
>Date: Mon, 10 Nov 2003 12:10:46 +0100
>Subject: Re: [parisc-linux] C110 builtin nic slow?
>
>
>Hello Grant,

> netperf home is netperf.org.

Yes I check and the sources in debian (non-free tree) are the last one alailable
near netperf.org.

> It does run/build on parisc. I've used it before.

Yes, I check it at the office on a b180 :) (
>pkg-buildpackage after
an apt-get source netperf; i don't see why it is not pre-build, well doesn't
matter)

>Note that with B180, I can only get about 1MB/s throughput max.
The same here at the office.

>With C3000 I get about 5 or 6 MB/s 100BT
>link.
What's up, if you connect it via a 10BT hub (but don't reboot and don't
restart or reset the interface). That should be what hapen on my pc box
(but I couldn't verify).

>Your network performance numbers are pretty far off from that but
>th
>re might be other factors involved.

Well trying to help to fix fdisk in 2.6, I don't have time to install netperf
on my C110, sorry.
Any way, a big part of the problem should come from the bad auto-configuration:
As explained before, I start up f
>rst my pc (to get a minicom 'console').
As it is setup with auto-negociation and the c110 is not yet pw up, the
nic should be set at 100/full-duplex. Then when I boot the c110, the nic
is setup with the best of its availability: 10/half-duplex.

T
>at seems to be confirm when I launch '/etc/init.d/networking stop and
latter start (restart don't seems to have same effect but again I couldn't
verify yet) on the pc,then I can log peack of 350k/s (that is already better
but that should be the limi
> of the adsl at this moment).
Another limits seems then to come from squid's caching which drop down flow
to about 100K/s.

So I still have to test ft without squid on the pc, with midle and big size
file, with get and put with various protocol fr
>m the two platform to confirm
this hypothesis (obvioulsy another way would be to use a 100bt router or
switch, but I couldn't get any one, and it would need to much time for me
to learn this
os).


>I expect mem copy routines are saturating the 
>PU and thrashing
>the data cache.  The tulip driver copies the entire buffer from
>where the card DMA'd to the skbuff in order to "bias" the buffer
>by 2 bytes. This avoids un-aligned data access in the "common" TCP case.
>Adding "unaligned access"
>macros to the "common" networking code
>path has been discussed and rejected (again) in the past month or so.
>Linus himself has rejected such proposals in the past to.
>
>If you twiddle the tulip driver to NOT copy all the data for
>packets > 512
>bytes, the kernel will tell you when/where the network
>stack makes unaligned accesses. You can fix those and keep that as
>a local patch. I'd be interested in hearing the netperf (or httperf)
>numbers with such a patch when compared to the current 
>ehavior.
>
Ok I will try it first.

>thanks,
>grant
>
Thanks to your attention,
    Joel





-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le 
>onde.

http://reg.tiscali.be/default.asp?lg=fr


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux



-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.

http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Grant,

Sorry again, but having find this interesting stuff in 82596.c:
---------><---------
[...]
                        /* Check if the packet is long enough to just accept
                         * without copying to a properly sized skbuff.
                         */

                        if (pkt_len > rx_copybreak) {
                                struct sk_buff *newskb;
[...]
                        }
                        else
                                skb = dev_alloc_skb(pkt_len + 2);

[...]
---------><---------
This seems well what you describe?
and more:
---------><---------
[...]
/* Copy frames shorter than rx_copybreak, otherwise pass on up in
 * a full sized sk_buff.  Value of 100 stolen from tulip.c (!alpha).
 */
static int rx_copybreak = 100;
[...]
---------><---------
and finaly:
---------><---------
/*
[...]
   TBD:
   [...]
   * performace test to tune rx_copybreak
[...]
---------><---------

(I just copy as read preformace and not performance as my mind abuse :) )

This last notice seems what I am loocking for?
Have you a better idea then try and test (ie rx_copybreak=512, test, rx_copybreak=256,
... and btw rx_copybreak = PKT_BUF_SZ == 1536)?
Or is it better to tiddle code before?

Thanks for additional advise,
    Joel

>-- Original Message --
>From: "Joel Soete" <soete.joel@tiscali.be>
>To: "Grant Grundler" <grundler@parisc-linux.org>
>Cc: "parisc-linux" <parisc-linux@lists.parisc-linux.org>
>Date: Mon, 10 Nov 2003 13:31:45 +0100
>Subject: Re: [parisc-linux] C110 builtin nic slow?
>
>
>Sorry for auto-reply but I just remember that on the c110 the builtin nic
is:
"8. Raven T' Core LAN (802.3) (10) at 0xffd07000 [8/16/6], versions 0x32,

0x0, 0x8a"
ie a Lasi_82596 (as Matthew mentioned in a previous mail).

That you look for tha
> stuff in that code :)

Joel




-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.

http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] C110 builtin nic slow?

[Grant Grundler]

On Mon, Nov 10, 2003 at 03:00:37PM +0100, Joel Soete wrote:
>                         if (pkt_len > rx_copybreak) {
>                                 struct sk_buff *newskb;

yup - the rx_copybreak support is exactly what I'm talking about.
tulip driver has similar support.

> /* Copy frames shorter than rx_copybreak, otherwise pass on up in
>  * a full sized sk_buff.  Value of 100 stolen from tulip.c (!alpha).
>  */
> static int rx_copybreak = 100;

The comment is wrong. Tulip uses 1518 for nearly everything but x86.
ie it copies all packets since the MTU is <= 1518.


> This last notice seems what I am loocking for?
> Have you a better idea then try and test (ie rx_copybreak=512, test, rx_copybreak=256,
> ... and btw rx_copybreak = PKT_BUF_SZ == 1536)?
> Or is it better to tiddle code before?

I don't know. It depends on if/when the misaligned access happens.
It's possible the misaligned access is less expensive than
the full copy on your machine.

grant

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Grant Grundler wrote:
> On Mon, Nov 10, 2003 at 03:00:37PM +0100, Joel Soete wrote:
> 
>>                        if (pkt_len > rx_copybreak) {
>>                                struct sk_buff *newskb;
> 
> 
> yup - the rx_copybreak support is exactly what I'm talking about.
> tulip driver has similar support.
> 
> 
>>/* Copy frames shorter than rx_copybreak, otherwise pass on up in
>> * a full sized sk_buff.  Value of 100 stolen from tulip.c (!alpha).
>> */
>>static int rx_copybreak = 100;
> 
> 
> The comment is wrong. Tulip uses 1518 for nearly everything but x86.
> ie it copies all packets since the MTU is <= 1518.
> 
Correct :)

I so try rx_copybreak = 1518

and also run from pc netperf (the script 
/usr/share/doc/netperf/examples/snapshot_script palin)

but on c110 I noticed many (with rx_copybreak = 100 and rx_copybreak = 
1518):
do_page_fault() pid=882 command='netserver' type=15 address=0x0000001c
...
:(

and i never get any miss alignement messages?

I restart this test this morning but in the contrary way ie from c110:
sh /usr/share/doc/netperf/examples/snapshot_script sid.home
then
Netperf snapshot script started at Tue Nov 11 12:52:15 CET 2003
Starting 56x4 TCP_STREAM tests at Tue Nov 11 12:52:52 CET 2003

------------------------------------
Testing with the following command line:
/usr/bin/netperf -t TCP_STREAM -l 60 -H sid.home -i 10,3 -I 99,5 -- -s 
57344 -S 57344 -m 4096


seems to send some pkt and finaly hung?

hmm I will try to run it under gdb and so hope to discover what append.

Cheers,
	Joel

Re: [parisc-linux] C110 builtin nic slow?

[Grant Grundler]

On Tue, Nov 11, 2003 at 12:54:25PM +0000, Joel Soete wrote:
...
> but on c110 I noticed many (with rx_copybreak = 100 and rx_copybreak = 
> 1518):
> do_page_fault() pid=882 command='netserver' type=15 address=0x0000001c
> ...

hrm...this sounds familiar...I might have only run the netperf "client"
on parisc and ran "netserver" on either ia64 or ia32 box. :^/

sorry,
grant

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Hi Grant,

I quiet sure now that the pb come from the 2d nic of my pc.

It is a:
00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] 
(rev 24)

I with google, I find back a mail of Andrew Morton in which he mentioned 
a diag tool for this nic (<http://www.scyld.com/diag/>). I launch it:
# ./vortex-diag -aem
[...]
Transceiver type in use:  10baseT.
  MAC settings: full-duplex.
                ^^^^^^^^^^^^
  Station address set to 00:10:4b:63:2e:bf.
  Configuration options 000a.
Saved EEPROM settings of a 3Com Vortex/Boomerang:
  3Com Node Address 00:10:4B:63:2E:BF (used as a unique ID only).
  OEM Station address 00:10:4B:63:2E:BF (used as the ethernet address).
   Device ID 9055,  Manufacturer ID 6d50.
   Manufacture date (MM/DD/YYYY) 3/17/1998, division 6, product NK.
   No BIOS ROM is present.
  Transceiver selection: 10baseT.
    Options: force full duplex, link beat required.
             ^^^^^^^^^^^^^^^^^
  PCI Subsystem IDs: Vendor 10b7 Device 9055.
[...]

So i will continue to see how to set it up in half-duplex (would it not 
be the default in 10BT?)

Cheers,
	Joel


Grant Grundler wrote:
> On Tue, Nov 11, 2003 at 12:54:25PM +0000, Joel Soete wrote:
> ...
> 
>>but on c110 I noticed many (with rx_copybreak = 100 and rx_copybreak = 
>>1518):
>>do_page_fault() pid=882 command='netserver' type=15 address=0x0000001c
>>...
> 
> 
> hrm...this sounds familiar...I might have only run the netperf "client"
> on parisc and ran "netserver" on either ia64 or ia32 box. :^/
> 
> sorry,
> grant
> 

Re: [parisc-linux] C110 builtin nic slow?

[M. Grabert]

On Sat, 15 Nov 2003, Joel Soete wrote:

> Hi Grant,
>
> I quiet sure now that the pb come from the 2d nic of my pc.
>
> It is a:
> 00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
> (rev 24)
>
> I with google, I find back a mail of Andrew Morton in which he mentioned
> a diag tool for this nic (<http://www.scyld.com/diag/>). I launch it:
> # ./vortex-diag -aem
> [...]
> Transceiver type in use:  10baseT.
>   MAC settings: full-duplex.
>                 ^^^^^^^^^^^^
>   Station address set to 00:10:4b:63:2e:bf.
>   Configuration options 000a.
> Saved EEPROM settings of a 3Com Vortex/Boomerang:
>   3Com Node Address 00:10:4B:63:2E:BF (used as a unique ID only).
>   OEM Station address 00:10:4B:63:2E:BF (used as the ethernet address).
>    Device ID 9055,  Manufacturer ID 6d50.
>    Manufacture date (MM/DD/YYYY) 3/17/1998, division 6, product NK.
>    No BIOS ROM is present.
>   Transceiver selection: 10baseT.
>     Options: force full duplex, link beat required.
>              ^^^^^^^^^^^^^^^^^
>   PCI Subsystem IDs: Vendor 10b7 Device 9055.
> [...]
>
> So i will continue to see how to set it up in half-duplex (would it not
> be the default in 10BT?)

How is it connected?
Is it connected to a Switch (with Full-Duplex support, not a regular Hub)?
Or is it connected to another PC via a Cross-Over cable?

If either of them is true, then 10BaseT will auto-negotiate Full-Duplex,
of both ends support it.
It's usually safe with 10BaseT only cards, but it's might come to some
little problems if some cheap 100BaseTx cards are involved (more complex
auto-negotiation involved, some cheap cards don't do it correctly).
Then you might have to force it to 10Mbit, 100Mbit, Full or Half-Duplex
manually.

However I don't see why the network card should be *automatically* forced
to Full-Duplex, since 'forced' implies that is was done manually!


Actually if one end point uses Full-Duplex and the other end uses
Half-Duplex, there should be no connection possible. The same for
the situation when one side uses 10Mbit and the other is set to
explicitly use 100MBit.

The only situation where such a decreased network performance occurs
is IMHO that your have a cheap network equipment.
IE. a dodgy network cable that isn't properly shielded or doesn't use all
8 wires, and/or cheap network cards that don't test whether the network
connection/cable is capable of supporting Full-Duplex reliably.

In this (worst case) scenario there will be a lot of packet drop on
the physical layer and the network cards will re-send the ethernet
packets autmatically (usually) without notifying you. You will see
decreased network performace as you mentioned it.
Unfortunately I have seen this a couple of times in my life, especially
in the old 10Base2/5 days with broken terminators or tranceivers, but also
with 10BaseT, and even more so with 100Mbit and low-quality network cables.

greetings, Max


PS: oh, yes, another possible problem might be an IRQ conflict (which is
rather unlikely on PA-RISC). It would cause also degraded network
performance.

Re: [parisc-linux] C110 builtin nic slow?

[M. Grabert]

Sorry to reply myself, but think I might need to clarify some points
(I'm a little bit tired, so I have missed some things in my previous post)

On Sat, 15 Nov 2003, M. Grabert wrote:

[...]

> > So i will continue to see how to set it up in half-duplex (would it not
> > be the default in 10BT?)

Yes, usually it defaults to 10Mbit half-duplex and then (if the cards
support it) it tries to negotiate better connections (full-duplex, 100Mbit ...)

> Actually if one end point uses Full-Duplex and the other end uses
> Half-Duplex, there should be no connection possible.

This is true if the (forced full-duplex) network card test for full-duplex
capable connection and doesn't find it. However most (cheap?) cards will
skip the test for full-duplex if it was 'forced', and you can still connect.

Light traffic will work, but you will have problems with large traffic.
The explanation:

The half-duplex side will send a packet, and assumes the other end stops
sending if a collision occurs, ie. if the other side was sending something
at the same time (CSMA/CD).
The full-duplex side will however will always send/receive as fast as it
can as it doesn't do CSMA/CD, ie. it doesn't care about collisions.

The effect is that there will be a massive amount of collisions if both
sides want to send data, and only the half-duplex card will try to resend
the packets (causing even more collisions).
You will see slow traffic when sending from half-duplex, and dropped
packets when sending from full-duplex when both cards are sending.

This will be most likely your problem, since it fits your description
perfectly (forced full-duplex mode). Sorry, I overlooked that in
my first post.



> The same for the situation when one side uses 10Mbit and the other is
> set to explicitly use 100MBit.

This will definitely never work.

> The only situation where such a decreased network performance occurs
> is IMHO that your have a cheap network equipment.
> IE. a dodgy network cable that isn't properly shielded or doesn't use all
> 8 wires,

I mean in the context for 10BaseT, ie. all 4 wires (1/2,3/6) are connected,
but not the rest. There will be noise/crosstalk that will lead to
collisions.

[...]

> In this (worst case) scenario there will be a lot of packet drop on
> the physical layer and the network cards will re-send the ethernet
> packets autmatically (usually) without notifying you. You will see
> decreased network performace as you mentioned it.

The network card (only in half-duplex) will think it detects collisions
due to noise/crosstalk and will automatically resend the packets without
notification.


Slan,
  Max

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

M. Grabert wrote:
> Sorry to reply myself,
Don't worry, I do it also frequently (tired or not i need some more time 
to test more stuff or find back more info ;) )
> but think I might need to clarify some points
> (I'm a little bit tired, so I have missed some things in my previous post)
> 
> On Sat, 15 Nov 2003, M. Grabert wrote:
> 
> [...]
> 
> 
>>>So i will continue to see how to set it up in half-duplex (would it not
>>>be the default in 10BT?)
> 
> 
> Yes, usually it defaults to 10Mbit half-duplex and then (if the cards
> support it) it tries to negotiate better connections (full-duplex, 100Mbit ...)
> 
> 
>>Actually if one end point uses Full-Duplex and the other end uses
>>Half-Duplex, there should be no connection possible.
> 
> 
> This is true if the (forced full-duplex) network card test for full-duplex
> capable connection and doesn't find it. However most (cheap?) cards will
> skip the test for full-duplex if it was 'forced', and you can still connect.
> 
> Light traffic will work, but you will have problems with large traffic.
> The explanation:
> 
> The half-duplex side will send a packet, and assumes the other end stops
> sending if a collision occurs, ie. if the other side was sending something
> at the same time (CSMA/CD).
> The full-duplex side will however will always send/receive as fast as it
> can as it doesn't do CSMA/CD, ie. it doesn't care about collisions.
> 
> The effect is that there will be a massive amount of collisions if both
> sides want to send data, and only the half-duplex card will try to resend
> the packets (causing even more collisions).
> You will see slow traffic when sending from half-duplex, and dropped
> packets when sending from full-duplex when both cards are sending.
> 
> This will be most likely your problem, since it fits your description
> perfectly (forced full-duplex mode). Sorry, I overlooked that in
> my first post.
>
That explain perfectly the pb I encounter; thanks :)

> 
> 
> 
>>The same for the situation when one side uses 10Mbit and the other is
>>set to explicitly use 100MBit.
> 
> 
> This will definitely never work.
> 
> 
>>The only situation where such a decreased network performance occurs
>>is IMHO that your have a cheap network equipment.
>>IE. a dodgy network cable that isn't properly shielded or doesn't use all
>>8 wires,
> 
> 
> I mean in the context for 10BaseT, ie. all 4 wires (1/2,3/6) are connected,
> but not the rest. There will be noise/crosstalk that will lead to
> collisions.
> 
I check: all 8 wires are connected
> [...]
> 
> 
>>In this (worst case) scenario there will be a lot of packet drop on
>>the physical layer and the network cards will re-send the ethernet
>>packets autmatically (usually) without notifying you. You will see
>>decreased network performace as you mentioned it.
> 
> 
> The network card (only in half-duplex) will think it detects collisions
> due to noise/crosstalk and will automatically resend the packets without
> notification.
> 
> 
> Slan,
>   Max
> 
> 
Thanks again,
	Joel

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Hi all,


Joel Soete wrote:
> 
> 
> M. Grabert wrote:
> 
>> Sorry to reply myself,
> 
this is me now ;)

A small follow-up: I exchange my 3com with another hp nic (the same as 
the first one).

The pb now, is that the new one become eth0 (and works fine) but the old 
one (which would be eth1) is not any-more usable (no means to configure 
to setup and configure it):
# cat /proc/pci
[...]
   Bus  0, device  11, function  0:
     Ethernet controller: Hewlett-Packard Company J2585B HP 10/100VG PCI 
LAN Ada
ter (rev 0).
       IRQ 9.
       Master Capable.  Latency=64.  Min Gnt=8.Max Lat=32.
       I/O at 0xe000 [0xe0ff].
       Non-prefetchable 32 bit memory at 0xeb000000 [0xeb001fff].
   Bus  0, device  12, function  0:
     Ethernet controller: Hewlett-Packard Company J2585B HP 10/100VG PCI 
LAN Ada
ter (#2) (rev 0).
       IRQ 10.
       Master Capable.  Latency=64.  Min Gnt=8.Max Lat=32.
       I/O at 0xe400 [0xe4ff].
       Non-prefetchable 32 bit memory at 0xeb002000 [0xeb003fff].
[...]

Any idea?

Thanks again,
	Joel

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Hi all,

Joel Soete wrote:
> Hi all,
> 
> 
> Joel Soete wrote:
> 
>>
>>
>> M. Grabert wrote:
>>
>>> Sorry to reply myself,
>>
>>
> this is me now ;)
Again, apologies

> 
> A small follow-up: I exchange my 3com with another hp nic (the same as 
> the first one).
> 
> The pb now, is that the new one become eth0 (and works fine) but the old 
> one (which would be eth1) is not any-more usable (no means to configure 
> to setup and configure it):
> # cat /proc/pci
> [...]
>   Bus  0, device  11, function  0:
>     Ethernet controller: Hewlett-Packard Company J2585B HP 10/100VG PCI 
> LAN Ada
> ter (rev 0).
>       IRQ 9.
>       Master Capable.  Latency=64.  Min Gnt=8.Max Lat=32.
>       I/O at 0xe000 [0xe0ff].
>       Non-prefetchable 32 bit memory at 0xeb000000 [0xeb001fff].
>   Bus  0, device  12, function  0:
>     Ethernet controller: Hewlett-Packard Company J2585B HP 10/100VG PCI 
> LAN Ada
> ter (#2) (rev 0).
>       IRQ 10.
>       Master Capable.  Latency=64.  Min Gnt=8.Max Lat=32.
>       I/O at 0xe400 [0xe4ff].
>       Non-prefetchable 32 bit memory at 0xeb002000 [0xeb003fff].
> [...]
> 
> Any idea?
> 
I found: ether=9,0,eth0 ether=10,0,eth1 as additional bootparam.

It works but I am confused:
at the office I also have two nic (well of tulip model) on my b2k but I 
never have to add any bootparam to make recognise the second card?
Is it linked with the model capability?

Thanks,
	Joel

PS:  ft problem seems to be solved :)
hmm this 3com works perfectly with 10BT-hd at the office but connected 
this time to a hub (10BT capable) :0

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Hi Max,

M. Grabert wrote:
> On Sat, 15 Nov 2003, Joel Soete wrote:
> 
> 
>>Hi Grant,
>>
>>I quiet sure now that the pb come from the 2d nic of my pc.
>>
>>It is a:
>>00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
>>(rev 24)
>>
>>I with google, I find back a mail of Andrew Morton in which he mentioned
>>a diag tool for this nic (<http://www.scyld.com/diag/>). I launch it:
>># ./vortex-diag -aem
>>[...]
>>Transceiver type in use:  10baseT.
>>  MAC settings: full-duplex.
>>                ^^^^^^^^^^^^
>>  Station address set to 00:10:4b:63:2e:bf.
>>  Configuration options 000a.
>>Saved EEPROM settings of a 3Com Vortex/Boomerang:
>>  3Com Node Address 00:10:4B:63:2E:BF (used as a unique ID only).
>>  OEM Station address 00:10:4B:63:2E:BF (used as the ethernet address).
>>   Device ID 9055,  Manufacturer ID 6d50.
>>   Manufacture date (MM/DD/YYYY) 3/17/1998, division 6, product NK.
>>   No BIOS ROM is present.
>>  Transceiver selection: 10baseT.
>>    Options: force full duplex, link beat required.
>>             ^^^^^^^^^^^^^^^^^
>>  PCI Subsystem IDs: Vendor 10b7 Device 9055.
>>[...]
>>
>>So i will continue to see how to set it up in half-duplex (would it not
>>be the default in 10BT?)
> 
> 
> How is it connected?
> Is it connected to a Switch (with Full-Duplex support, not a regular Hub)?
> Or is it connected to another PC via a Cross-Over cable?
> 
A cross-cable (of high quality).
btw I bring back my office 'thinkpad' (win2k) at home, connect it with 
the same cable to c110's nic and ftp my last kernel src (about 30mb): 
ftp stat showing about 800k/s; that is normal.
I use so the same cable to connect 'thinkpab' to my 3com nic and do the 
same ftp: ftp hang after 600k?

> If either of them is true, then 10BaseT will auto-negotiate Full-Duplex,
> of both ends support it.
> It's usually safe with 10BaseT only cards, but it's might come to some
> little problems if some cheap 100BaseTx cards are involved (more complex
> auto-negotiation involved, some cheap cards don't do it correctly).
> Then you might have to force it to 10Mbit, 100Mbit, Full or Half-Duplex
> manually.
> 
many strange things occurs with this card:
* I don't see it initialized in dmesg as the other nic (even though it 
is well configure (ifconfig :) )
* mii-tool shows:
eth1: 10 Mbit, half duplex, no link
                             ^^^^^^^
even though:
  # ping hpalin
PING hpalin (172.16.248.45): 56 data bytes
64 bytes from 172.16.248.45: icmp_seq=0 ttl=64 time=0.4 ms
64 bytes from 172.16.248.45: icmp_seq=1 ttl=64 time=0.4 ms
64 bytes from 172.16.248.45: icmp_seq=2 ttl=64 time=0.4 ms
64 bytes from 172.16.248.45: icmp_seq=3 ttl=64 time=0.4 ms

--- hpalin ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.4/0.4/0.4 ms
or
  # ping hpalin -s 3000
PING hpalin (172.16.248.45): 3000 data bytes
3008 bytes from 172.16.248.45: icmp_seq=0 ttl=64 time=5.7 ms
3008 bytes from 172.16.248.45: icmp_seq=1 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=2 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=3 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=4 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=5 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=6 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=7 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=8 ttl=64 time=5.6 ms
3008 bytes from 172.16.248.45: icmp_seq=9 ttl=64 time=5.6 ms

--- hpalin ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss

* above mentioned tools (vortex-diag) also mentioned:
[...]
  Basic mode status register 0x3000 ... 3000.
    Link status: not established.
    Capable of  100baseTx 10baseT-FD.
    Unable to perform Auto-negotiation, negotiation not complete.
  This transceiver has no vendor identification.
  I'm advertising 3000:
    Advertising no additional info pages.
    Using an unknown (non 802.3) encapsulation.
  Link partner capability is 3000:.
    Negotiation did not complete.

I need so definitely to force 10baseT-hd but I don't yet find how (I 
lost my isp connection during my last evening research :( ).

> However I don't see why the network card should be *automatically* forced
> to Full-Duplex, since 'forced' implies that is was done manually!
> 
As explain above, it is not the only one incoherencies :(; a cheap bug? 
(afaik it is not the standard to 'force fd' when autoneg failed?)
> 
> Actually if one end point uses Full-Duplex and the other end uses
> Half-Duplex, there should be no connection possible.
By experience (recently we have to fix to 100-fd all server nic and 
related switch ports to avoid such autoneg pb, only with some supplier 
nic not hp :) ), I wouldn't say 'no connection' but well degraded 
connection ;)

> The same for
> the situation when one side uses 10Mbit and the other is set to
> explicitly use 100MBit.
> 
In this case, iirc there are well no connection possible.

> The only situation where such a decreased network performance occurs
> is IMHO that your have a cheap network equipment.
> IE. a dodgy network cable that isn't properly shielded or doesn't use all
> 8 wires, and/or cheap network cards that don't test whether the network
> connection/cable is capable of supporting Full-Duplex reliably.
> 
I don't know if they were cheap but a bit old now:
[...]
Saved EEPROM settings of a 3Com Vortex/Boomerang:
  3Com Node Address 00:10:4B:63:2E:BF (used as a unique ID only).
  OEM Station address 00:10:4B:63:2E:BF (used as the ethernet address).
   Device ID 9055,  Manufacturer ID 6d50.
   Manufacture date (MM/DD/YYYY) 3/17/1998, division 6, product NK.
[...]

> In this (worst case) scenario there will be a lot of packet drop on
> the physical layer and the network cards will re-send the ethernet
> packets autmatically (usually) without notifying you. You will see
> decreased network performace as you mentioned it.
> Unfortunately I have seen this a couple of times in my life, especially
> in the old 10Base2/5 days with broken terminators or tranceivers, but also
> with 10BaseT, and even more so with 100Mbit and low-quality network cables.
> 
> greetings, Max
> 
> 
> PS: oh, yes, another possible problem might be an IRQ conflict (which is
> rather unlikely on PA-RISC). It would cause also degraded network
> performance.
> 
That is the first thing I check:
  # cat /proc/pci
PCI devices found:
[...]
   Bus  0, device   7, function  2:
     USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 1).
       IRQ 10.
       Master Capable.  Latency=64.
       I/O at 0xd000 [0xd01f].
   Bus  0, device   7, function  3:
     Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 2).
       IRQ 9.
[...]
   Bus  0, device  11, function  0:
     Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] 
(rev 36).
       IRQ 9.
       Master Capable.  Latency=64.  Min Gnt=10.Max Lat=10.
       I/O at 0xe000 [0xe07f].
       Non-prefetchable 32 bit memory at 0xec006000 [0xec00607f].
   Bus  0, device  12, function  0:
     Ethernet controller: Hewlett-Packard Company J2585B HP 10/100VG PCI 
LAN Adapter (rev 0).
       IRQ 10.
       Master Capable.  Latency=64.  Min Gnt=8.Max Lat=32.
       I/O at 0xe400 [0xe4ff].
       Non-prefetchable 32 bit memory at 0xec000000 [0xec001fff].
[...]

hmm well the same irq 9 for bridge:... ACPI and nic: 3Com, should it be 
the source of pb?

Thanks for advise and attention,
	Joel

Re: [parisc-linux] C110 builtin nic slow?

[Grant Grundler]

On Mon, Nov 10, 2003 at 01:31:45PM +0100, Joel Soete wrote:
> ie a Lasi_82596 (as Matthew mentioned in a previous mail).

yeah - that's not going to perform as well as tulip.
And 10-Half is going to be substantially slower.
Sounds like it has a bug in the negotiation.

grant

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Grant Grundler wrote:
> On Mon, Nov 10, 2003 at 01:31:45PM +0100, Joel Soete wrote:
> 
>>ie a Lasi_82596 (as Matthew mentioned in a previous mail).
> 
> 
> yeah - that's not going to perform as well as tulip.
> And 10-Half is going to be substantially slower.
> Sounds like it has a bug in the negotiation.
Hmm I could verify, i would have to had ethtool support.
btw is somebody knows a driver which support it (i test without succes 
3com an hp100 driver).

Thx,
	Joel

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

(sorry for auto-reply) but I find effectively interesting stuff:
man ethtool mentioned:  /usr/share/doc/ethtool/README.Debian

in which it seems that is:
Last column show current capabilities of these drivers:
   D = get driver infos
   C = get/set card settings
   W = get/set wake-on-lan settings
   M = get/set message-level
   L = get link status
   R = restart autonegotiation
   G = get registers
   P = get EEPROM

An 'x' indicates that the feature is available, a '.' indicates not.

Ethernet card family                        linux driver    DCWMLRGP
--------------------------------------------------------------------
[...]
NatSemi DP8381x series                      natsemi         xxxxxxxx
[...]

which own the most of ethtool support.

Again sorry for anoyance,
	Joel

Joel Soete wrote:
> 
> 
> Grant Grundler wrote:
> 
>> On Mon, Nov 10, 2003 at 01:31:45PM +0100, Joel Soete wrote:
>>
>>> ie a Lasi_82596 (as Matthew mentioned in a previous mail).
>>
>>
>>
>> yeah - that's not going to perform as well as tulip.
>> And 10-Half is going to be substantially slower.
>> Sounds like it has a bug in the negotiation.
> 
> Hmm I could verify, i would have to had ethtool support.
> btw is somebody knows a driver which support it (i test without succes 
> 3com an hp100 driver).
> 
> Thx,
>     Joel
> 
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
> 

Re: [parisc-linux] C110 builtin nic slow?

[M. Grabert]

On Mon, 10 Nov 2003, Grant Grundler wrote:

> On Mon, Nov 10, 2003 at 01:31:45PM +0100, Joel Soete wrote:
> > ie a Lasi_82596 (as Matthew mentioned in a previous mail).
>
> yeah - that's not going to perform as well as tulip.
> And 10-Half is going to be substantially slower.
> Sounds like it has a bug in the negotiation.

Very likely!

My C200 is also very picky whether to enable 100MBit or not.
I'm using a no-name 100MBit-Switch, and it works fine for all
5 other PCs in my house).

I was not able to force 100MBit by changing the settings in the
PDC, but the following DID work:

> mii-tool -A 100baseTx,10baseT eth0


On my C3000 I don't have these problems.

Take a look in the mailing-list archive (about a year ago I guess and
later I found it also here: http://www.unixnerd.demon.co.uk/hp_unix.html).

Note that this is a problem with the C2x0, but I guess it might be
also true for the entire Cxxx series.


Max

Re: [parisc-linux] C110 builtin nic slow?

[Joel Soete]

Hi Max,

M. Grabert wrote:
> On Mon, 10 Nov 2003, Grant Grundler wrote:
> 
> 
>>On Mon, Nov 10, 2003 at 01:31:45PM +0100, Joel Soete wrote:
>>
>>>ie a Lasi_82596 (as Matthew mentioned in a previous mail).
>>
>>yeah - that's not going to perform as well as tulip.
>>And 10-Half is going to be substantially slower.
>>Sounds like it has a bug in the negotiation.
> 
> 
> Very likely!
> 
> My C200 is also very picky whether to enable 100MBit or not.
> I'm using a no-name 100MBit-Switch, and it works fine for all
> 5 other PCs in my house).
> 
> I was not able to force 100MBit by changing the settings in the
> PDC, but the following DID work:
> 
> 
>>mii-tool -A 100baseTx,10baseT eth0
> 
Ah interesting:
on my pc,
  # mii-tool
SIOCGMIIPHY on 'eth0' failed: Operation not supported
eth1: 10 Mbit, half duplex, no link

and eth1 is the nic I use to connect my c110 :) (don't see what no link 
means but that is the right setup that I need with c110)

otc on the c110:
# mii-tool
SIOCGMIIPHY on 'eth0' failed: Operation not supported
no MII interfaces found
:(

Thx a lot,
	Joel