policer 1 mbps = 1,000,000 bps, 1,024,000 bps or 1,048,576 bps?

In the C3550 QoS reference
http://www.cisco.com/en/US/products/hw/switches/ps646/products_tech_note09186a00800feff5.shtml
....examples refer to "1 mbps" using "police 1000000":

If the "police 1000 kbps" syntax is used, would that be the same rate as
above, or would "police 1000 kbps" mean 1024000 bps? And similarly, is
"police 1 mbps" going to police at 1000000, 1024000 or 1048576 bits/sec?

 

[/QUOTE]

In networking, when talking about line rates, the metric prefixes
apply. 1 kbps is 1000 bits/second, 1 mbps is 1000000 bits/second.

 

In networking, when talking about line rates, the metric prefixes
apply. 1 kbps is 1000 bits/second, 1 mbps is 1000000 bits/second.[/QUOTE]

more importantly - there are some uncertainties about policing that will
swamp any difference.

i hit some nasties last time i had to decide exactly what to do with some
policing requirements (on a Cat6k).

To be fair the issues were more about deciding what you actually mean by
vague terms like "police to 30 Mbps".

biggest one is exactly what are you measuring?

eg different routers / switches etc will use the L1, L2 or L3 packet size to
"count" how much bandwidth is used - and it never seems to be
documented........

We had size constraints defined for L3 traffic, but the Sup 720 only seems
to police @ L2. So - what size frames do we use to calculate policer
settings?

this can make a big difference with smaller packets - L2 size on Ethernet is
around 20% more than L3 for a minimum sized Ethernet frame......

the other thing likely to hit you is that the policing you get will depend
on granularity - the policer might try to measure bytes or bandwidth, but it
can only throw away complete frames.

so the device needs to keep track of fractions of packets, or you get
cumulative errors.

finally - the devices, apps etc will react to packet loss, so exactly what
happens is dependent on how they behave under loss.

and then the next issue - congestion control - which has to happen at layer
1, so you deal with frame preambles, inter frame gaps. Yet another set of
fuzzy additions to the answers.

dont get me wrong - it works well.

it is just so traffic / frame size dependent that worrying about fractions
of 1% of load is pretty much irrelevant.......

 

In networking, when talking about line rates, the metric prefixes
apply. 1 kbps is 1000 bits/second, 1 mbps is 1000000 bits/second.[/QUOTE]

Not exactly true. LAN speeds tend to be powers of 10 or integer
multiples. WAN speeds are usually based on multiples of 64000 bps.
That means that what's commonly called a 2Mbps line (E1) is actually
2048000 bps, 30x64000 bps channels plus management overhead, and 1.5Mbps
(T1) is actually 1.544Mbps, 24x64kbps plus some stuff. Higher rates
pack multiple E1s or T1s into further bundles.

That "multiples + overhead" stuff is why the nominal 10Gbps WAN standard
transmission rate isn't quite the same as the (exactly) 10Gbps ethernet
rate and also why you sometimes see the same service quoted at different
rates - it's the difference between the raw bit rate and the user data
that can be packed in between the overhead bits.

There's lots of plausible looking stuff in Wikipedia about this - try
<http://en.wikipedia.org/wiki/Megabit_per_second> and then the "List of
device bandwidths" link at the bottom of the page and head for the Wide
area network and Local area network sections.

Sam

 

Thanks, that looks useful.

My view of this as a customer is - who cares?

Well I don't really care - I would rather just knock the policer
rate down a bit to be sure that I was on the right side.

On the other hand a supplier of services would be expected
to provide accurate information and there is the famous case
of the NM-4E1 (at a guess but possibly correct) that provided
4 E1 interfaces with a total bandwidth of 8,000,000 bps.

Unfortunately an E1 is a bit more than 2,000,000 bps
maybe 1000 x 1024 or in other words n x 64000.

This of course meant that 4 x E1 did not work.

It was swiftly followed by the NM-4E1+ )