I often get questions from customers on what data rate can they expect from their particular network protocol, like Ethernet, MoCA, or HPNA. They often have expectations that have been set by marketing material and not reality. I thought it would be worthwhile reviewing what drives the effective data rate of typical network protocol and how that number differs from what is often reported in the product's marketing material.
There are no doubts about it, internet and telephone networks have never been more important. This is particularly true for businesses such as IT companies in Melbourne and all over the world that rely on their IT networks to keep in touch with their customers. Above all, maintaining an open communication channel is the key to success for companies that operate from an online platform.
That being said, for my example, I will use the Home Phone Network Alliance (HPNA) standard, which is commonly used to distribute data over old phone lines (twisted pair) and coaxial cable (Figure 1). For this discussion, I will not need to go into the HPNA's operational details – we are going to focus on the definitions of a few terms that are commonly used to describe data rates. As usual, the answer becomes complicated because the data rate you obtain is a function of the version of integrated circuit you are using.
Understanding bit rates for a network is similar to trying to understand the gas mileage numbers for a car. The car manufacturers emphasize the highway mileage numbers, which are optimistic and that few, if any, drivers obtain. The city driving numbers probably are closer to what most drivers will get, but even these numbers are frequently optimistic. The actual mileage depends strongly on how you drive – same with network performance. You can do configuration via an Arris router login to fine tune the engine of the connection that is the router, which can help up the speed (or the mileage), but before doing so it is important to understand what the ISP means by data rate.
There are three common terms used to specify data rate:
- Theoretical Physical Rate (TPR)
- The total number of bits transferred per second. This parameter ignores the overheads associated with forming bits into packets, managing these packet, and dealing with errors.
Errors and malfunctioning networks can sometimes lead to data loss in the computer systems that run them. In such situations, Storage Area Network (SAN) data recovery and similar services can be utilized by administrators to restore the data.
- Practical Physical Rate (PPR)
- The total number of bits transferred per second after handling errors.
- Data Rate (DR)
- The actual number of data bits transferred per second after removing the overheads associated with transport overheads like Internet Protocol (IP).
I often have customers tell me that they expected the TPR because of what they had read in marketing material, but they measured the DR, which is often not listed. I will use HPNA as an example of how these three specifications are related.
Equation 1 shows how the TPR is computed, which is of interest to hardware designers because it drives the performance requirements for their part of the network. This is the number I usually hear customers repeating. They will NEVER obtain this rate in practice.
- NSymbol is the number of bits per symbol.
- fSymbol is the rate of symbol transmission.
Equation 2 shows how the PPR is computed, which is mainly of interest to hardware developers who are dealing with the error-correcting portions of the system. I do not hear this number from customers much, but it has come up – customers will never obtain this rate in practice either.
- N is the HPNA overhead for supporting IP.
Equation 3 shows how the DR is computed. The customers actually have a chance at obtaining this number, assuming all is going smoothly. It is comparable to the city driving number for gas mileage.
- k is the HPNA overhead for supporting IP.
|Chip Version||fSymbol (Mbps)||NSymbol (bits)||PPR (Mbps)|
|Chip Version||fSymbol (Mbps)||NSymbol|1E-7 (bits)||PPR (Mbps)|
I have actually had customers obtain the rates shown in Table 3. However, those rates were obtained in an almost ideal test environment. Start adding multiple data interfaces and the rates begin to drop because of other system overheads associated with multiple interfaces vying for the shared media.
|Chip Version||PPR (Mbps)||Overhead||Data Rate (Mbps)|
This question came up today and I thought my response was worth documenting here.