Walter Roberson
Guest
|
 Posted:
Fri Dec 16, 2005 1:58 am Post subject:
Re: Serial line - utilization |
|
|
In article <1134676698.240754.247200@z14g2000cwz.googlegroups.com>,
<gautamzone@gmail.com> wrote:
| Quote: | I just wanted to know that for a Serial line with a 128 Mbps leased
line connection , what can be a problem-free utilization rate. Is it 80
percent or 90 percent or something else? Should there be a need to
worry and upgrade bandwidth to 192 K or 256 K if utilization exceeds a
certain percent?
|
-Usually-, utilization rate is not the most important factor: the
most important factor (for reasonable error levels) is usually
latency.
As a rough approximation, Yes, latency usually does increase with
increased utilization -- but the conditions for increased latency
are more complicated than that. For a fixed link, latency increases
when packets have to wait for transmission time to become available.
If packets were being dispatched at random intervals, then latency
would become exponential in -remaining- available utilization
[after you hit 100% average utilization, if you try to increase the
rate at which you send packets, packets are going to have to drop
unless you have infinite buffers and infinite timeouts.]
But packets are not actually dispatched at random intervals, because
TCP packets especially are part of data flows that have built in
flow-control mechanisms. Therefore if you had just long-running TCP
connections transfering data at a constant rate, then the flows
could end up synchronizing with available bandwidth -- first
host takes a turn, second host takes a turn, and so on -- in which
case the latency as traditionally measured could actually end up falling
as the sessions become more and more synchronized.
Think of a busy highway: where is the slow part? If there are no
accidents or lane closures along the way, then once -on- the highway,
everyone can pick a lane and go the speed limit -- so the slow part
is getting -on- the highway. UDP, other protocols, and short TCP sessions
correspond to a lot of on-and-off traffic on the highway: the
limiting factor becomes not the traffic volume itself, but the
contention for getting on and off. If you drove up the ramp and there
just happens to be a gap right then, then you just go for it. If
you drove up at a random time, then the chance that there will be
a gap when you want it depends upon the distribution of the traffic.
But if you happen to know when the next gap will be and you are
able to schedule yourself to arrive then, then you don't wait at all --
and that's something that depends on your ability to predict the gaps
(or to have something regulate you so you hit the gaps just right.)
So.... we can't really answer the question, not unless we know what
the distribution of your traffic is. If your traffic is a good
approximation of "random", then we could tell you the percentage
average utilization that is compatable with a particular increase
in latency.
I say that latency is usually more important than utilization rate
because for random traffic, your users will complain if the network
seems slow to them. "The network is slow" is really a matter of
latency. You could have 95% utilization through long running
automatic transfers, and if your network was configured to prioritize
the (say) 2% interactive typing, then your interactive users wouldn't
notice that the link is being heavily used. Users don't care about
how much traffic is going over the network behind their backs: what
they want is that -their- traffic is not noticably delayed compared
to what they have become accustomed to. If you do have a lot of
traffic that is not delay-sensitive (because users are not paused
waiting for it), then you can gain a lot of user satisfaction by
traffic prioritization -- which doesn't change how busy the link is,
only how quickly the delay-sensitive traffic gets on to the link.
Your traffic utilization has to be -quite- close to 100% before
you start actually losing IP packets. You can check whether that
is happening by looking at the interface statistics and looking
at the figure for "excessive collisions". Chances are that that
number is 0 for you. If your interface shows collisions as a
percentage, and the rate is less than about 3000%, you might be
experiencing delays but you aren't going to lose packets. If your
collision rate shows about 100%, then you are not even -close- to losing
packets... but your packets would be delayed, and you would have -less-
delay if you prioritized traffic or if you added bandwidth.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest |
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in