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