Some of what you are seeing is probably based on TCP slow start
and backoff. What application are you using to generate UDP packets?
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?
Have you discussed this with your account team or JTAC?
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