netdev
[Top] [All Lists]

Re: [RFC-2] Configuring Synchronous Interfaces in Linux

To: gparrott@xxxxxxxxxx (Greg Parrott)
Subject: Re: [RFC-2] Configuring Synchronous Interfaces in Linux
From: Robert Olsson <Robert.Olsson@xxxxxxxxxxx>
Date: Tue, 5 Dec 2000 16:55:48 +0100 (CET)
Cc: netdev@xxxxxxxxxxx
In-reply-to: <3A2D068E.604FE486@lucent.com>
References: <E143Ebi-000500-00@the-village.bc.nu> <3A2D068E.604FE486@lucent.com>
Sender: owner-netdev@xxxxxxxxxxx
Offtopic.

And I was happy being able to saturate an OC-48 Link with four Linux boxes
equipped with GIGE. :-) 1440 byte packets and a combination of three acenic's 
and one e1000 NIC.

(Cisco output)

POS1/0 is up, line protocol is up
  Hardware is Packet over SONET
  Description: STM16 connection to STK-PR-2
  Internet address is XXX.XXX.XXX.XXX/MM
  MTU 4470 bytes, BW 2400000 Kbit, DLY 100 usec, rely 255/255, load 255/255
  Encapsulation HDLC, crc 32, loopback not set
  Keepalive set (10 sec)
  Scramble enabled
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 01:02:17
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  30 second input rate 7000 bits/sec, 4 packets/sec
  30 second output rate 2400361000 bits/sec, 210413 packets/sec
                        ^^^^^^^^^^^^^^^^^^
     185427805 packets input, 2538532250 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
              0 parity
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     1106539583 packets output, 1462397823 bytes, 0 underruns
     0 output errors, 0 applique, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

                                                --ro

Greg Parrott writes:
 > I have a vested interest in how this all turns out.  I own a Packet Over 
 > SONET
 > device driver for our OC-12 and OC-48 NICs that I currently pass all 
 > parameters
 > to the driver via arguments on the insmod.  To avoid lengthy commands, we
 > provide the common defaults.  We accept some basic ifconfig input, but with
 > SONET/SDH and chip specific items that needed to be controlled, ifconfig did 
 > not
 > seem the way to go.

<Prev in Thread] Current Thread [Next in Thread>