RE: How to guarantee the latency

From: gladston@br.ibm.com
Date: Tue Sep 06 2005 - 09:02:02 GMT-3


That would explain why it does not make sense.

Cordially,
------------------------------------------------------------------
 Gladston

"Scott Morris" <swm@emanon.com>
05/09/2005 23:57
Please respond to
<swm@emanon.com>

To
Alaerte Gladston Vidali/Brazil/IBM@IBMBR
cc
<aarumuga@hotmail.com>, <ccielab@groupstudy.com>, "'Stefan Grey'"
<examplebrain@hotmail.com>
Subject
RE: How to guarantee the latency

If SPEED between them is 56K, then I'd start looking at what other pieces
were mentioned (alone which is what I read at the bottom of these threads)
nearby to give the whole picture.

If the speed is considered to be 56K (as in shaping), then you may get
into
a LFI/frame-relay fragmentation scenario. Either way, the part "the queue
is 640K" doesn't belong. If you're looking at a 56K line, they may say
the
optimum frame size has been determined to be 640 which would be about
right
in a voice integration setup. Then you'll use LFI (if PPPoFR) or
Frame-Relay Fragmentation in the map class. But it's not measured in K,
it's just measured in bytes.

Now, I hate to be the bearer of bad tidings here, but since we're spending
so much time on this, and it's a not-real-well worded thing, the little
bells in my head are going off about someone trying to remember what their
lab said and why they didn't get the points. The scenario as quoted makes
no sense. So are we trying to reverse engineer someone's real lab?

Scott

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
gladston@br.ibm.com
Sent: Monday, September 05, 2005 1:07 PM
To: swm@emanon.com
Cc: aarumuga@hotmail.com; ccielab@groupstudy.com; 'Stefan Grey'
Subject: RE: How to guarantee the latency

Sorry Scott, I mean the value, 640k.
The poster said "The optimum situation is when the speed between them is
56k and the queue is 640k"

...and you posted that it should use priority 640.

Could you explain the logic between "the queue is 640k" and 'priority
640'?

I am wondering what I am missing, because I associated 'queue is 640k' to
setting the deep of the queue, not the bps on the priority command.

Cordially,
------------------------------------------------------------------
Gladston

"Scott Morris" <swm@emanon.com>
05/09/2005 13:52
Please respond to
<swm@emanon.com>

To
Alaerte Gladston Vidali/Brazil/IBM@IBMBR
cc
<aarumuga@hotmail.com>, <ccielab@groupstudy.com>, "'Stefan Grey'"
<examplebrain@hotmail.com>
Subject
RE: How to guarantee the latency

According to the original post:

> > The router R1 is configured to router BB2. The latency should be
> > guaranteed between them. The optimum situation is when the speed
> > between them is 56k
> > and the queue is 640k. And the connecteion between R1 and BB2 is
> > ethernet.

Now, with certain things in mind:

1. The connection is ethernet. At this speed, there is no worry about
propogation delays here (fragmentation and interleave)

2. The idea is to guarantee the latency. This is strange wording, but
one
should assume this means the best latency (e.g. lowest) possible.

3. So, what we've ascertained is that I need to do some sort of queuing
to
give preference to the packets, and I need low latency. Put 'em together
and you get 'low latency queuing' which is a feature of the MQC command
set
and "priority" keywords.

HTH,

Scott

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
gladston@br.ibm.com
Sent: Monday, September 05, 2005 12:31 PM
To: swm@emanon.com
Cc: aarumuga@hotmail.com; ccielab@groupstudy.com; 'Stefan Grey'
Subject: RE: How to guarantee the latency

Scott,

Could you explain how to make that conclusion?

==========================
quoted
The "queue is 640k" refers to using "priority 640"
==========================

Cordially,
------------------------------------------------------------------
Gladston

"Scott Morris" <swm@emanon.com>
05/09/2005 09:05
Please respond to
<swm@emanon.com>

To
"'Stefan Grey'" <examplebrain@hotmail.com>, <ccielab@groupstudy.com>,
Alaerte Gladston Vidali/Brazil/IBM@IBMBR, <aarumuga@hotmail.com>
cc

Subject
RE: How to guarantee the latency

Now, what fun would there be in answering the original question? :)

But yes, Brian is right. In an MQC environment, the "priority" keyword
engages the low-latency queue (catchy name for being the solution
desired!)

Depending on the environment you are in (link speed, etc) it may still be
beneficial to engage in LFI or FRF-based fragmentation so that your voice
packets don't wait for the serialization delay. But that may be beyond
the
scope of the question asked of you.

The "queue is 640k" refers to using "priority 640" in your config. There's
really nothing to do with the number of packets per queue.

HTH,

Scott

-----Original Message-----
From: Stefan Grey [mailto:examplebrain@hotmail.com]
Sent: Monday, September 05, 2005 12:04 AM
To: ccielab@groupstudy.com; swm@emanon.com; gladston@br.ibm.com;
aarumuga@hotmail.com
Subject: RE: How to guarantee the latency

Hello,

I am the original author of the question, below is the complete question
and
the answer on this of the Brian. I still have not the answer on my
question.

As far as I understood the priority command should be used in this case??
HOw should we influence the queue size than? Could anybody. It would be
great if also anybody could give a configuration for this.

Thanks again for everyone,

> Latency is a measurement of delay. Delay can be minimized through
the
>legacy priority-queue or the MQC low latency queue (priority keyword in
>the policy-map).
>
>

> > Hello,
> >
> > The router R1 is configured to router BB2. The latency should be
> > guaranteed between them. The optimum situation is when the speed
> > between them is
>56k
> > and the queue is 640k. And the connecteion between R1 and BB2 is
>ethernet.
> >
> > Any ideas how to solve this?? Should it be policing or shaping or
> > something else? How would you interpret this.
> > Thanks for any input.
> >



This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:14 GMT-3