[j-nsp] Output queue drops and temporal buffers

[John Neiberger]

This particular router is running 9.6R4.4 (yeah, I know...) and the
linecard is a DPCE-R-40GE-TX. Thanks to some prodding by someone else, I
took a look at the drop profile configured and see that this queue will
start WRED drops at 70%, which amounts to just 880 KB or so. I guess we
must be seeing short bursts of traffic that hit the drop threshold for that
queue, but they total traffic is low enough that it doesn't move the
average throughput much. Our traffic monitoring tools don't show any
increase at all, but the output discards go up considerably occasionally. I
wouldn't have expected to see that many drops when the average interface
utilization is around 10%, but it's clearly happening.

Thanks,
John


On Tue, Oct 1, 2013 at 2:46 PM, <david.roy at orange.com> wrote:

> Hi
>
> We experienced unexpected drops with temporal buffer (which is a static
> buffer) and iCHIP based cards. It was in junos 11.4. Jtac had found an
> internal PR that matched our issue.
>
> Workaround was the using buffer-size in %.
>
> Which version and cards do you use?
>
> David
>
> Envoyé de mon iPad
>
> > Le 1 oct. 2013 à 21:13, "John Neiberger" <jneiberger at gmail.com> a écrit
> :
> >
> > I've been troubleshooting an interesting problem off and on the past
> couple
> > of days. We have a 1-gig link that is consistently running around 10%
> > utilization, give or take a couple of percent, but we see periods where
> the
> > egress WRED drops for queue 0 spike. It's bizarre because there is no
> > corresponding increase in overall utilization. I don't know much about
> > queueing on this platform (MX960), but I've been reading up on it today.
> > Here is the config for that queue:
> >
> > TRAFFIC-CLASS-1-SCHEDULER {
> >    transmit-rate percent 20;
> >    buffer-size temporal 50k;
> >    priority low;
> >    drop-profile-map loss-priority low protocol any drop-profile DROP-LOW;
> >    drop-profile-map loss-priority high protocol any drop-profile
> DROP-HIGH;
> >
> > As I understand it, the formula to determine available buffer space is
> this:
> >
> > bandwidth * transmit-rate percent * temporal buffer size
> >
> > On a 1-gig link, I think that means that queue has a total buffer size of
> > 1.25 MB. I'm guessing that means that we must be getting large-ish chunks
> > of data big enough to come close to filling that queue but intermittent
> > enough that the average rate doesn't go up noticeably.
> >
> > My question regarding the config is this: if we are already setting the
> > transmit rate percentage, why would we also configure a temporal
> > allocation? Isn't a percentage of the available bandwidth sufficient?
> What
> > does adding a temporal allocation buy us? Is the transmit rate percent
> just
> > setting how often that queue is serviced, while the buffer-size
> configures
> > the queue depth?
> >
> > Thanks,
> > John
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>