[j-nsp] FW: strict-high priority queue
Eric Van Tol
eric at atlantech.net
Wed Jun 14 11:53:46 EDT 2006
Harry, the config does spit out an error if I commit and the configured
rates are over 100%. However, I had modified the be-class queue to use
less of a percentage so that all 4 queues added up to 100%. Unless I'm
misinterpreting what you're saying, I don't think that was the issue.
It looks like I might have to open up a JTAC case on this one - I
wouldn't want you wasting your time troubleshooting this if JTAC can do
it.
Also, cosd logs don't show anything unusual to me. Just a bunch of
these about once or twice a day:
Jun 14 10:47:48 main: Detected non-fabric-based chassis
Jun 14 10:47:48 main: started: check=1, nuke=0 pid=24161
Jun 14 10:47:48 read net.link.agg.ae_max_links 8
Thanks,
evt
-----Original Message-----
From: Harry Reynolds [mailto:harry at juniper.net]
Sent: Wednesday, June 14, 2006 11:41 AM
To: Eric Van Tol; juniper-nsp at puck.nether.net
Subject: RE: [j-nsp] FW: strict-high priority queue
Still looking into this. Word back from folks smarter than me is that
you have exceeded 100% rate total when setting the SH class above 35%,
which then results in a failure to load the configured cos settings,
which in turn is like having default cos.
You may want to search the messages log matching on "cosd" to see if
there are messages that your config is invalid.
It seems that newer code, 8.0B2 for example, will reject such a config
at commit:
[edit class-of-service]
harry at moe# commit check
configuration check succeeds
[edit class-of-service]
harry at moe# show
drop-profiles {
non-tcp-low-red {
fill-level 80 drop-probability 10;
}
tcp-high-red {
fill-level 50 drop-probability 10;
}
tcp-low-red {
fill-level 40 drop-probability 10;
}
non-tcp-high-red {
fill-level 30 drop-probability 30;
}
}
interfaces {
so-0/0/0 {
scheduler-map test;
}
}
scheduler-maps {
test {
forwarding-class best-effort scheduler be-scheduler;
forwarding-class network-control scheduler nc-scheduler;
forwarding-class assured-forwarding scheduler af-scheduler;
forwarding-class expedited-forwarding scheduler ef-scheduler;
}
}
schedulers {
be-scheduler {
transmit-rate percent 50;
buffer-size percent 50;
priority low;
drop-profile-map loss-priority low protocol non-tcp drop-profile
non-tcp-low-red;
drop-profile-map loss-priority high protocol tcp drop-profile
tcp-high-red;
drop-profile-map loss-priority low protocol tcp drop-profile
tcp-low-red;
drop-profile-map loss-priority high protocol non-tcp
drop-profile non-tcp-high-red;
}
nc-scheduler {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
af-scheduler {
transmit-rate percent 10;
buffer-size percent 5;
priority high;
}
ef-scheduler {
transmit-rate percent 35;
buffer-size percent 5;
priority strict-high;
}
}
[edit class-of-service]
harry at moe# set schedulers ef-scheduler transmit-rate percent 40
[edit class-of-service]
harry at moe# commit check
[edit class-of-service]
'scheduler-maps test'
Total bandwidth allocation exceeds 100 percent for scheduler-map
test
error: configuration check-out failed
[edit class-of-service]
harry at moe# run show version
Hostname: moe
Model: m5
JUNOS Base OS boot [8.0B2]
JUNOS Base OS Software Suite [8.0B2]
JUNOS Kernel Software Suite [8.0B2]
JUNOS Packet Forwarding Engine Support (M5/M10) [8.0B2]
JUNOS Routing Software Suite [8.0B2]
JUNOS Online Documentation [8.0B2]
I am loading up 7.6R2 in an attempt to verify if it allows the commit of
a config in which explicit SH tx-rate results in > 100% weights being
assigned.
Regards
> -----Original Message-----
> From: juniper-nsp-bounces at puck.nether.net
> [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Eric Van Tol
> Sent: Wednesday, June 14, 2006 7:37 AM
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] FW: strict-high priority queue
>
> Thanks, Harry. I'm on an M20 running 7.5R2.8 and found that
> when modifying the strict-high queue's transmit-rate
> percentage above 35%, the queue would suddenly start dropping
> packets. My strict-high queue is configured for
> expedited-forwarding of voice traffic and even with only a
> single 80k G.711 stream, the strict-high would drop packets
> if configured at 40% transmit-rate. The ef-class queue is
> using the default drop profile:
>
> be-scheduler {
> transmit-rate percent 50;
> buffer-size percent 50;
> priority low;
> drop-profile-map loss-priority low protocol non-tcp
> drop-profile non-tcp-low-red;
> drop-profile-map loss-priority high protocol tcp
> drop-profile tcp-high-red;
> drop-profile-map loss-priority low protocol tcp
> drop-profile tcp-low-red;
> drop-profile-map loss-priority high protocol non-tcp
> drop-profile non-tcp-high-red; } nc-scheduler {
> transmit-rate percent 5;
> buffer-size percent 5;
> priority high;
> }
> af-scheduler {
> transmit-rate percent 10;
> buffer-size percent 5;
> priority high;
> }
> ef-scheduler {
> transmit-rate percent 35;
> buffer-size percent 5;
> priority strict-high;
> }
>
> I've read in a C-vendor book that the serialization process
> is a determining factor with real-time traffic on T1/E1 links
> and they don't recommend setting a strict-high queue to more
> than 33%. It's unclear to me whether this is specific to the
> C-vendor implementation of low latency queuing or a general
> rule of thumb.
>
> evt
>
> -----Original Message-----
> From: Harry Reynolds [mailto:harry at juniper.net]
> Sent: Tuesday, June 13, 2006 6:46 PM
> To: Eric Van Tol; juniper-nsp at puck.nether.net
> Subject: RE: [j-nsp] FW: strict-high priority queue
>
> Alright, so out from the woodwork I crawl.
>
> I did a little research and tend to think that the IE book is
> in need of an update on this regard, and I have made due note.
>
> Below is a jni thread (with names/addresses removed) that may
> shed light on your issue, but I'm not sure because you
> indicate SH drops occur when you alter transmit-weight. The
> thread summary is that the rate assigned to a strict-high
> does not affect the SH queue, but *is* factored into the
> calculations for the total WRR% available to other queues.
> This means that changing the rate assigned to a strict-high
> can have an impact on drop performance for the other queues,
> and in this regard the IE book is misleading. At the same
> time, the thread I've pasted indicates that one should assign
> the expected rate to the SH queue, which is at odds with the
> tech pub example you cite. I will ping the developers to see
> if they can set the record straight. You may want to post
> additional details such as SW/HW version, as your description
> of loss in the SH class does not match any expected behaviors
> I am aware of.
>
>
> Regards
>
> Harry
>
>
> [scrubbed thread]
>
> My experience was, that transmit rate for SHP queue has
> influence on behavior of ... rest of queues.
>
> To be more detail:
>
> - SHP queue has effectively no limits and can consume all
> bandwidth of interface, but:
>
> - if you have other queue marked as high prority (not
> strict), as long as this queues are positive (in bandwidth)
> scheduler consider transmit rate of SHP and all HP when they
> decide from which queue packet should be taken. When HP and
> SHP queues goes to deficit, then SHP is still served by
> scheduler, as they will be in positive.
>
> - The other site effect is when you use transmit rate
> percentage. If you not specify rate for SHP, then trans mit
> rate of remaining queues will be aligned to 100%, then
> effective guaranteed rate will be too high, because SHP
> traffic volume is not taken to account.
>
> So, my advice:
>
> - Specify transmit rate for SHP queues at level of expected
> traffic volume,
> - Use policer to avoid 100% of bandwidth eated by SHP traffic
> (if applicable).
> - in addition for SHP use HP queues for NetControll traffic.
>
>
> X x x x x x
> Professional Services Consultant
>
> Juniper Networks
>
> -----Original Message-----
> From: xxxxxxxx
> Sent: 03 May 2006 20:18
> To: xxxxxx
> Subject: Re: FW: [q] transmit rate for the strict high queue
>
> > Could you please comment, what the semantics is for the
> transmit rate
> > assigned to the strict high queue (M/T)?
> > In other words, what happens if I change the rate on the
> strict high
> > queue?
>
> My understanding is that when using a strict high queue we
> essentially add 100% to whatever transmit-rate is specified.
> This makes the rate meaningless (and you might as well not
> include one) since it will never be below 100% and as such
> will never be negative.
>
> [/thread]
>
>
> > -----Original Message-----
> > From: juniper-nsp-bounces at puck.nether.net
> > [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
> Eric Van Tol
> > Sent: Tuesday, June 13, 2006 3:20 PM
> > To: juniper-nsp at puck.nether.net
> > Subject: [j-nsp] FW: strict-high priority queue
> >
> > Sorry for the duplicate post, but I haven't gotten any
> feedback on the
> > questions presented below. I was hoping this would be
> something that
> > could be answered here, since some of the authors of the
> Sybex books
> > are members of the list.
> >
> > Thanks,
> > evt
> >
> > Subject: [j-nsp] strict-high priority queue
> >
> > Hi all,
> > I've been doing some testing with QoS configs and according to the
> > following page:
> >
> > http://www.juniper.net/techpubs/software/junos/junos76/swconfi
> > g76-cos/ht
> > ml/cos-scheduler-maps9.html
> >
> > if a queue is configured with a strict-high priority setting, the
> > transmit-rate has no effect because the strict-high is
> given the full
> > interface bandwidth. However, from what I've seen, the if the
> > 'transmit-rate' is configured for strict-high, it does have
> at least
> > some effect. For instance, when configuring any rate greater than
> > about 35%, the strict-high queue starts to drop packets.
> >
> > In addition, it states that queues configured with strict-high
> > *shouldn't* be configured with a transmit-rate. However,
> on page 655
> > of the Sybex JNCIE book, the expedited-forwarding queue is
> strict-high
> > with a transmit-rate.
> >
> > Two questions:
> >
> > 1. Why does strict-high drop packets when configured with
> too high of
> > a transmit-rate?
> > 2. Which method is correct? The JNCIE example or the JUNOS docs?
> >
> >
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>
More information about the juniper-nsp
mailing list