From: Wang Dehong-DWANG1 (Dehong.Wang@motorola.com)
Date: Fri Jul 30 2004 - 12:58:52 GMT-3
correct me if I am wrong:
map-class frame-relay frts
frame-relay cir 32000
frame-relay bc 4000 32k/8 = 4000
frame-relay be 4000 64k/8 = 8000 = be + bc, thus be = 4000
frame-relay mincir 16000
frame-relay adaptive-shaping becn
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
James Yeo
Sent: Friday, July 30, 2004 10:43 AM
To: Group Study
Subject: Frame-relay Traffic Shaping Question
I have the following senario from my workbook.
The traffic on the link cannot exceed 64kbps.
The average traffic rate for the PVC is 32kbps.
The BC should be 1/8 the CIR.
The time interval is 125msec.
The service provider is guaranteeing 16kbps of traffic.
The PVC should adapt to receive BECNs.
How would you interpret the question?
Here is what I think...
map-class frame-relay frts
frame-relay cir 64000
frame-relay bc 8000
frame-relay be 6000
frame-relay mincir 16000
frame-relay adaptive-shaping becn
Any comments would be appreciated.
Kind regards
James
----- Original Message -----
From: "ccie2be" <ccie2be@nyc.rr.com>
To: "Daniel Ginsburg" <dginsburg@mail.ru>; "Group Study"
<ccielab@groupstudy.com>
Sent: Friday, July 30, 2004 8:29 AM
Subject: Re: Generating enough pings to make dialer load threshold kick in
> Hi Daniel,
>
> Thanks for that very detailed and insightful explanation. It is truly very
> appreciated and helpful.
>
> Do you recall seeing a post yesterday from Richard Dumoulin. He suggested
> creating 4 telnet sessions and pinging simultaneously from all 4 telnet
> sessions to generate a greater traffic load.
>
> I asked him how exactly to do that but didn't hear back. Have any ideas
> about how I could do that?
>
> Thanks again. Tim
>
>
> ----- Original Message -----
> From: "Daniel Ginsburg" <dginsburg@mail.ru>
> To: "Group Study" <ccielab@groupstudy.com>
> Sent: Friday, July 30, 2004 10:11 AM
> Subject: Re: Generating enough pings to make dialer load threshold kick in
>
>
> > As far as I know timeout parameter affects only how long router waits
> > for reply before printing '.' instead of '!'.
> >
> > I ran ping with default timeout, with 0 timeout and with timeout 100.
> > All three completed in approximately same time. My conclusion is that
> > rate of packets dictated only by round-trip time.
> >
> > Please note that 50% is upper bound. It can be significantly less is
> > case of LFN (long fat pipe).
> >
> >
> > On Fri, Jul 30, 2004 at 03:56:58PM +0200, Richard Gallagher wrote:
> > > What about setting the timeout to zero? Then we don't ever hang around
> > > and wait for a response. We just send as fast as the router can.
> > >
> > > On Fri, 2004-07-30 at 15:29, Daniel Ginsburg wrote:
> > > > On Thu, Jul 29, 2004 at 10:50:38AM -0400, ccie2be wrote:
> > > > > Hey Richard,
> > > > >
> > > > > I don't dispute or disagree with what you're saying but how do
know
> that 4
> > > > > simultaneous pings with a packet size of 1500 will load the
channel
> to over
> > > > > 80%? How do you know what load exactly that will put on the
> channel? If
> > > > > you don't know exactly what load that puts on the channel, how do
> you know
> > > > > that that is NOT, for example, a 65% load or 75 % load?
> > > > >
> > > >
> > > > Unlike many other ping implementations which send 1 echo request per
> > > > interval cisco's one sends next echo request as soon it receives
echo
> > > > reply or waits for timeout if request or reply is lost. So average
> > > > bandwidth utilization in one direction with one 'ping a.b.c.d size
X'
> > > > will never exceed 50%.
> > > >
> > > > Let me illustrate this with the diagram
> > > >
> > > > ---
> > > > ^ BW
> > > > |
> > > > | (1) (3) (5)
> > > > |----- ----- -----
> > > > |
> > > > | (2) (4)
> > > > ----------------------------------------->
> > > > Time
> > > >
> > > > (1) router transmits ping request
> > > > (2) router waits for ping reply
> > > > (3) router transmits next ping request
> > > > (4) router waits for next ping reply
> > > > etc.
> > > >
> > > > So router uses the link almost[1] exactly half of the time. Please
> note
> > > > that this 50% figure almost[1] doesn't depend on size of echo
> > > > request/reply.
> > > >
> > > > [1] I'm saying almost because router needs to ponder a very short
> period
> > > > of time before replying to echo request. This period of time may be
> > > > negligible or not depending on speed of the link.
> > > >
> > > > Two simultaneous pings will theoreticaly saturate the link. Run four
> to
> > > > make sure ;)
> > >
> > >
This archive was generated by hypermail 2.1.4 : Sun Aug 01 2004 - 10:12:07 GMT-3