How fast is the F40 built-in ethernet port (the twisted pair one, not
the AUI, if it makes a difference)? I told it to download
aix51ml9.tar.gz (~600MB) last night and it is still at it (I am using
wget here):

==> SYST ... done. ==> PWD ... done.
==> TYPE I ... done. ==> CWD /software/server/aix51 ... done.
==> PORT ... done. ==> RETR aix51ml9.tar.gz ... done.
Length: 676,284,690 (unauthoritative)

16% [====> ] 109,028,352 3.22K/s ETA 47:47:38

Is it me or that is way too slow?

--
Mauricio raub-kudria-com
(if you need to email me, use this address =)

Mauricio Tavares wrote:
> How fast is the F40 built-in ethernet port (the twisted pair one,
> not the AUI, if it makes a difference)? I told it to download
> aix51ml9.tar.gz (~600MB) last night and it is still at it (I am using
> wget here):
>
> ==> SYST ... done. ==> PWD ... done.
> ==> TYPE I ... done. ==> CWD /software/server/aix51 ... done.
> ==> PORT ... done. ==> RETR aix51ml9.tar.gz ... done.
> Length: 676,284,690 (unauthoritative)
>
> 16% [====> ] 109,028,352 3.22K/s ETA 47:47:38
>
> Is it me or that is way too slow?
>
According to my switch it is running at 100Base but half duplex?! Let's
see if I find a way to persuade it of the joys of going full duplex; can
I do that during flight?

bob>show int fa0/21
FastEthernet0/21 is up, line protocol is up
Hardware is Fast Ethernet, address is 0001.964d.6455 (bia 0001.964d.6455)
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 239/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Auto-duplex (Half), Auto Speed (10), 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 5000 bits/sec, 7 packets/sec
5 minute output rate 25000 bits/sec, 7 packets/sec
14872462 packets input, 3993893193 bytes
Received 2032 broadcasts, 0 runts, 0 giants, 0 throttles
1 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 112 multicast
0 input packets with dribble condition detected
8443653 packets output, 3390476725 bytes, 0 underruns
647573 output errors, 26474 collisions, 1 interface resets
0 babbles, 647573 late collision, 26594 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
bob>


--
Mauricio raub-kudria-com
(if you need to email me, use this address =)

On May 7, 12:57 pm, Mauricio Tavares <u...@ftc.gov> wrote:
> 16% [====> ] 109,028,352 3.22K/s ETA 47:47:38
>
> Is it me or that is way too slow?

Force that thing to Full Duplex.

# chdev -l ent0 -a media_speed=10_Full_Duplex

Autonegotiation always manages to have both parties disagree about the
duplex setting for some reason.

Hope this helps!

Cheers,
Menno

On May 10, 9:23 am, Menno Willemse <fle...@wanadoo.nl> wrote:
> Force that thing to Full Duplex.
>
> # chdev -l ent0 -a media_speed=10_Full_Duplex
>
> Autonegotiation always manages to have both parties disagree about the
> duplex setting for some reason.
>

Ah. In full flight. The old "reconfigure-the-interface-I'm-logged-in-
on-and-hope-for-the-best".

batch
rmdev -l en0
chdev -l ent0 -a media_speed=10_Full_Duplex
mkdev -l en0
^D

Wait for a few breathless seconds and hope you didn't make any
typos Of course, if you can do this on the console, you don't need
the batch command. And you may have to check your routes afterwards,
but this is left as an exercise to the reader.

