From: John Gibson (johngibson1541@yahoo.com)
Date: Mon May 14 2007 - 17:51:53 ART
I think I figured out the reasoning they say ingress
is shared mode only.
They don't say it is round-robin.
So, shared mode is not round-robin mode.
Shared mode is round-robin combined with optional
shaping in univercd's internal.
Shaping means someone somewhere counts the bits
and times it. Round-robin means no one times
any thing. Round-robin just sends packets in turn
no time concept.
They have to have some counter somewhere counting the
bits going out from the expedite queue to detect
when expedite queue has maxed its bandwidth that we
configure for it.
--- John Gibson <johngibson1541@yahoo.com> wrote:
> I think when an ingress queue running in expedite
> mode,
> the SRR must be shaping the traffic. I don't
> understand
> why univercd says SRR at ingress does not shape.
>
> Why I think when an ingress queue running in
> expedite
> mode the SRR must be shaping the traffic ?
>
> Consider we keep giving frames to the expedite queue
> so that the expedite queue always has some frames to
> send,
>
> 1. If SRR doesn't shape in this case, the expedite
> queue exhausts the whole bandwidth, then
> the "You can configure the bandwidth required for
>
> this traffic as a percentage of the total traffic
>
> by using..." is wrong. Because your configuration
> of bandwidth is ignored
>
> 2. If the expedite queue doesn't exhaust the whole
> bandwidth and stops sending frames in the
> expedite
> queue every once in a while so that the expedite
> queue doesn't consume more bandwidth than what
> you
> configure, then the expedite queue is not an
> expedite queue by definition.
>
> 3. The bandwidth you configure must be the upper
> limit
> of the expedite queue you want to impose. There
> is no such thing as configuring a minimum
> bandwith
> for an expedite queue. This discussion is over.
>
> Why does univercd say SRR at ingress does not shape
> ?
>
> Why ? Why ? Why ? Why ? Why ? Why ? Why ? Why ? Why
> ?
>
> What is going on ?
>
> Why ?
>
>
>
>
>
This archive was generated by hypermail 2.1.4 : Fri Jun 01 2007 - 06:55:21 ART