LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 12-24-2006, 05:35 AM   #1
rylan76
Senior Member
 
Registered: Apr 2004
Location: Potchefstroom, South Africa
Distribution: Fedora 17 - 3.3.4-5.fc17.x86_64
Posts: 1,552

Rep: Reputation: 103Reputation: 103
Dropped packets reported by ifconfig - implication?


Hi again all

Ifconfig reports the following for my eth0 interface:

eth0 Link encap:Ethernet HWaddr 00:16:E6:5D:F3:65
inet addr:169.254.255.20 Bcast:169.254.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1578 errors:0 dropped:0 overruns:0 frame:0
TX packets:1500 errors:0 dropped:17 overruns:0 carrier:0
collisions:0 txqueuelen:2000
RX bytes:569081 (555.7 KiB) TX bytes:270212 (263.8 KiB)
Interrupt:153 Base address:0x9000

I've noticed that between ifdowning and ifupping the inferface (which I have to do all the time because it keeps failing) has different numbers of dropped TX packets coming up.

I've also noticed that a higher number of dropped packets causes that connection instance to fail quicker than others. By "fail" I mean that externally the box stops responding to pings, and itself can't ping out anymore, nor can any traffic go anywhere.

On my previous linux installation (FC3) on another motherboard with a different NIC there were NO dropped packets of any kind.

How can I prevent dropped packets? Are these dropped packets what are causing my regular outages on eth0?

ANY help appreciated!

Thanks,
 
Old 12-24-2006, 10:36 AM   #2
rylan76
Senior Member
 
Registered: Apr 2004
Location: Potchefstroom, South Africa
Distribution: Fedora 17 - 3.3.4-5.fc17.x86_64
Posts: 1,552

Original Poster
Rep: Reputation: 103Reputation: 103
Hi guys

Just thought I'd report that it seems I've got this mitigated further or maybe licked in total!

Apparently, the implication of dropped packets is a too long queue length, and will soon lead to the sendmsg: no buffer space availabe error.

It seems the buffer overflows I was experiencing was caused by a too long transmission queue length. I've changed the transmission queue length to 500 instead of the default 1000 by doing:

/sbin/ifconfig eth0 169.254.255.20 netmask 255.255.255.0 broadcast 169.254.255.255 txqueuelen 500 up

Now, if I run ifconfig I no longer have dropped packets:

eth0 Link encap:Ethernet HWaddr 00:16:E6:5D:F3:65
inet addr:169.254.255.20 Bcast:169.254.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1701246 errors:0 dropped:0 overruns:0 frame:0
TX packets:1135670 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:2447542857 (2.2 GiB) TX bytes:100667936 (96.0 MiB)
Interrupt:177 Base address:0x9000

Previously I had dropped packets indicated with a queue length of 1000. For the record, this is on a Gigabyte GA945PL-S3 motherboard with FC6 with a custom compiled 2.6.18.1 kernel with the

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)

NIC as indicated by lspci. I'm running the RealTek Linux driver for this card.

I further also massively increased certain buffersizes that were autotuned by the kernel. I've not tested if the queue length was the deciding factor (it works, so I want to leave it as it is!) but I also did this:

echo 98886080 > /proc/sys/net/core/wmem_max
echo 98886080 > /proc/sys/net/core/rmem_max
echo 98886080 > /proc/sys/net/core/wmem_default
echo 98886080 > /proc/sys/net/core/rmem_default
echo 32767 > /proc/sys/net/core/optmem_max
echo 256 > /proc/sys/net/core/somaxconn
echo 2000 > /proc/sys/net/core/netdev_max_backlog

echo 0 > /proc/sys/net/ipv4/tcp_timestamps
echo 1 > /proc/sys/net/ipv4/tcp_sack
echo 1 > /proc/sys/net/ipv4/tcp_window_scaling

echo 26244 786432 1048576 > /proc/sys/net/ipv4/tcp_mem
echo 43960 4194304 8194304 > /proc/sys/net/ipv4/tcp_rmem
echo 43960 4194304 8194304 > /proc/sys/net/ipv4/tcp_wmem

Hope this helps somebody else?
 
Old 12-24-2006, 11:21 AM   #3
rylan76
Senior Member
 
Registered: Apr 2004
Location: Potchefstroom, South Africa
Distribution: Fedora 17 - 3.3.4-5.fc17.x86_64
Posts: 1,552

Original Poster
Rep: Reputation: 103Reputation: 103
:(

NOT Solved

Its doing it again...

Getting desperate. Anyhow...
 
Old 12-24-2006, 02:48 PM   #4
Brian1
LQ Guru
 
Registered: Jan 2003
Location: Seymour, Indiana
Distribution: Distribution: RHEL 5 with Pieces of this and that. Kernel 2.6.23.1, KDE 3.5.8 and KDE 4.0 beta, Plu
Posts: 5,700

Rep: Reputation: 65
Seen this post earlier and over at Fedora Forums.
Question are you connecting to a gigabit switch?

Brian
 
Old 12-24-2006, 05:21 PM   #5
teckk
LQ Guru
 
Registered: Oct 2004
Distribution: Arch
Posts: 5,137
Blog Entries: 6

Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
Are you getting your IP from a DHCP server like a router?
You may want to change everything on the network to a fixed IP address. See if that solves your problem. Linux has a problem with the way it gets IP addresses from a DHCP server with some routers. It will cause random stalls on the network and with the box in general. I assume there is a stall when IP leases are renewed, but it affects the whole box. And yes ifdown and ifup will solve it temporarily.

I still haven't discovered the cause of it but setting everything to a fixed IP will solve it. If this is the problem that you are having.
 
Old 12-31-2006, 03:48 AM   #6
rylan76
Senior Member
 
Registered: Apr 2004
Location: Potchefstroom, South Africa
Distribution: Fedora 17 - 3.3.4-5.fc17.x86_64
Posts: 1,552

Original Poster
Rep: Reputation: 103Reputation: 103
Hi guys

Thanks for repyling. No I'm on a normal 100MBit LAN, and the NIC was running in 100MB mode...

I've since given up on it (since I simply have to have a reliable NIC in this box) and disabled it in the BIOS. I put in an older 100MB 8139 based NIC in a PCI slot in the box and everything is working 100% fine now. It's got no dropped packets reported, and it never goes down like the 8168B does constantly with the Realtek driver...

Anyway, using the stock RTL-8139 driver in the kernel now works perfectly with the PCI 8139, so my problem is sort of solved. Guess the Gigabit NIC is still not really usable with the Realtek driver, but I'm ok to stay at 100MBit for a while yet.

Thanks for taking the time to reply!
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Dropped packets Doolspin Linux - Software 1 10-22-2006 01:22 PM
too much dropped packets...Hi.. alaios Linux - Networking 2 02-10-2005 04:49 AM
Dropped packets - is this a problem?? benr77 Linux - General 4 10-04-2004 02:05 PM
tcpdump and dropped packets Blindsight Linux - Networking 5 07-14-2003 10:41 PM
dropped packets... sohmc Linux - Software 3 05-29-2003 09:26 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 07:39 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration