Serial line - utilization

-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.