Does it make sense to generally “Disable TCP Checksum Offload”?
Clash Royale CLAN TAG#URR8PPP
In a work sheet for PCs that we deliver to customers, I found instructions to always "Disable TCP Checksum Offload" on the NICs. Via those NICs, the PCs are connected to the customer's LAN, and it is imperative that they work without problems.
The explanation by a seasoned colleague for why this instruction is needed was that "NICs are always buggy and are causing lots of problems because of this."
Now, I could just imagine that they've had such problems a couple of years ago and have been doing things this way ever since.
But since the offload is usually on by default, I could also imagine that the NICs we get these days have improved somewhat. Also, we only choose robust and well-made PCs made by known-good manufacturers.
Does it make sense to always "Disable TCP Checksum Offload" on the NICs of a PC I could buy today? Or could I strike the above work instruction from the work sheet without having to fear outages on the customer's site?
hardware checksum
asked Jan 13 at 17:17
doppelfishdoppelfish
183
add a comment |
In a work sheet for PCs that we deliver to customers, I found instructions to always "Disable TCP Checksum Offload" on the NICs. Via those NICs, the PCs are connected to the customer's LAN, and it is imperative that they work without problems.
The explanation by a seasoned colleague for why this instruction is needed was that "NICs are always buggy and are causing lots of problems because of this."
Now, I could just imagine that they've had such problems a couple of years ago and have been doing things this way ever since.
But since the offload is usually on by default, I could also imagine that the NICs we get these days have improved somewhat. Also, we only choose robust and well-made PCs made by known-good manufacturers.
Does it make sense to always "Disable TCP Checksum Offload" on the NICs of a PC I could buy today? Or could I strike the above work instruction from the work sheet without having to fear outages on the customer's site?
hardware checksum
asked Jan 13 at 17:17
doppelfishdoppelfish
183
While the possibility is there, I've been in networking for decades and have yet to encounter a NIC that did checksum offload incorrectly. (stay away from random, no-name Chinese junk, and you too may never see it.)
– Ricky Beam
Jan 13 at 21:15
Can you clarify if these are budget NICs in desktops (ie realtek etc) or high-end NICs used in servers ?
– Criggie
Jan 14 at 0:51
1
Broken NICs are a thing, and this kind of bug manifests itself in a very subtle way that makes it hard and expensive to debug.
– Simon Richter
Jan 14 at 6:38
1
@Criggie We're using high-quality hardware from well-known suppliers. I doubt that they can afford to build in budget NICs.
– doppelfish
Jan 14 at 19:54
add a comment |
In a work sheet for PCs that we deliver to customers, I found instructions to always "Disable TCP Checksum Offload" on the NICs. Via those NICs, the PCs are connected to the customer's LAN, and it is imperative that they work without problems.
The explanation by a seasoned colleague for why this instruction is needed was that "NICs are always buggy and are causing lots of problems because of this."
Now, I could just imagine that they've had such problems a couple of years ago and have been doing things this way ever since.
But since the offload is usually on by default, I could also imagine that the NICs we get these days have improved somewhat. Also, we only choose robust and well-made PCs made by known-good manufacturers.
Does it make sense to always "Disable TCP Checksum Offload" on the NICs of a PC I could buy today? Or could I strike the above work instruction from the work sheet without having to fear outages on the customer's site?
hardware checksum
asked Jan 13 at 17:17
doppelfishdoppelfish
183
In a work sheet for PCs that we deliver to customers, I found instructions to always "Disable TCP Checksum Offload" on the NICs. Via those NICs, the PCs are connected to the customer's LAN, and it is imperative that they work without problems.
The explanation by a seasoned colleague for why this instruction is needed was that "NICs are always buggy and are causing lots of problems because of this."
Now, I could just imagine that they've had such problems a couple of years ago and have been doing things this way ever since.
But since the offload is usually on by default, I could also imagine that the NICs we get these days have improved somewhat. Also, we only choose robust and well-made PCs made by known-good manufacturers.
Does it make sense to always "Disable TCP Checksum Offload" on the NICs of a PC I could buy today? Or could I strike the above work instruction from the work sheet without having to fear outages on the customer's site?
hardware checksum
hardware checksum
asked Jan 13 at 17:17
doppelfishdoppelfish
183
asked Jan 13 at 17:17
doppelfishdoppelfish
183
asked Jan 13 at 17:17
doppelfishdoppelfish
183
asked Jan 13 at 17:17
doppelfishdoppelfish
183
asked Jan 13 at 17:17
doppelfishdoppelfish
183
183
While the possibility is there, I've been in networking for decades and have yet to encounter a NIC that did checksum offload incorrectly. (stay away from random, no-name Chinese junk, and you too may never see it.)
– Ricky Beam
Jan 13 at 21:15
Can you clarify if these are budget NICs in desktops (ie realtek etc) or high-end NICs used in servers ?
– Criggie
Jan 14 at 0:51
1
Broken NICs are a thing, and this kind of bug manifests itself in a very subtle way that makes it hard and expensive to debug.
– Simon Richter
Jan 14 at 6:38
1
@Criggie We're using high-quality hardware from well-known suppliers. I doubt that they can afford to build in budget NICs.
– doppelfish
Jan 14 at 19:54
add a comment |
While the possibility is there, I've been in networking for decades and have yet to encounter a NIC that did checksum offload incorrectly. (stay away from random, no-name Chinese junk, and you too may never see it.)
– Ricky Beam
Jan 13 at 21:15
Can you clarify if these are budget NICs in desktops (ie realtek etc) or high-end NICs used in servers ?
– Criggie
Jan 14 at 0:51
1
Broken NICs are a thing, and this kind of bug manifests itself in a very subtle way that makes it hard and expensive to debug.
– Simon Richter
Jan 14 at 6:38
1
@Criggie We're using high-quality hardware from well-known suppliers. I doubt that they can afford to build in budget NICs.
– doppelfish
Jan 14 at 19:54
While the possibility is there, I've been in networking for decades and have yet to encounter a NIC that did checksum offload incorrectly. (stay away from random, no-name Chinese junk, and you too may never see it.)
– Ricky Beam
Jan 13 at 21:15
While the possibility is there, I've been in networking for decades and have yet to encounter a NIC that did checksum offload incorrectly. (stay away from random, no-name Chinese junk, and you too may never see it.)
– Ricky Beam
Jan 13 at 21:15
Can you clarify if these are budget NICs in desktops (ie realtek etc) or high-end NICs used in servers ?
– Criggie
Jan 14 at 0:51
Can you clarify if these are budget NICs in desktops (ie realtek etc) or high-end NICs used in servers ?
– Criggie
Jan 14 at 0:51
1
1
Broken NICs are a thing, and this kind of bug manifests itself in a very subtle way that makes it hard and expensive to debug.
– Simon Richter
Jan 14 at 6:38
Broken NICs are a thing, and this kind of bug manifests itself in a very subtle way that makes it hard and expensive to debug.
– Simon Richter
Jan 14 at 6:38
1
1
@Criggie We're using high-quality hardware from well-known suppliers. I doubt that they can afford to build in budget NICs.
– doppelfish
Jan 14 at 19:54
@Criggie We're using high-quality hardware from well-known suppliers. I doubt that they can afford to build in budget NICs.
– doppelfish
Jan 14 at 19:54
add a comment |
1 Answer
1
active
oldest
votes
Hardware offloading feature may have bugs but they are generally beneficial. I only deactivate them on certain NICs or vendors which do have problems.
However, on a workstation/PC the network load is usually low to very low - there's little benefit gained from offloading but there's still a risk of buggy hardware/drivers. That probably drove the work sheet's author to deactivate it in any case.
In servers, there is a lot more network traffic and other load, so there's more potential gain from offloading. Also, server (NIC) drivers are often better tested and potentially more stable.
The choice is still yours. ;-)
answered Jan 13 at 18:06
Zac67Zac67
28.1k21457
Testing and maintaining a database of individual hardware quirks is sometimes much more expensive than simply not using a specific feature. I've been guilty myself for advising an underoptimised setup in order to avoid bug reports.
– slebetman
Jan 14 at 0:14
1
You may also want to capture the original packets for a tool like wireshark rather that receive them with the checksums verified and removed.
– james
Jan 14 at 1:36
@james Excellent point - for capturing you should deactivate all offloading.
– Zac67
Jan 14 at 7:18
@james... and when tcp checksums are of no interest, wireshark can be configured to ignore tcp, udp or ip checksums.
– Marc 'netztier' Luethi
Jan 15 at 17:43
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
);
);
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%2f56083%2fdoes-it-make-sense-to-generally-disable-tcp-checksum-offload%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Hardware offloading feature may have bugs but they are generally beneficial. I only deactivate them on certain NICs or vendors which do have problems.
However, on a workstation/PC the network load is usually low to very low - there's little benefit gained from offloading but there's still a risk of buggy hardware/drivers. That probably drove the work sheet's author to deactivate it in any case.
In servers, there is a lot more network traffic and other load, so there's more potential gain from offloading. Also, server (NIC) drivers are often better tested and potentially more stable.
The choice is still yours. ;-)
answered Jan 13 at 18:06
Zac67Zac67
28.1k21457
Testing and maintaining a database of individual hardware quirks is sometimes much more expensive than simply not using a specific feature. I've been guilty myself for advising an underoptimised setup in order to avoid bug reports.
– slebetman
Jan 14 at 0:14
1
You may also want to capture the original packets for a tool like wireshark rather that receive them with the checksums verified and removed.
– james
Jan 14 at 1:36
@james Excellent point - for capturing you should deactivate all offloading.
– Zac67
Jan 14 at 7:18
@james... and when tcp checksums are of no interest, wireshark can be configured to ignore tcp, udp or ip checksums.
– Marc 'netztier' Luethi
Jan 15 at 17:43
add a comment |
Hardware offloading feature may have bugs but they are generally beneficial. I only deactivate them on certain NICs or vendors which do have problems.
However, on a workstation/PC the network load is usually low to very low - there's little benefit gained from offloading but there's still a risk of buggy hardware/drivers. That probably drove the work sheet's author to deactivate it in any case.
In servers, there is a lot more network traffic and other load, so there's more potential gain from offloading. Also, server (NIC) drivers are often better tested and potentially more stable.
The choice is still yours. ;-)
answered Jan 13 at 18:06
Zac67Zac67
28.1k21457
Testing and maintaining a database of individual hardware quirks is sometimes much more expensive than simply not using a specific feature. I've been guilty myself for advising an underoptimised setup in order to avoid bug reports.
– slebetman
Jan 14 at 0:14
1
You may also want to capture the original packets for a tool like wireshark rather that receive them with the checksums verified and removed.
– james
Jan 14 at 1:36
@james Excellent point - for capturing you should deactivate all offloading.
– Zac67
Jan 14 at 7:18
@james... and when tcp checksums are of no interest, wireshark can be configured to ignore tcp, udp or ip checksums.
– Marc 'netztier' Luethi
Jan 15 at 17:43
add a comment |
Hardware offloading feature may have bugs but they are generally beneficial. I only deactivate them on certain NICs or vendors which do have problems.
However, on a workstation/PC the network load is usually low to very low - there's little benefit gained from offloading but there's still a risk of buggy hardware/drivers. That probably drove the work sheet's author to deactivate it in any case.
In servers, there is a lot more network traffic and other load, so there's more potential gain from offloading. Also, server (NIC) drivers are often better tested and potentially more stable.
The choice is still yours. ;-)
answered Jan 13 at 18:06
Zac67Zac67
28.1k21457
Hardware offloading feature may have bugs but they are generally beneficial. I only deactivate them on certain NICs or vendors which do have problems.
However, on a workstation/PC the network load is usually low to very low - there's little benefit gained from offloading but there's still a risk of buggy hardware/drivers. That probably drove the work sheet's author to deactivate it in any case.
In servers, there is a lot more network traffic and other load, so there's more potential gain from offloading. Also, server (NIC) drivers are often better tested and potentially more stable.
The choice is still yours. ;-)
answered Jan 13 at 18:06
Zac67Zac67
28.1k21457
answered Jan 13 at 18:06
Zac67Zac67
28.1k21457
answered Jan 13 at 18:06
Zac67Zac67
28.1k21457
answered Jan 13 at 18:06
Zac67Zac67
28.1k21457
28.1k21457
Testing and maintaining a database of individual hardware quirks is sometimes much more expensive than simply not using a specific feature. I've been guilty myself for advising an underoptimised setup in order to avoid bug reports.
– slebetman
Jan 14 at 0:14
1
You may also want to capture the original packets for a tool like wireshark rather that receive them with the checksums verified and removed.
– james
Jan 14 at 1:36
@james Excellent point - for capturing you should deactivate all offloading.
– Zac67
Jan 14 at 7:18
@james... and when tcp checksums are of no interest, wireshark can be configured to ignore tcp, udp or ip checksums.
– Marc 'netztier' Luethi
Jan 15 at 17:43
add a comment |
Testing and maintaining a database of individual hardware quirks is sometimes much more expensive than simply not using a specific feature. I've been guilty myself for advising an underoptimised setup in order to avoid bug reports.
– slebetman
Jan 14 at 0:14
1
You may also want to capture the original packets for a tool like wireshark rather that receive them with the checksums verified and removed.
– james
Jan 14 at 1:36
@james Excellent point - for capturing you should deactivate all offloading.
– Zac67
Jan 14 at 7:18
@james... and when tcp checksums are of no interest, wireshark can be configured to ignore tcp, udp or ip checksums.
– Marc 'netztier' Luethi
Jan 15 at 17:43
Testing and maintaining a database of individual hardware quirks is sometimes much more expensive than simply not using a specific feature. I've been guilty myself for advising an underoptimised setup in order to avoid bug reports.
– slebetman
Jan 14 at 0:14
Testing and maintaining a database of individual hardware quirks is sometimes much more expensive than simply not using a specific feature. I've been guilty myself for advising an underoptimised setup in order to avoid bug reports.
– slebetman
Jan 14 at 0:14
1
1
You may also want to capture the original packets for a tool like wireshark rather that receive them with the checksums verified and removed.
– james
Jan 14 at 1:36
You may also want to capture the original packets for a tool like wireshark rather that receive them with the checksums verified and removed.
– james
Jan 14 at 1:36
@james Excellent point - for capturing you should deactivate all offloading.
– Zac67
Jan 14 at 7:18
@james Excellent point - for capturing you should deactivate all offloading.
– Zac67
Jan 14 at 7:18
@james... and when tcp checksums are of no interest, wireshark can be configured to ignore tcp, udp or ip checksums.
– Marc 'netztier' Luethi
Jan 15 at 17:43
@james... and when tcp checksums are of no interest, wireshark can be configured to ignore tcp, udp or ip checksums.
– Marc 'netztier' Luethi
Jan 15 at 17:43
add a comment |
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%2f56083%2fdoes-it-make-sense-to-generally-disable-tcp-checksum-offload%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
While the possibility is there, I've been in networking for decades and have yet to encounter a NIC that did checksum offload incorrectly. (stay away from random, no-name Chinese junk, and you too may never see it.)
– Ricky Beam
Jan 13 at 21:15
Can you clarify if these are budget NICs in desktops (ie realtek etc) or high-end NICs used in servers ?
– Criggie
Jan 14 at 0:51
1
Broken NICs are a thing, and this kind of bug manifests itself in a very subtle way that makes it hard and expensive to debug.
– Simon Richter
Jan 14 at 6:38
1
@Criggie We're using high-quality hardware from well-known suppliers. I doubt that they can afford to build in budget NICs.
– doppelfish
Jan 14 at 19:54