[c-nsp] mlppp performance

[Adam Greene]

Thanks for the on- and off-list replies. Seems that mlppp performance issues 
are a common problem .... No clear solution seems in sight yet, besides 
perhaps increasing the speed of the component links to get an overall 
increase in bundled speeds.

Thanks,
Adam


----- Original Message ----- 
From: "Ben Steele" <ben at internode.com.au>
To: "Adam Greene" <maillist at webjogger.net>
Cc: <cisco-nsp at puck.nether.net>
Sent: Monday, March 31, 2008 8:17 PM
Subject: Re: [c-nsp] mlppp performance


> One bit of advice I can offer to this is make sure all 4 lines are 
> exactly the same speed, shape them if you have to, mis-matched speed  on 
> mlppp can result is sub optimal performance for the entire bundle.
>
> Ben
>
> On 01/04/2008, at 4:13 AM, Adam Greene wrote:
>
>> Hi,
>>
>> I'm bonding (4) aDSL lines at a customer location and am only seeing 
>> about 66 - 75% of the performance I was expecting. Is this normal? I 
>> wonder if an IOS upgrade will help things.
>>
>> I actually have two customer locations experiencing the same issue.  The 
>> client routers are 2811's with 512MB RAM running IOS 12.3(8)T6.  They are 
>> plain vanilla configs, running at ~2% CPU with lots of  memory to spare. 
>> The head end is a 7205 / NPE200 w/ 128MB RAM and  IOS 12.3(15b), 
>> terminating about 100 ATM aDSL lines. CPU is at about  14% and memory 
>> utilization is low.
>>
>> The head end reports:
>>
>> Multilink3,
>>  Bundle up for 11:29:07, 1/255 load
>>  Receive buffer limit 48768 bytes, frag timeout 1000 ms
>>    0/0 fragments/bytes in reassembly list
>>    5 lost fragments, 1046793 reordered
>>    0/0 discarded fragments/bytes, 0 lost received
>>    0x30FA03 received sequence, 0x4C98A7 sent sequence
>>  Member links: 4 active, 1 inactive (max not set, min not set)
>>    Vi7, since 11:29:07
>>    Vi8, since 11:29:05
>>    Vi4, since 11:28:59
>>    Vi9, since 11:27:50
>>    Vt3 (inactive)
>>
>> Customer end:
>>
>> Multilink1,
>>  Endpoint discriminator is xxx
>>  Bundle up for 11:28:50, 7/255 load
>>  Receive buffer limit 48768 bytes, frag timeout 1000 ms
>>    0/0 fragments/bytes in reassembly list
>>    137 lost fragments, 1453838 reordered
>>    86/57363 discarded fragments/bytes, 0 lost received
>>    0x4C7B86 received sequence, 0x30F120 sent sequence
>>  Member links: 4 active, 1 inactive (max not set, min not set)
>>    Vi4, since 11:28:48
>>    PPPoATM link, ATM PVC 0/35 on ATM0/3/0
>>    Packets in ATM PVC Holdq: 0 , Particles in ATM PVC Tx Ring: 0
>>    Vi5, since 11:28:42
>>    PPPoATM link, ATM PVC 0/35 on ATM0/0/0
>>    Packets in ATM PVC Holdq: 0 , Particles in ATM PVC Tx Ring: 0
>>    Vi6, since 11:27:33
>>    PPPoATM link, ATM PVC 0/35 on ATM0/2/0
>>    Packets in ATM PVC Holdq: 0 , Particles in ATM PVC Tx Ring: 0
>>    Vi3, since 11:28:50
>>    PPPoATM link, ATM PVC 0/35 on ATM0/1/0
>>    Packets in ATM PVC Holdq: 0 , Particles in ATM PVC Tx Ring: 0
>>    Vt1 (inactive)
>>
>> Thanks for any insight.
>> Adam
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
>
>
>