Network Capacity

S

simbasahr

n00b
Joined
Jul 11, 2013
Messages
1
This question asks you to think about how much of the network capacity is used for protocol headers compared to the message contents.
A 1250 byte transmission unit carried "on the wire" over the network is the result of sending a message with a protocol stack with DNS, UDP, IP, PPP, and SONET. Each protocol header is 20 bytes long. What percentage of the network bandwidth "on the wire" is spent carrying the message data? Give a numeric answer only.
 
Can you repeat the question.

Seriously, this sounds like a Cisco question and god help those guys to ever just ask you a straight question without trying to confuse you as to what they really want.
 
This is the kind of worthless information you'll never need to know in the real world. Something you'd see on a college quiz..... hmmmm....
 
Mister Natural said:
This is the kind of worthless information you'll never need to know in the real world. Something you'd see on a college quiz..... hmmmm....
Click to expand...
Knowing about overhead and Throughput vs. Goodput is certainly not "worthless".

Unless you're one of the "network gurus" who discounts overhead as witchcraft, and thinks they should actually be getting 125MB/s file transfers on their Gigabit network. And then threatens to withhold payment on a $12k network project until the "performance is corrected"...
 
As asked, I'd say the answer is 92 - ((1250-(5*20))/1250)*100.

Answered correctly, the number would probably be higher. A UDP header is 8 bytes. IP is 20. Not sure about DNS, PPP, or SONET without looking them up.
 
Innocence said:
Knowing about overhead and Throughput vs. Goodput is certainly not "worthless".

Unless you're one of the "network gurus" who discounts overhead as witchcraft, and thinks they should actually be getting 125MB/s file transfers on their Gigabit network. And then threatens to withhold payment on a $12k network project until the "performance is corrected"...
Click to expand...


You should be getting 125MBps throughput on a 1 Gigabit link. Most modern hardware for the past decade (Ethernet wise) already has overhead taken into account to prevent the inconsistencies people would see. So if your NIC is rated for 1Gbps it really has 1.25Gbps actual exchange rates.

One of the main reasons they changed the encoding methods from 5/6b > 8/10b > 64/66b is to cut back on the wasted bandwidth while allowing Ethernet to grow exponentially as it was getting ridiculous.

1Gbps > 250Mbps needed for extra capacity. 10Gbps > 1.25Gbps extra carrying capacity. With 100Gbps if nothing changed they'd need 12.5Gbps of extra capacity.

You're right though, there is a definite need for understanding between bandwidth, throughput, and goodput, but this question is seriously lacking.
 
Innocence said:
Knowing about overhead and Throughput vs. Goodput is certainly not "worthless".

Unless you're one of the "network gurus" who discounts overhead as witchcraft, and thinks they should actually be getting 125MB/s file transfers on their Gigabit network. And then threatens to withhold payment on a $12k network project until the "performance is corrected"...
Click to expand...

In the real world you just tell the boss you need fibre installed to solve the problem. :cool:
 
I laugh at questions like this. Serves no purpose. When I service companies that moan and bitch about networking I tell them, there is always better hardware, give me your blessing and well get some 10gbit in here :)
 
Liger88 said:
You should be getting 125MBps throughput on a 1 Gigabit link. Most modern hardware for the past decade (Ethernet wise) already has overhead taken into account to prevent the inconsistencies people would see. So if your NIC is rated for 1Gbps it really has 1.25Gbps actual exchange rates.

One of the main reasons they changed the encoding methods from 5/6b > 8/10b > 64/66b is to cut back on the wasted bandwidth while allowing Ethernet to grow exponentially as it was getting ridiculous.

1Gbps > 250Mbps needed for extra capacity. 10Gbps > 1.25Gbps extra carrying capacity. With 100Gbps if nothing changed they'd need 12.5Gbps of extra capacity.

You're right though, there is a definite need for understanding between bandwidth, throughput, and goodput, but this question is seriously lacking.
Click to expand...
I've never heard of such a thing - do you have any sources that show you should get 125MB/s goodput (for example on SMB of CIFS) on 1000BASE-T?

125MB/s total throughput, yes. Show me a SMB Transfer on Gigabit running at 125MB/s and I'll be impressed...and confused.
 
Innocence said:
I've never heard of such a thing - do you have any sources that show you should get 125MB/s goodput (for example on SMB of CIFS) on 1000BASE-T?

125MB/s total throughput, yes. Show me a SMB Transfer on Gigabit running at 125MB/s and I'll be impressed...and confused.
Click to expand...

Well, you won't ever get full speed with SMB in particular. SMB is quite a chatty and inefficient protocol. Though at least version 2 is a lot better than version 1 (and v3 adds multipathing). SMB is extremely sensitive to latency, especially in v1. We have a bunch of Server 2003 machines at work still (meaning SMBv1 awfulness), and when copying them across our location-to-location VPN (minimum link 5Mbps), we literally get about 1KB/s. With a server 2012 machine from a Win7 box (thus SMBv2) we get about 7KB/s. We don't use much capacity of our line; it's not just congestion. It's a latency issue. SMB just isn't very efficient. Obviously all protocols have overhead of some sort... SMB is on the high end. On low-latency connections it's not nearly as bad, of course, but it's still less efficient than say FTP if you just want to simply transfer files and don't need all the metadata.
 
