On Tuesday 17 July 2007 12:44, Dennis Breithaupt wrote: > Hello, > > I've some questions on that topic, too :) > > On Tue, 17 Jul 2007 10:55:41 +0200, Ivan Gasparik <[EMAIL PROTECTED]> wrote: > > Hello, > > > > The right place to activate policy-map in case of DSL WAN > > connection is PVC inside interface ATM0: > > > > interface ATM0 > > pvc x/y > > cbr <speed> > > service-policy output voice > > What exactly does the "cbr"-adjustment do under the pvc? Does it > have an real effect on data flow or is it just an > administrative/management configuration?
Yes, cbr is a shaping method at ATM layer. There are other methods too (vbr, ubr, ... - I'm not an ATM expert :-)), but we use for our customers only cbr. > > We're having the problem, that we have a load auf 100% on our > ADSL-lines on the upstream, because we're uploading massive > background traffic. That leads to horrible high latency times. So > we want to achieve, that we're only using i.e. 80% of the upload > bandwidth. In my opinion the high latency is caused by default setting of tx-ring-limit buffer. This buffer is applied in hardware after software queueing configured in policy-map. So in case of fully exhausted upload your policy-map will do it's work, but the hardware queue will add several hundred miliseconds latency to all outgoing packets (depends on average packet lenght). You can decrease the value of tx-ring-limit buffer and decrease the time that takes a packet to pass through the interface. VoIP traffic configured in policy-map to take strict priority will pass more quickly and all other traffic will be queued in software (class-default in policy-map) instead of hardware in case of congested interface. > > Sadly we can't use "bandwidth average" in the service policy, > because the 836 (in our case), but I think the 876, too, can't > shape on ATM. (afaik) > > Is that the case? Our has cbr an effect on bandwidth limiting, too? Yes, cbr does ATM traffic shaping. > > Can I also combine WRED with this adjustment? My tries with WRED > were not successfull, because the OutQ was always "0". WRED is supported in class-default, just configure random-detect inside it. Fair queueing is also a good choice. Ivan > > Thanks, regards, > > Dennis > [...] > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
