Hello, I just started running my little 5 mbits mid relay on Pi3 on raspbian and all seems to be dandy, it picked traffic nicely, hovering around 700-800 total connections, its not unusual to see it pushing full advertised bandwidth during peak hours (with ~20-25% load on 1 core, multithread pls come already), tldr so far nice. Except with 3days uptime and 20 gigs of data relayed ifconfig shows 11 (eleven) packets dropped on eth0. Google says it can be ring buffer on NIC getting full, but ethtool -g eth0 says Ring parameters for eth0: Cannot get device ring settings: Operation not supported ethtool -S eth0 = no stats available Htop avg load is 0.30, tor uses 121/950mb of ram. Im running standard conntrack cstate established related iptable rule with default drop. Pi3 is in LAN behind modem nat. It worries me because if I get more consensus, drops will probably go up. I didnt apply any sysctl tweaks. Using official deb NIC is Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter and its internally connected to usb2 by design - it shows under lsusb. ethtool says 100Mb/s full duplex. Tor log is clean with only heartbeat in it, syslog seemed ok also if I didnt miss anything. Or is it so marginal I should forget about it? Im not sure what should I do about it, any suggestions are welcomed. Thanks
On Mon, 15 Aug 2016 20:08:31 +0200 Pi3 tor-relays@mixbox.pl wrote:
Hello, I just started running my little 5 mbits mid relay on Pi3 on raspbian and all seems to be dandy, it picked traffic nicely, hovering around 700-800 total connections, its not unusual to see it pushing full advertised bandwidth during peak hours (with ~20-25% load on 1 core, multithread pls come already), tldr so far nice. Except with 3days uptime and 20 gigs of data relayed ifconfig shows 11 (eleven) packets dropped on eth0. Google says it can be ring buffer on NIC getting full, but ethtool -g eth0 says Ring parameters for eth0: Cannot get device ring settings: Operation not supported ethtool -S eth0 = no stats available Htop avg load is 0.30, tor uses 121/950mb of ram. Im running standard conntrack cstate established related iptable rule with default drop. Pi3 is in LAN behind modem nat. It worries me because if I get more consensus, drops will probably go up. I didnt apply any sysctl tweaks. Using official deb NIC is Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter and its internally connected to usb2 by design - it shows under lsusb. ethtool says 100Mb/s full duplex. Tor log is clean with only heartbeat in it, syslog seemed ok also if I didnt miss anything. Or is it so marginal I should forget about it? Im not sure what should I do about it, any suggestions are welcomed. Thanks
Like others explained, just 11 frames (at maximum, around 15 KB or so in 20GB!) is practically nothing, so there is no reason to worry. Also keep in mind that frames can be dropped for legitimate reasons, e.g. if for some reason the board sees packets on the wire which are not addressed to it, or oversized, or generally malformed in some way by the other side. In any case, thanks to TCP any dropped frame (=lost packet) gets rapidly retransmitted with no significant impact on throughput or connection stability.
That said, I remember from reading various Raspberry Pi forums that the smsc95xx device doesn't exactly have the reputation of the most reliable or well designed piece of hardware in the world (mostly related to attempts to make various 'unusual' USB devices such as some audio interfaces to work with it, or using a number of USB devices concurrently), so considering your results it's actually working amazingly well for you so far. :)
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1053088862188 errors:0 dropped:0 overruns:511390 frame:0 TX packets:306784541602 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1413645618747401 (1.2 PiB) TX bytes:317045507788162 (288.3 TiB) Memory:80000000-8001ffff
Over half a million packets lost. Nothing to worry at all. Even good packets get sometimes hurt. I would not worry about your 11 packets :)
Markus
2016-08-15 21:50 GMT+02:00 Roman Mamedov rm@romanrm.net:
On Mon, 15 Aug 2016 20:08:31 +0200 Pi3 tor-relays@mixbox.pl wrote:
Hello, I just started running my little 5 mbits mid relay on Pi3 on raspbian and all seems to be dandy, it picked traffic nicely, hovering around 700-800 total connections, its not unusual to see it pushing full advertised bandwidth during peak hours (with ~20-25% load on 1 core, multithread pls come already), tldr so far nice. Except with 3days uptime and 20 gigs of data relayed ifconfig shows 11 (eleven) packets dropped on eth0. Google says it can be ring buffer on NIC getting full, but ethtool -g eth0 says Ring parameters for eth0: Cannot get device ring settings: Operation not supported ethtool -S eth0 = no stats available Htop avg load is 0.30, tor uses 121/950mb of ram. Im running standard conntrack cstate established related iptable rule with default drop. Pi3 is in LAN behind modem nat. It worries me because if I get more consensus, drops will probably go up. I didnt apply any sysctl tweaks. Using official deb NIC is Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter and its internally connected to usb2 by design - it shows under lsusb. ethtool says 100Mb/s full duplex. Tor log is clean with only heartbeat in it, syslog seemed ok also if I didnt miss anything. Or is it so marginal I should forget about it? Im not sure what should I do about it, any suggestions are welcomed. Thanks
Counter-point... transmission errors are not a certainty:
RX packets:323526978271 errors:0 dropped:0 overruns:0 frame:0 TX packets:249565709357 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:285274358053849 (285.2 TB) TX bytes:287754558279252 (287.7 TB)
Ideally there should be no errors. :)
11 dropped packets isn't a big deal, but I wouldn't be quick to dismiss these errors by default. In certain cases things might be improved with driver updates, or sysctl tweaks, or a new ethernet cable, etc.
tor-relays@lists.torproject.org