Hi Nikolas,
The IP-II rate limits IP payload. When I was doing some testing it took me
a bit to recognize this and calculate in the overhead for the media type
and frame size being used. For ethernet once I took into account the frame
size, ipg, preamble, sfd etc I was able to tie out to the values configured
in the policer.
Jack.
At 02:34 PM 4/10/2001, Nikolas Weidenbacher wrote:
>On Tue, 10 Apr 2001, dave o'leary wrote:
> > Some of what you are seeing is probably based on TCP slow start
> > and backoff. What application are you using to generate UDP packets?
>
>Well, yes, TCP is certainly using its normal means to deal with packet
>loss. What I'm trying to do is understand the interaction between TCP
>and
>the policer.
>
>I'm using iperf (http://dast.nlanr.net/Projects/Iperf/) to generate both
>TCP and UDP. I'm using tcpdump/tcptrace and some of my own perl to look
>at (graph, that is) TCP performance and packet-over-time distributions.
>
> > How long have you let the test run and do the numbers work out over
> > time such that 30 Mb/s is the amount of traffic received?
>
>I have never seen (for example) 30 Mb/s achieved over any interval from
>1
>second to one minute with a 30m policer. (Increasing the burst size
>helps.)
>
>I have seen 1Mb/s achieved through a 1Mb/s policer. In other words, if
>I
>use a small enough percentage of the "true" available bandwidth, it all
>gets through, because TCP has enough time to recover 4 (or so) times per
>second.
>
>Keep in mind that this is all local ethernet, so the bandwidth*delay is
>low. If I introduce latency into the picture, I expect throughput to go
>down a bit more.
>
> > Have you discussed this with your account team or JTAC?
>
>Erm, not yet, although I think my account team might know about it by
>now.
>I don't have a problem as such, I'm just doing some research, and was
>hoping to get some input from someone else doing this in the field.
>
>nikw
>
>
> > thanks,
> > dave
> >
> > At 11:36 PM 4/9/01 -0400, Nikolas Weidenbacher wrote:
> >
> > >I have been playing with the firewall filter <*> policer,
>particularly
> > >related to performance of large TCP sessions (I would LOVE to be able
>to
> > >get say 30mbits/s through a 30mbit/s policer). I've been testing on
>the
> > >following incredibly simple setup:
> > >
> > >[L1]---[switch1]===[M20]===[switch2]---[L2]
> > >
> > >where:
> > >L1 and L2 are linux-2.2 with 0.5G and dual 667Mhz P-IIIs.
> > >switch1 and switch2 are layer-2 ethernet switches
> > >--- is 100M full-duplex
> > >=== is GE full-duplex, 802.1q
> > >
> > >1. When sending a large TCP stream from L1 to L2 through a policer
>on the
> > >M20, what I see at L2 is a 200-250ms cycle consisting of roughly n ms
>of
> > >steadily rising TCP window followed by roughly 250-n ms of silence,
>where
> > >n is directly proportional to the bandwidth-limit in my policer
>statement,
> > >and in the range of 0 to 200ms.
> > >
> > >2. I see the same thing when sending UDP at relatively low rates
>(<50M),
> > >while rate limiting it at a still lower rate.
> > >
> > >Based on 1 and 2, the policer seems to work like CAR, with a counter
>and
> > >an interval, and the interval appears to be 200ms or so. The
>interval
> > >does not seem to be configurable.
> > >
> > >3. However, when I blast UDP at 100M and rate limit it at a lower
>rate, I
> > >see packets arriving at a MUCH more uniform rate. On closer
>inspection,
> > >there are occasionally (say, 2 to 10 per second) inter-packet gaps
>from 3
> > >to 10 times the size of the average gap, but these don't seem to
>occur at
> > >any regular interval.
> > >
> > >Based on 3, I have no freakin idea how the policer works. In this
>case,
> > >it almost looks like it's CAR with an interval approaching 1 MTU.
> > >
> > >Anyone who knows more about it care to comment?
> > >
> > >(Smaple filter for policing an interface follows)
> > >
> > >firewall
> > >{
> > > filter FIL_policer1
> > > {
> > > policer policer1
> > > {
> > > if-exceeding
> > > {
> > > bandwidth-limit
> > > 5m;
> > > burst-size-limit
> > > 512k;
> > > }
> > >
> > then
> > discard;
> > > }
> > >
> > term 1
> > {
> > > then policer
> > > policer1;
> > > }
> > >
> > }
> > >}
> > >
> > > Nik Weidenbacher nikw@sgns.net
> > > Network Engineer 215-351-1067
> > > Sungard eSourcing
> > >
> >
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:42 EDT