Re: HP-PB 10/100 10.20 driver?

From: Rick Jones (foo_at_bar.baz.invalid)
Date: 10/09/03 

Date: Thu, 09 Oct 2003 17:08:54 GMT

Gereon Wenzel <gereon.wenzel@post.rwth-aachen.de> wrote:
> I allready searched this group with google and found several equal
> threads, but I don't have a support contract, so no DART Cds are
> availiable. The card is a pull from a G30, so the original CD isn't
> availiable either. If there is no downloadable driver, is there any
> way the create the driver package (.depot) from the source system?

Nope. The driver was provided on DARTS, and there is no way (at least
no supported way) to copy the driver from a system on which it is
already installed. If you know all the relevant filenames you _could_
probably accomplish it, but I don't know all the relevant filenames.

Did you even get much more than 10 Mbit/s out of the 10/100 NIC in the
G30? IIRC the E series were at least as powerful if not more so:

 Date: Fri, 13 Jun 1997 17:30:12 -0700
 From: Rick Jones <raj+briefs@cup.hp.com>

 Folks,

 As part of HP's effort to address <customer>'s concerns with HP-PB
 100 BT performance, I have set-up a pair of E Series systems to
 investigate performance differences between the HP-PB 100BT card, and
 an HP-PB FDDI card crippled with a 1500 byte MTU.

 The system(s) used by <customer> for their tests were apparently
 E25's, though it is not entirely clear if those are also the systems
 in "production." E25's were bottom-of-the-line entry-level systems
 some years ago, and finding that type of system in the Lab proved
 quite difficult. I was able to obtain an E35 and an E55. Into each
 system I placed 100BT and FDDI interface. The FDDI interfaces were
 connected via a Cisco concentrator, the 100BT interfaces were
 connected to a Cisco 104T hub and were operating in a half-duplex
 mode.

 The OS was 10.20, and the drivers were the "DART 34" versions from an
 HP-internal depot maintained by the driver project.

 <customer>'s original tests used FTP. For these tests I used netperf
 (http://www.cup.hp.com/netperf/NetperfPage.html) to avoid any issues
 with disc I/O. 56KB TCP windows were used, matching the default
 window size used by FTP in 10.20.

 Here are the results of three separate netperf TCP_STREAM tests, all
 with the E35 sending and the E55 receiving. The first is with FDDI
 unconstrained by the 1500 byte MTU:

 # ./netperf -H 192.68.2.8 -l 30 -c $LOC_RATE -- -S 56K -s 56K -m 4K
 TCP STREAM TEST to 192.68.2.8
 Recv Send Send Utilization Service Demand
 Socket Socket Message Elapsed Send Recv Send Recv
 Size Size Size Time Throughput local remote local remote
 bytes bytes bytes secs. 10^6bits/s % I % U us/KB us/KB

 57344 57344 4096 30.01 55.82 63.95 -1.00 93.846 -1.000

 You can see that with the full MTU, it took about 93 microseconds of
 CPU time to transfer a KB (K == 1024) of bulk data across the FDDI
 interface.

 The next is with FDDI crippled with a 1500 byte MTU:

 # lanadmin -M 1500 4
 Old MTU Size = 4352
 New MTU Size = 1500
 # ./netperf -H 192.68.2.8 -l 30 -c $LOC_RATE -- -S 56K -s 56K -m 4K
 TCP STREAM TEST to 192.68.2.8
 Recv Send Send Utilization Service Demand
 Socket Socket Message Elapsed Send Recv Send Recv
 Size Size Size Time Throughput local remote local remote
 bytes bytes bytes secs. 10^6bits/s % I % U us/KB us/KB

 57344 57344 4096 30.01 41.80 94.57 -1.00 185.330 -1.000

 We can see that the quantity of CPU time required to transmit a KB of
 data across the link has increased considerably - roughly 2X. This
 is consistent with the nearly 3X increase in the number of packets
 required for a given quantity of data (4096/1460 = 2.8). That means
 nearly three times the number of interrupts as before, and three
 times the number of trips up and down the protocol stack. Service
 demand did not increase 3X because not all of the CPU "cost" is
 per-packet. The rest (eg data copy) is per-byte. The only reason
 our performance was not cut in half was that the original test still
 had 37% idle CPU - this second test with the smaller MTU soaked that
 up and more.

 Third, the same test over the HP-PB 100BT interface:

 # ./netperf -H 192.168.1.8 -l 30 -c $LOC_RATE -- -S 56K -s 56K -m 4K
 TCP STREAM TEST to 192.168.1.8
 Recv Send Send Utilization Service Demand
 Socket Socket Message Elapsed Send Recv Send Recv
 Size Size Size Time Throughput local remote local remote
 bytes bytes bytes secs. 10^6bits/s % I % U us/KB us/KB

 57344 57344 4096 30.00 29.83 95.41 -1.00 261.998 -1.000

 In this test, the service demand was nearly 262 microseconds per KB,
 which is an increase of approximately 40%, which is consistent with
 throughput delta's between the two interfaces.

 So, even though both interfaces are NIO, and both were configured
 with a 1500 byte MTU, the increased service demand of the HP-PB 100BT
 driver leads to lower throughput. In the case of the E35, the CPU
 bottleneck for the 100BT driver is hit before the bandwidth
 bottleneck of the HP-PB bus converter.

 The E25 has a SPECint92 rating of 50.1, and an OLTP performance
 rating of 80. The E35 has a SPECint92 of 73.1, and OLTP rating of
 125.

 So, one might expect at a first, very rough, approximation, an E25 to
 be at about 18 or 19 Mbit/s, which is getting close to the 16 Mbit/s
 reported by <customer>. Add-in the additional overhead of FTP
 (filesystem and such) and 16 Mbit/s sounds about right. 

-- 
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com  but NOT BOTH...

Relevant Pages

  • Re: VxWorks 6.6 - Ethernet interface driver support
    ... Ethernet interface cards, deploying the "Intel PRO/1000 VxBus Enhanced ... Network Driver" in conjunction with the "Generic PHY driver", ... these interfaces. ...   MII_Bus @ 0x005073cc ...
    (comp.os.vxworks)
  • Re: VxWorks 6.6 - Ethernet interface driver support
    ... electrical Ethernet interfaces with optical Ethernet ... interfaces (DSS PMC card), so I wanted to disable the Generic PHY ... driver would result in removing also the Intel PRO/ ... CTRL register bits RFCE (Receive Flow Control Enable) and TCFE ...
    (comp.os.vxworks)
  • Re: VxWorks 6.6 - Ethernet interface driver support
    ... electrical Ethernet interfaces with optical Ethernet ... interfaces (DSS PMC card), so I wanted to disable the Generic PHY ... driver would result in removing also the Intel PRO/ ... CTRL register bit LRST is set ...
    (comp.os.vxworks)
  • Re: VxWorks 6.6 - Ethernet interface driver support
    ... electrical Ethernet interfaces with optical Ethernet ... interfaces (DSS PMC card), so I wanted to disable the Generic PHY ... driver would result in removing also the Intel PRO/ ... CTRL register bit LRST is set ...
    (comp.os.vxworks)
  • Re: PATCH: VLAN support for 3c59x/3c90x
    ... > the MTU change information is given to the driver after it is already ... MTU change need not occur while the interface is up. ... but receiving packets not wholly contained in a single frame is SO ...
    (Linux-Kernel)