To have a better experience, please upgrade your IE browser.upgrade
Questo sito utilizza cookie di profilazione (propri e di terze parti) per ottimizzare la tua esperienza online e per inviarti pubblicità in linea con le tue preferenze. Continuando a utilizzare questo sito senza modificare le tue preferenze acconsenti all’uso dei cookie. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie clicca qui>
The website that you are visiting also provides Arabian language. Do you wish to switch language version?
يوفر موقع الويب الذي تزوره المحتوى باللغة العربية أيضًا. هل ترغب في تبديل إصدار اللغة؟
The website that you are visiting also provides Russia language Do you wish to switch language version?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
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.
Huawei performed the following operations to resolve this issue:
Performed the following configuration in the domain: /*Used to trigger queue scheduling*/
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 noneAfter the preceding configuration, the queue bandwidth was high enough so that the delay would not be too long.