No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>


To have a better experience, please upgrade your IE browser.


A Long Delay for Users Connected to an ME60 Due to Different CAR mechanisms on the ME60 and MA5200G

Publication Date:  2013-09-29 Views:  63 Downloads:  0
Issue Description
After user data was migrated from an MA5200G to an ME60, a dial-up user with a 10 Mbit/s bandwidth used P2P software for download. The user pinged a site when the 10 Mbit/s bandwidth was not used up. The delay was 100 ms. Before the migration, the delay was 20 ms.
Handling Process

Huawei analyzed the issue as follows:

An ME60 implemented CAR for users using TM. A queue was used for each user. When the load for a user was full, traffic was buffered in the queue. The buffered traffic was not processed until the load became light. Therefore, when the user performed heavy-traffic download, much bandwidth was used and traffic of other applications was buffered in the queue. In this case, no packet was lost, but the delay was long.

An MA5200G implemented CAR using NP. Each port had multiple queues. Multiple users shared a large queue. Therefore, even if the bandwidth would be used up soon, the delay did not change significantly.
Root Cause

Huawei performed the following operations to resolve this issue:

Performed the following configuration in the domain: /*Used to trigger queue scheduling*/

 user-max-session  1  

 user-group xx    

Performed the following configuration at the port through which a user went online: /*Use to add the user to the default queue. none means adding a user to the default queue instead of performing queue scheduling for the user.*/

 qos schedule none

After the preceding configuration, the queue bandwidth was high enough so that the delay would not be too long.