I should probably mention some real numbers, since I agree, but the
difference I am seeing is too large for that. For a 50m policer with a
128k burst, I get from 25Mbits/s to 32Mbits/s, using a 10s average.
Increase the burst to 512k, and the range goes up to 30-35Mbits/s.
Increase the burst to 1024k, and the range stays at 30-35Mbits/s.
I've put some TCP graphs from a 50m policer at
http://www1.martnet.com/~nikw/policer/ in case you want to take a look.
They should be worth at least a few words.
nikw
On Tue, 10 Apr 2001, Jack Billings wrote:
> 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