I have a CentOS 5.8 box that is dropping packets (just from ping). The network is 8139 RTL-8139/8139C/8139C+ Rev 10
Adding the parameters "pci=noacpi acpi=off " has helped but it still happens.
Is there something else that helps the network not drop packets?
Thanks,
jerry
On Sat, Oct 27, 2012 at 04:40:42PM -0400, Jerry Geis wrote:
I have a CentOS 5.8 box that is dropping packets (just from ping). The network is 8139 RTL-8139/8139C/8139C+ Rev 10
Adding the parameters "pci=noacpi acpi=off " has helped but it still happens.
Is there something else that helps the network not drop packets?
This probably won't be helpful, but whenever someone inquires about trouble with a Realtek network chipset someone ALWAYS responds that Realtek network hardware is junk and that you should replace it with something good, such as an intel e100 or e1000 or some such.
Me, I've never had trouble with a realtek card, myself.
On Sat, 27 Oct 2012, fred smith wrote:
To: CentOS ML centos@centos.org From: fred smith fredex@fcshome.stoneham.ma.us Subject: Re: [CentOS] 8139 dropping packets
On Sat, Oct 27, 2012 at 04:40:42PM -0400, Jerry Geis wrote:
I have a CentOS 5.8 box that is dropping packets (just from ping). The network is 8139 RTL-8139/8139C/8139C+ Rev 10
Adding the parameters "pci=noacpi acpi=off " has helped but it still happens.
Is there something else that helps the network not drop packets?
This probably won't be helpful, but whenever someone inquires about trouble with a Realtek network chipset someone ALWAYS responds that Realtek network hardware is junk and that you should replace it with something good, such as an intel e100 or e1000 or some such.
Me, I've never had trouble with a realtek card, myself.
Me neither.
I have a RT adapter on my laptop - no problems there either.
HTH
Keith
This probably won't be helpful, but whenever someone inquires about trouble with a Realtek network chipset someone ALWAYS responds that Realtek network hardware is junk and that you should replace it with something good, such as an intel e100 or e1000 or some such.
Me, I've never had trouble with a realtek card, myself.
Fred - thanks - but not an option in this case. Its built in and no slots available.
jerry
On 10/27/12 4:59 PM, Jerry Geis wrote:
This probably won't be helpful, but whenever someone inquires about trouble with a Realtek network chipset someone ALWAYS responds that Realtek network hardware is junk and that you should replace it with something good, such as an intel e100 or e1000 or some such.
Me, I've never had trouble with a realtek card, myself.
Fred - thanks - but not an option in this case. Its built in and no slots available.
with the newest intel desktop CPUs at least, the first ethernet controller is built into the southbridge (H77, Z77, etc), and if there's a realtek chip on there its just the 'PHY" physical interface.
ck your duplex. I have had two recent problems with duplex:
One, with a Cisco router - it auto-negotiated every time to half duplex, even though it really -was- full. Use mii-tool to find out.
Two, with a RR modem - the speed was forced to 10mb half duplex instead of 100mb full duplex. All sorts of strange loss. Once I put it back, all was well.
I have used TONs of 8139s, and while I do see where they are not the fastest kid on the block, I cannot say I've seen packet loss.
Bob
Bob - thanks,
I found this article: http://www.appliedtrust.com/resources/performance/untangling-ethernet-perfor...
my devices are 10/100 and auto-negotiate. I will be changing them as soon as I can.
jerry
On 29/10/2012 13:26, Jerry Geis wrote:
ck your duplex. I have had two recent problems with duplex:
One, with a Cisco router - it auto-negotiated every time to half duplex, even though it really -was- full. Use mii-tool to find out.
Just a note, auto-negotiation of 10/100 links will not work reliably unless both sides of the link are set to auto-negotiate.
If one side is set to 100/full, and the other side is set to auto negotiate, then it will try to negotiate, the side that is hard coded 100/full will _NOT_ negotiate and negotiation will fail, the side that was set to auto negotiate will fail back to a 'fail-safe' 10/half duplex link.
My rule of thumb, static link (e.g. those to servers, inter switch links, switch to router links etc...) should just be hard coded. Links that might have a variety of devices connected to them, e.g. the access layer ports - set them to auto-negotiate.
Is there any chances you can send in the stats of the interface? Just show if the driver says why it's being dropped.
------------ Banyan He Blog: http://www.rootong.com Email: banyan@rootong.com
On 2012-10-28 4:40 AM, Jerry Geis wrote:
I have a CentOS 5.8 box that is dropping packets (just from ping). The network is 8139 RTL-8139/8139C/8139C+ Rev 10
Adding the parameters "pci=noacpi acpi=off " has helped but it still happens.
Is there something else that helps the network not drop packets?
Thanks,
jerry _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Sat, 27 Oct 2012, Jerry Geis wrote:
I have a CentOS 5.8 box that is dropping packets (just from ping). The network is 8139 RTL-8139/8139C/8139C+ Rev 10
Adding the parameters "pci=noacpi acpi=off " has helped but it still happens.
Is there something else that helps the network not drop packets?
Upgrade to Centos 6. I have approx 20 jetway mini-itx boxes with a built in 8139. I recently had all but 2 experience large packet loss problems. Some of them were happily running C-5 for over 2 years. Upgrading them to C-6 solved it but I do not know why. I too would really like to understand what is going on here.
In addition, I would like to know why I still have 2 boxes that are happily running c-5.
I suspect that this is some kind of driver issue but I even tried upgrading the drivers using those supplied by EL-Repo. The only thing that improved the situation was upgrading to C-6.
FWIW, I use them as router/firewalls. They have a 3 port daughter board for a total of 4 Ethernet ports on them that I have recently switched to using an Intel based chipset just as a precaution.
HTH,