On May 10, 4:29 am, Menno Willemse <fle...@wanadoo.nl> wrote:
> On May 10, 9:23 am, Menno Willemse <fle...@wanadoo.nl> wrote:
>
> > Force that thing to Full Duplex.
>
> > # chdev -l ent0 -a media_speed=10_Full_Duplex
>
> > Autonegotiation always manages to have both parties disagree about the
> > duplex setting for some reason.
>
> Ah. In full flight. The old "reconfigure-the-interface-I'm-logged-in-
> on-and-hope-for-the-best".
>
> batch
> rmdev -l en0
> chdev -l ent0 -a media_speed=10_Full_Duplex
> mkdev -l en0
> ^D
>
> Wait for a few breathless seconds and hope you didn't make any
> typos Of course, if you can do this on the console, you don't need
> the batch command. And you may have to check your routes afterwards,
> but this is left as an exercise to the reader.

I ran the above batch thingie and this is what I got:

$ lsattr -El ent0
busio 0x800000 Bus I/O address False
busintr 3 Bus interrupt level False
intr_priority 3 Interrupt priority False
tx_que_size 64 TRANSMIT queue size True
rx_que_size 32 RECEIVE queue size True
full_duplex yes Full duplex True
use_alt_addr no Enable ALTERNATE ETHERNET address True
alt_addr 0x000000000000 ALTERNATE ETHERNET address True
$

So, the machine thinks the card is doing full duplex. Problem is the
switch still thinks we are doing half. So, I turned the port of and
then back in in the switch. It did not help. What next? Force the
port to go full in the switch?

On May 15, 5:02 pm, Mauricio <raubvo...@gmail.com> wrote:
....
>
> So, the machine thinks the card is doing full duplex. Problem is the
> switch still thinks we are doing half. So, I turned the port of and
> then back in in the switch. It did not help. What next? Force the
> port to go full in the switch?

$ entsat ent0
will show properties of the adapter , current speed and any errors

hth
Hajo

On May 15, 11:29 am, Hajo Ehlers <serv...@metamodul.com> wrote:
>
> $ entsat ent0
> will show properties of the adapter , current speed and any errors
>
> hth
> Hajo

