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@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp