MHonArc test archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Traffic shaping problem with pca200e

I think we have the same problem. I'm not any good at Linux ATM, but I can try to explain our problem.

We have a PCA200E, atm 0.31, kernel 2.0.29 on a AMD K6-300 with 128Mb RAM. We are running CLIP.  Our ISP uses a Newbridge ATM switch. 

Everything is working fine - exept traffic shaping.

Our contract says 2Mbit/s. We are shaping at 2Mbit/s CBR. But our ISP must put their shaping at 60 Mbit/s!! Else we get a lot of dropped cells. <40 byte ping is OK. >100 byte ping results in dropped cells.

We have no solution for this problem. I heard that the PCA200e don't support full hardware shaping. I don't now if this is correct.

Ronnie Lindgren

-----Ursprungligt meddelande-----
Fr&egr;n: Christos V. Stathis <>
Till: <>
Kopia: Vassilis N. Merekoulias <>
Datum: den 1 september 1999 21:10
&Dgr;mne: Traffic shaping problem with pca200e

>Hi all,
>we have set a testbed of linux atm machines at our lab in NTUA.
>We want to measure the performance of  IP over UBR and CBR ATM connections
>over congested atm backbone links.
>The set up is the following:
>WS1 ----------- ASX200BX ----------- WS2
>The nics at our WS are:
>WS1: PCA200E Rev C Adapter
>     Slackware linux, kernel 2.1.106 + atm 0.38 + pca200e-0.4 driver
>WS2: FORE LE 155 adapter
>     Slackware linux, kernel 2.2.9 + atm 0.59 + IDT77201 (NICStaR) driver
>We tried a very "simple" (we thought at the begining that is going to be
>simple :) ) scenario:
>Inject traffic over a CBR PVC at 17Mbps that we configured at both the NICs
>of the WSs and the asx200.  Everything seems to work fine, as we try pinging
>with the default 64byte icmp packet.
>BUT (here we go :)) as we try pinging with 1024byte icmp packets, we get
>many (from an optimistic point of view :( ) dropped cells at the port of the
>ASX200 that the WS1 is connected (the one with the PCA200E).  From my
>experience this seem to be a traffic shaping problem.  The WS1 is injecting
>cells everytime an ICMP echo-req is transmited, faster than the conntract
>(CBR 17Mbps) resulting in dropped cells... :(
>We tried injecting traffic using ttcp. The result is as expected (that means
>dropped cells again):
>    When we originate traffic from WS1 => WS2 we get a lot of dropped cells
>and almost nothing going through.
>    When we originate traffic from WS2 => WS1 everything is working fine.
>That is something "normal" as ttcp server sends back to the client only an
>ACK of the data reception.
>What I get from all the above, if I don't miss something, is that the
>policing mechanism of WS1 is not working properly.  I hope it's a
>configuration problem of kernel - atm - driver and not something else and
>with some help we will overcome this :) .
>Any help is appreciated.
>Best regards
>Christos V. Stathis - Vassilis N. Merekoulias
>Network Management and Optimal Design Laboratory (NETMODE)
>Iroon Politechneiou 9, 157 80 Zografou
>Tel: +301-7721448, Fax: +301-7721452

Home | Main Index | Thread Index