Unfortunately it seems entsat is not available in 5.1. =(

Mauricio wrote:

> On May 15, 11:29 am, Hajo Ehlers <serv...@metamodul.com> wrote:
>
>>$ entsat ent0
>>will show properties of the adapter , current speed and any errors
>>
>>hth
>>Hajo
>
>
> Unfortunately it seems entsat is not available in 5.1. =(
>

Try "entstat ent0" (note the additional 't')
or "netstat -v" which should do the same thing.

Paul Landay

Mauricio Tavares wrote:
>
>
> On 5/16/07, *Paul Landay* <landay@attglobal.net
> <mailto:landay@attglobal.net>> wrote:
>
> Mauricio wrote:
>
> > On May 15, 11:29 am, Hajo Ehlers <serv...@metamodul.com
> <mailto:serv...@metamodul.com>> wrote:
> >
> >>$ entsat ent0
> >>will show properties of the adapter , current speed and any errors
> >>
> >>hth
> >>Hajo
> >
> >
> > Unfortunately it seems entsat is not available in 5.1. =(
> >
>
> Try "entstat ent0" (note the additional 't')
> or "netstat -v" which should do the same thing.
>
> Paul Landay
>
>
> Hello there. I finally turned my F40 on again. HEre is the output:
>
> # entstat ent0
> -------------------------------------------------------------
> ETHERNET STATISTICS (ent0) :
> Device Type: IBM PCI Ethernet Adapter (22100020)
> Hardware Address: 08:00:5a:ba:96:a0
> Elapsed Time: 0 days 5 hours 11 minutes 24 seconds
>
> Transmit Statistics: Receive Statistics:
> -------------------- -------------------
> Packets: 558 Packets: 8621
> Bytes: 48975 Bytes: 475204
> Interrupts: 0 Interrupts: 8621
> Transmit Errors: 0 Receive Errors: 0
> Packets Dropped: 0 Packets Dropped: 0
> Bad Packets: 0
> Max Packets on S/W Transmit Queue: 4
> S/W Transmit Queue Overflow: 0
> Current S/W+H/W Transmit Queue Length: 1
>
> Broadcast Packets: 9 Broadcast Packets: 8067
> Multicast Packets: 2 Multicast Packets: 386
> No Carrier Sense: 0 CRC Errors: 0
> DMA Underrun: 0 DMA Overrun: 0
> Lost CTS Errors: 0 Alignment Errors: 0
> Max Collision Errors: 0 No Resource Errors: 0
> Late Collision Errors: 0 Receive Collision Errors: 0
> Deferred: 0 Packet Too Short Errors: 0
> SQE Test: 0 Packet Too Long Errors: 0
> Timeout Errors: 0 Packets Discarded by
> Adapter: 0
> Single Collision Count: 0 Receiver Start Count: 0
> Multiple Collision Count: 0
> Current HW Transmit Queue Length: 1
>
> General Statistics:
> -------------------
> No mbuf Errors: 0
> Adapter Reset Count: 25
> Driver Flags: Up Broadcast Running
> Simplex AlternateAddress 64BitSupport
> # netstat -v
> -------------------------------------------------------------
> ETHERNET STATISTICS (ent0) :
> Device Type: IBM PCI Ethernet Adapter (22100020)
> Hardware Address: 08:00:5a:ba:96:a0
> Elapsed Time: 0 days 5 hours 12 minutes 2 seconds
>
> Transmit Statistics: Receive Statistics:
> -------------------- -------------------
> Packets: 607 Packets: 8684
> Bytes: 55605 Bytes: 479218
> Interrupts: 0 Interrupts: 8684
> Transmit Errors: 0 Receive Errors: 0
> Packets Dropped: 0 Packets Dropped: 0
> Bad Packets: 0
> Max Packets on S/W Transmit Queue: 4
> S/W Transmit Queue Overflow: 0
> Current S/W+H/W Transmit Queue Length: 1
>
> Broadcast Packets: 9 Broadcast Packets: 8089
> Multicast Packets: 2 Multicast Packets: 386
> No Carrier Sense: 0 CRC Errors: 0
> DMA Underrun: 0 DMA Overrun: 0
> Lost CTS Errors: 0 Alignment Errors: 0
> Max Collision Errors: 0 No Resource Errors: 0
> Late Collision Errors: 0 Receive Collision Errors: 0
> Deferred: 0 Packet Too Short Errors: 0
> SQE Test: 0 Packet Too Long Errors: 0
> Timeout Errors: 0 Packets Discarded by
> Adapter: 0
> Single Collision Count: 0 Receiver Start Count: 0
> Multiple Collision Count: 0
> Current HW Transmit Queue Length: 1
>
> General Statistics:
> -------------------
> No mbuf Errors: 0
> Adapter Reset Count: 25
> Driver Flags: Up Broadcast Running
> Simplex AlternateAddress 64BitSupport
>
> IBM PCI Ethernet Adapter Specific Statistics:
> ------------------------------------------------
> Chip Version: 16
> Packets with Transmit collisions:
> 1 collisions: 0 6 collisions: 0 11 collisions: 0
> 2 collisions: 0 7 collisions: 0 12 collisions: 0
> 3 collisions: 0 8 collisions: 0 13 collisions: 0
> 4 collisions: 0 9 collisions: 0 14 collisions: 0
> 5 collisions: 0 10 collisions: 0 15 collisions: 0
> #
>
> I do not know how to find out what is the specs from this output though;
> it really does not tell me much. That said, I did find the quick
> installation booklet and it did say it was a 10BaseT port.

This is a 10Mbps (only) card. It can be set to full or half
duplex, but I would set the switch port to match and not rely
on auto negotiation. Other than 'adapter resets', the netstat
values look good, so your cable is probably ok. I am not sure
what 'adapter resets' means for that card, but you could continue
to monitor it with netstat and see if that count corresponds to
any errors logged in the switch.

http://publib.boulder.ibm.com/infoce...thernet_dd.htm
(expand the 'Configuration Parameters' section).

Paul Landay