Can throughput exceed the bandwidth of a network
so I took an introductory course to networking this semester and I was wondering:
Looking at things at the layer 4 level using TCP can the throughput on the network exceed its' bandwidth? If according to definition I believe throughput can be explained as the percentage of packets on a link whether they fail to reach the other end or not.
If that's the true definition and a network theoretically can run at 100% of its' bandwidth wouldn't all window sizes of senders on that link now grow larger to and all together exceed the bandwidth of the entire link?
In other words the throughput momentarily would exceed 100% which would surely lead to packet loss, am I correct to think of it this way?
tcp bandwidth throughput
asked 1 hour ago
edan pattedan patt
61
New contributor
edan patt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
so I took an introductory course to networking this semester and I was wondering:
Looking at things at the layer 4 level using TCP can the throughput on the network exceed its' bandwidth? If according to definition I believe throughput can be explained as the percentage of packets on a link whether they fail to reach the other end or not.
If that's the true definition and a network theoretically can run at 100% of its' bandwidth wouldn't all window sizes of senders on that link now grow larger to and all together exceed the bandwidth of the entire link?
In other words the throughput momentarily would exceed 100% which would surely lead to packet loss, am I correct to think of it this way?
tcp bandwidth throughput
asked 1 hour ago
edan pattedan patt
61
New contributor
edan patt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
so I took an introductory course to networking this semester and I was wondering:
Looking at things at the layer 4 level using TCP can the throughput on the network exceed its' bandwidth? If according to definition I believe throughput can be explained as the percentage of packets on a link whether they fail to reach the other end or not.
If that's the true definition and a network theoretically can run at 100% of its' bandwidth wouldn't all window sizes of senders on that link now grow larger to and all together exceed the bandwidth of the entire link?
In other words the throughput momentarily would exceed 100% which would surely lead to packet loss, am I correct to think of it this way?
tcp bandwidth throughput
asked 1 hour ago
edan pattedan patt
61
New contributor
edan patt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
so I took an introductory course to networking this semester and I was wondering:
Looking at things at the layer 4 level using TCP can the throughput on the network exceed its' bandwidth? If according to definition I believe throughput can be explained as the percentage of packets on a link whether they fail to reach the other end or not.
If that's the true definition and a network theoretically can run at 100% of its' bandwidth wouldn't all window sizes of senders on that link now grow larger to and all together exceed the bandwidth of the entire link?
In other words the throughput momentarily would exceed 100% which would surely lead to packet loss, am I correct to think of it this way?
tcp bandwidth throughput
tcp bandwidth throughput
asked 1 hour ago
edan pattedan patt
61
New contributor
edan patt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 1 hour ago
edan pattedan patt
61
New contributor
edan patt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 1 hour ago
edan pattedan patt
61
New contributor
edan patt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 1 hour ago
edan pattedan patt
61
asked 1 hour ago
edan pattedan patt
61
61
New contributor
edan patt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
edan patt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edan patt is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
The bandwidth is the number of bits that can be sent on a link in one second. The throughput is the amount of data sent, and that will need to subtract the protocol overhead from the bandwidth, so no, the throughput cannot exceed the bandwidth. It may seem that way if you compress the data, but that is an illusion.
answered 1 hour ago
Ron Maupin♦Ron Maupin
66.5k1369123
Well if I send more than the network link can handle wouldn't it still be accounted for? As in we could exceed 100% although it would surely cause segments to be lost
– edan patt
1 hour ago
It would simply be queued or dropped at the interface. You cannot send more bits than the interface can send during a specific time period (one second).
– Ron Maupin♦
1 hour ago
I see, so what matters is what is physically sent, I've always looked at the throughput "through the eyes" of the sender meaning the sender could send more than what the network could handle. Thanks for making it clear.
– edan patt
1 hour ago
The bandwidth limits the number of bits that can be transmitted per second. So you can't send more than that.
– Ron Trunk
1 hour ago
Typically, the throughput is measured in bytes, not bits, of the application data sent during a specific time period. You must subtract the protocol overhead to arrive at the throughput, which can also be affected by slow host processing, waiting for ACKs, etc. It is how much useful data is actually sent.
– Ron Maupin♦
1 hour ago
add a comment |
TCP also implements a receive window that's sent in the ACK for each received packet, so if you try to overload the host on the other end, it'll set the receive window to a smaller value as the TCP receive buffer fills, until finally it's set to 0 to tell the sending party to back off until it has had time process the incoming packets and hand them off to the upper layers of the networking stack. So this limits the sending capabilities. Also, if a network switch were to drop a frame due to over-congestion, that will cause TCP to halt everything, ask for a fast retransmit of the missing packet (since packets will start to arrive out of order), and then resume processing of the other packets. TCP doesn't care about maximum speed or throughput, it cares about getting every single frame through, in order and without errors. For what you're describing to even happen, you'd need to use another Layer 4 protocol, preferably something which doesn't care about anything, like UDP.
answered 28 mins ago
StuggiStuggi
1,432521
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "496"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
edan patt is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f57427%2fcan-throughput-exceed-the-bandwidth-of-a-network%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
The bandwidth is the number of bits that can be sent on a link in one second. The throughput is the amount of data sent, and that will need to subtract the protocol overhead from the bandwidth, so no, the throughput cannot exceed the bandwidth. It may seem that way if you compress the data, but that is an illusion.
answered 1 hour ago
Ron Maupin♦Ron Maupin
66.5k1369123
Well if I send more than the network link can handle wouldn't it still be accounted for? As in we could exceed 100% although it would surely cause segments to be lost
– edan patt
1 hour ago
It would simply be queued or dropped at the interface. You cannot send more bits than the interface can send during a specific time period (one second).
– Ron Maupin♦
1 hour ago
I see, so what matters is what is physically sent, I've always looked at the throughput "through the eyes" of the sender meaning the sender could send more than what the network could handle. Thanks for making it clear.
– edan patt
1 hour ago
The bandwidth limits the number of bits that can be transmitted per second. So you can't send more than that.
– Ron Trunk
1 hour ago
Typically, the throughput is measured in bytes, not bits, of the application data sent during a specific time period. You must subtract the protocol overhead to arrive at the throughput, which can also be affected by slow host processing, waiting for ACKs, etc. It is how much useful data is actually sent.
– Ron Maupin♦
1 hour ago
add a comment |
The bandwidth is the number of bits that can be sent on a link in one second. The throughput is the amount of data sent, and that will need to subtract the protocol overhead from the bandwidth, so no, the throughput cannot exceed the bandwidth. It may seem that way if you compress the data, but that is an illusion.
answered 1 hour ago
Ron Maupin♦Ron Maupin
66.5k1369123
Well if I send more than the network link can handle wouldn't it still be accounted for? As in we could exceed 100% although it would surely cause segments to be lost
– edan patt
1 hour ago
It would simply be queued or dropped at the interface. You cannot send more bits than the interface can send during a specific time period (one second).
– Ron Maupin♦
1 hour ago
I see, so what matters is what is physically sent, I've always looked at the throughput "through the eyes" of the sender meaning the sender could send more than what the network could handle. Thanks for making it clear.
– edan patt
1 hour ago
The bandwidth limits the number of bits that can be transmitted per second. So you can't send more than that.
– Ron Trunk
1 hour ago
Typically, the throughput is measured in bytes, not bits, of the application data sent during a specific time period. You must subtract the protocol overhead to arrive at the throughput, which can also be affected by slow host processing, waiting for ACKs, etc. It is how much useful data is actually sent.
– Ron Maupin♦
1 hour ago
add a comment |
The bandwidth is the number of bits that can be sent on a link in one second. The throughput is the amount of data sent, and that will need to subtract the protocol overhead from the bandwidth, so no, the throughput cannot exceed the bandwidth. It may seem that way if you compress the data, but that is an illusion.
answered 1 hour ago
Ron Maupin♦Ron Maupin
66.5k1369123
The bandwidth is the number of bits that can be sent on a link in one second. The throughput is the amount of data sent, and that will need to subtract the protocol overhead from the bandwidth, so no, the throughput cannot exceed the bandwidth. It may seem that way if you compress the data, but that is an illusion.
answered 1 hour ago
Ron Maupin♦Ron Maupin
66.5k1369123
answered 1 hour ago
Ron Maupin♦Ron Maupin
66.5k1369123
answered 1 hour ago
Ron Maupin♦Ron Maupin
66.5k1369123
answered 1 hour ago
Ron Maupin♦Ron Maupin
66.5k1369123
66.5k1369123
Well if I send more than the network link can handle wouldn't it still be accounted for? As in we could exceed 100% although it would surely cause segments to be lost
– edan patt
1 hour ago
It would simply be queued or dropped at the interface. You cannot send more bits than the interface can send during a specific time period (one second).
– Ron Maupin♦
1 hour ago
I see, so what matters is what is physically sent, I've always looked at the throughput "through the eyes" of the sender meaning the sender could send more than what the network could handle. Thanks for making it clear.
– edan patt
1 hour ago
The bandwidth limits the number of bits that can be transmitted per second. So you can't send more than that.
– Ron Trunk
1 hour ago
Typically, the throughput is measured in bytes, not bits, of the application data sent during a specific time period. You must subtract the protocol overhead to arrive at the throughput, which can also be affected by slow host processing, waiting for ACKs, etc. It is how much useful data is actually sent.
– Ron Maupin♦
1 hour ago
add a comment |
Well if I send more than the network link can handle wouldn't it still be accounted for? As in we could exceed 100% although it would surely cause segments to be lost
– edan patt
1 hour ago
It would simply be queued or dropped at the interface. You cannot send more bits than the interface can send during a specific time period (one second).
– Ron Maupin♦
1 hour ago
I see, so what matters is what is physically sent, I've always looked at the throughput "through the eyes" of the sender meaning the sender could send more than what the network could handle. Thanks for making it clear.
– edan patt
1 hour ago
The bandwidth limits the number of bits that can be transmitted per second. So you can't send more than that.
– Ron Trunk
1 hour ago
Typically, the throughput is measured in bytes, not bits, of the application data sent during a specific time period. You must subtract the protocol overhead to arrive at the throughput, which can also be affected by slow host processing, waiting for ACKs, etc. It is how much useful data is actually sent.
– Ron Maupin♦
1 hour ago
Well if I send more than the network link can handle wouldn't it still be accounted for? As in we could exceed 100% although it would surely cause segments to be lost
– edan patt
1 hour ago
Well if I send more than the network link can handle wouldn't it still be accounted for? As in we could exceed 100% although it would surely cause segments to be lost
– edan patt
1 hour ago
It would simply be queued or dropped at the interface. You cannot send more bits than the interface can send during a specific time period (one second).
– Ron Maupin♦
1 hour ago
It would simply be queued or dropped at the interface. You cannot send more bits than the interface can send during a specific time period (one second).
– Ron Maupin♦
1 hour ago
I see, so what matters is what is physically sent, I've always looked at the throughput "through the eyes" of the sender meaning the sender could send more than what the network could handle. Thanks for making it clear.
– edan patt
1 hour ago
I see, so what matters is what is physically sent, I've always looked at the throughput "through the eyes" of the sender meaning the sender could send more than what the network could handle. Thanks for making it clear.
– edan patt
1 hour ago
The bandwidth limits the number of bits that can be transmitted per second. So you can't send more than that.
– Ron Trunk
1 hour ago
The bandwidth limits the number of bits that can be transmitted per second. So you can't send more than that.
– Ron Trunk
1 hour ago
Typically, the throughput is measured in bytes, not bits, of the application data sent during a specific time period. You must subtract the protocol overhead to arrive at the throughput, which can also be affected by slow host processing, waiting for ACKs, etc. It is how much useful data is actually sent.
– Ron Maupin♦
1 hour ago
Typically, the throughput is measured in bytes, not bits, of the application data sent during a specific time period. You must subtract the protocol overhead to arrive at the throughput, which can also be affected by slow host processing, waiting for ACKs, etc. It is how much useful data is actually sent.
– Ron Maupin♦
1 hour ago
add a comment |
TCP also implements a receive window that's sent in the ACK for each received packet, so if you try to overload the host on the other end, it'll set the receive window to a smaller value as the TCP receive buffer fills, until finally it's set to 0 to tell the sending party to back off until it has had time process the incoming packets and hand them off to the upper layers of the networking stack. So this limits the sending capabilities. Also, if a network switch were to drop a frame due to over-congestion, that will cause TCP to halt everything, ask for a fast retransmit of the missing packet (since packets will start to arrive out of order), and then resume processing of the other packets. TCP doesn't care about maximum speed or throughput, it cares about getting every single frame through, in order and without errors. For what you're describing to even happen, you'd need to use another Layer 4 protocol, preferably something which doesn't care about anything, like UDP.
answered 28 mins ago
StuggiStuggi
1,432521
add a comment |
TCP also implements a receive window that's sent in the ACK for each received packet, so if you try to overload the host on the other end, it'll set the receive window to a smaller value as the TCP receive buffer fills, until finally it's set to 0 to tell the sending party to back off until it has had time process the incoming packets and hand them off to the upper layers of the networking stack. So this limits the sending capabilities. Also, if a network switch were to drop a frame due to over-congestion, that will cause TCP to halt everything, ask for a fast retransmit of the missing packet (since packets will start to arrive out of order), and then resume processing of the other packets. TCP doesn't care about maximum speed or throughput, it cares about getting every single frame through, in order and without errors. For what you're describing to even happen, you'd need to use another Layer 4 protocol, preferably something which doesn't care about anything, like UDP.
answered 28 mins ago
StuggiStuggi
1,432521
add a comment |
TCP also implements a receive window that's sent in the ACK for each received packet, so if you try to overload the host on the other end, it'll set the receive window to a smaller value as the TCP receive buffer fills, until finally it's set to 0 to tell the sending party to back off until it has had time process the incoming packets and hand them off to the upper layers of the networking stack. So this limits the sending capabilities. Also, if a network switch were to drop a frame due to over-congestion, that will cause TCP to halt everything, ask for a fast retransmit of the missing packet (since packets will start to arrive out of order), and then resume processing of the other packets. TCP doesn't care about maximum speed or throughput, it cares about getting every single frame through, in order and without errors. For what you're describing to even happen, you'd need to use another Layer 4 protocol, preferably something which doesn't care about anything, like UDP.
answered 28 mins ago
StuggiStuggi
1,432521
TCP also implements a receive window that's sent in the ACK for each received packet, so if you try to overload the host on the other end, it'll set the receive window to a smaller value as the TCP receive buffer fills, until finally it's set to 0 to tell the sending party to back off until it has had time process the incoming packets and hand them off to the upper layers of the networking stack. So this limits the sending capabilities. Also, if a network switch were to drop a frame due to over-congestion, that will cause TCP to halt everything, ask for a fast retransmit of the missing packet (since packets will start to arrive out of order), and then resume processing of the other packets. TCP doesn't care about maximum speed or throughput, it cares about getting every single frame through, in order and without errors. For what you're describing to even happen, you'd need to use another Layer 4 protocol, preferably something which doesn't care about anything, like UDP.
answered 28 mins ago
StuggiStuggi
1,432521
answered 28 mins ago
StuggiStuggi
1,432521
answered 28 mins ago
StuggiStuggi
1,432521
answered 28 mins ago
StuggiStuggi
1,432521
1,432521
add a comment |
add a comment |
edan patt is a new contributor. Be nice, and check out our Code of Conduct.
edan patt is a new contributor. Be nice, and check out our Code of Conduct.
edan patt is a new contributor. Be nice, and check out our Code of Conduct.
edan patt is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Network Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f57427%2fcan-throughput-exceed-the-bandwidth-of-a-network%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