Last edited:
dandragonrage said:
Well, you won't ever get full speed with SMB in particular. SMB is quite a chatty and inefficient protocol. Though at least version 2 is a lot better than version 1 (and v3 adds multipathing). SMB is extremely sensitive to latency, especially in v1. We have a bunch of Server 2003 machines at work still (meaning SMBv1 awfulness), and when copying them across our location-to-location VPN (minimum link 5Mbps), we literally get about 1KB/s. With a server 2012 machine from a Win7 box (thus SMBv2) we get about 7KB/s. We don't use much capacity of our line; it's not just congestion. It's a latency issue. SMB just isn't very efficient. Obviously all protocols have overhead of some sort... SMB is on the high end. On low-latency connections it's not nearly as bad, of course, but it's still less efficient than say FTP if you just want to simply transfer files and don't need all the metadata.
Click to expand...
Yeah, SMB can be a pig. But even ignoring application protocol overhead - there is still packet overhead.

Even if you had a theoretically 100% efficient application protocol, you still have 3% packet overhead (not accounting for Jumbo Packets). Meaning the absolute best goodput you could get on Gigabit is right around 121MB/s .

At least that's always been my impression of it, feel free to correct me.
 
Innocence said:
Yeah, SMB can be a pig. But even ignoring application protocol overhead - there is still packet overhead.

Even if you had a theoretically 100% efficient application protocol, you still have 3% packet overhead (not accounting for Jumbo Packets). Meaning the absolute best goodput you could get on Gigabit is right around 121MB/s .

At least that's always been my impression of it, feel free to correct me.
Click to expand...


Absolutely. What I was saying is at the Layer 2 if something is rated for 1Gbps it should be theoretically (as engineers would say max possible under ideal conditions) 125MBps, now once it leaves Layer 2 its anyones game because the amount of packaging each data segment creates so much bloat as is with each transmission. Even though you may transfer at 125MBps you might only be getting 100MB or less of actual data after frames are fully stripped up the TCP/IP stack.

So technically it would be transferring at that rate, just not all the data would be relevant by the time it reaches the Application Layer. Corporations will invest heavily in making sure all devices can transmit at the rate in which they are claiming including switching/backplane bandwidth and NIC cards capable of maintaining the max Layer 2 transfer speed all the way up the stack.

As far as Ethernet devices capable of doing more than the claimed speed behind the scenes (i.e. 1Gbps NIC can actually transmit at 1Gbps actual due to overhead already taken into account) I'll have to find the resource. I'm forgetting the term used, but I'm sure if I can't find quickly enough someone will be able to fill in the details.

*EDIT*

Here's a quick link.

http://www.cisco.com/en/US/tech/tk389/tk214/tech_brief09186a0080091a8a.html#wp16659

Basically they increase the signaling rate to offset the overhead.

The LAN PHY
The simpler LAN PHY comes in two flavors, a serial version and a 4-channel Wide Wave Division Multiplexing (WWDM) version. Remember, the fast Ethernet and Gigabit Ethernet fiber PHYs used a 8B/10B encoding to provide actual line rates of 125 Mbps and 1250 Mbps, respectively. After some discussion, 10 Gigabit Ethernet settled on a more efficient 64B/66B encoding for the serial PHY, resulting in a line rate of 10.313 Gbps. The various physical media interfaces (optics) are discussed below. The WWDM PHY was added in the anticipation that the slower optical interface could result in a less expensive system; another alternative considered and discarded was using a four-discrete-fiber system. The WWDM interface basically uses four parallel channels running at 2.5 times the Gigabit Ethernet speed, hence each having a line rate of 3.125 Gbps. Again, remember that the actual data rate (MAC to PHY) is 10.000 Gbps; the encoding is used to avoid long runs of ones or zeros that could affect the receiver's ability to recover the clock and data. The LAN PHY is expected to be used in most LAN applications, and in WANs where dark fiber is used to carry 10 Gigabit Ethernet directly.
Click to expand...

http://certcities.com/editorial/features/story.asp?EditorialsID=44

Not the greatest of source, but further expands on the Cisco link and only learned of this myself in CCNA 1 course studies. It would take a real electrical or network technician to go further as this is way far out of my league and I don't want to talk out my ass to be honest. If I understood things incorrectly all this time I'm sure smarter people here will correct me. :)
 
Last edited:
I just looked at my ASA's and it reports that DNS totals 0% of my traffic, that means less than 1% basicly, so header information on my network is minimal really, at least for DNS
 
You must log in or register to reply here.
Back
Top