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

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?

[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

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.

[parisc-linux] Dual NICs on 9000/715, anyone?

[buggz]

Anyone get dual NICs working on this machine?
The second one is on the EISA expansion card.
It works in HPUX.
I'd like to get this to work in linux and use the box as a router/gw.

Re: [parisc-linux] Dual NICs on 9000/715, anyone?

[Matthew Wilcox]

On Sat, Nov 15, 2003 at 06:22:32PM -0500, buggz wrote:
> Anyone get dual NICs working on this machine?
> The second one is on the EISA expansion card.
> It works in HPUX.
> I'd like to get this to work in linux and use the box as a router/gw.

When you asked on IRC, I asked you what kind of EISA network card it is.
I don't know what driver you'll need to enable.

-- 
"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] Dual NICs on 9000/715, anyone?

[buggz]

On Sat, 15 Nov 2003, Matthew Wilcox wrote:

> On Sat, Nov 15, 2003 at 06:22:32PM -0500, buggz wrote:
> > Anyone get dual NICs working on this machine?
> > The second one is on the EISA expansion card.
> > It works in HPUX.
> > I'd like to get this to work in linux and use the box as a router/gw.
>
> When you asked on IRC, I asked you what kind of EISA network card it is.
> I don't know what driver you'll need to enable.
>
> --
> "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
>

Oh, the expansion card?
I gave the P/N of the NIC.
I will reply here w/ the P/N's of both the cards.
Those parts are at work, so it will be Tuesday before I know.
Thanks.

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] Dual NICs on 9000/715, anyone?

[Grant Grundler]

On Sat, Nov 15, 2003 at 06:22:32PM -0500, buggz wrote:
> Anyone get dual NICs working on this machine?
> The second one is on the EISA expansion card.

EISA DMA isn't working, IIRC.
I don't recall if anyone has published Wax (EISA) DMA docs.
If not, that means someone from HP would have to write it
or get enough detail from someone inside HP to write it.

> It works in HPUX.
> I'd like to get this to work in linux and use the box as a router/gw.

At one we had a NIC working using PIO (not DMA).
But don't expect stellar performance.

grant

RE: [parisc-linux] Dual NICs on 9000/715, anyone?

[Shane G. Brodie]

Slightly off topic:  I've been fighting with a 715/80 with an EISA 10/100 VG
AnyLan card in it for the last 2 weeks.  I can not get the network to come
up. I have a whole series of issues to resolve unrelated to the network
hardware, but that's another long story ... (the old SCSI CD-ROM doesn't
like CD-RW ... don't have spare CD-R ... disc 2 of my downloaded set is
unreadable - how I wish the MD5 checksums were up-to-date ...  I could set
up dial-up (eeek!) but ...

I don't have have an EtherTwist transceiver for the built-in (and don't know
if it'll work anyway) - can anyone advise me whether or not the the built-in
10-Base-2 Ethernet NIC will work using a AUI-10MB Ethernet transceiver
connected to a Linksys DSL 10/100 router?  (I have a CenterCOM MX10 IEEE
802.3 MicroTransceiver 10-Base-2 - a lot of good that'll do me ...).

Regards

Shane Brodie

-----Original Message-----
From: parisc-linux-admin@lists.parisc-linux.org
[mailto:parisc-linux-admin@lists.parisc-linux.org]On Behalf Of Grant
Grundler
Sent: November 15, 2003 7:52 PM
To: buggz
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] Dual NICs on 9000/715, anyone?


On Sat, Nov 15, 2003 at 06:22:32PM -0500, buggz wrote:
> Anyone get dual NICs working on this machine?
> The second one is on the EISA expansion card.

EISA DMA isn't working, IIRC.
I don't recall if anyone has published Wax (EISA) DMA docs.
If not, that means someone from HP would have to write it
or get enough detail from someone inside HP to write it.

> It works in HPUX.
> I'd like to get this to work in linux and use the box as a router/gw.

At one we had a NIC working using PIO (not DMA).
But don't expect stellar performance.

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

Re: [parisc-linux] Dual NICs on 9000/715, anyone?

[Grant Grundler]

On Sat, Nov 15, 2003 at 10:16:11PM -0600, Shane G. Brodie wrote:
> Slightly off topic:  I've been fighting with a 715/80 with an EISA 10/100 VG
> AnyLan card in it for the last 2 weeks.  I can not get the network to come
> up.

If it's trying to use DMA, it won't work.

> I have a whole series of issues to resolve unrelated to the network
> hardware, but that's another long story ... (the old SCSI CD-ROM doesn't
> like CD-RW ... don't have spare CD-R ... disc 2 of my downloaded set is
> unreadable - how I wish the MD5 checksums were up-to-date ...  I could set

can you clarify which MD5 csums are stale?
Post the URL on this list and likely someone can fix it.

> up dial-up (eeek!) but ...
> 
> I don't have have an EtherTwist transceiver for the built-in (and don't know
> if it'll work anyway) - can anyone advise me whether or not the the built-in
> 10-Base-2 Ethernet NIC will work using a AUI-10MB Ethernet transceiver
> connected to a Linksys DSL 10/100 router?

The 715 built-in (LASI "apricot", uses lasi_82596 driver) works fine.
I wouldn't expect any compatibility problems with Linksys router.

grant

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?

[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