Raspberry Pi Wired Ethernet Intermittent

Thanks centipede for the detailed facts. There are a few facts to understand:

• The ethernet is 10/100 mb/s old style technology.
• The chip that runs the ethernet also shares the bandwidth with USB. This means the FIFO stack is probable also shared(?)
• Although the Pi is getting better in some aspects like CPU/GPU/RAM, they have NOT changed the USB/ethernet chip.
• Because of the above, the Raspberry Pi is a nice to play with but not ready for heavy usage like you are seeing. Other players in the SBC arena are either better or encroaching on performance of the RPi. In my case I am using the RPi 3 only in daily operations using the WiFi constantly sending/receiving data. Except for one power outage, the system has been robust so far. I do not really tax it IMHO.

Clem 

Clem,

Thank you for your reply.

Yes, I suppose it's possible that the Raspberry PI is just not capable of sending out large amounts of data over the wired Ethernet connection, although if that were the case, I would think there would be many posts online about that limitation.  Rumors abound, and many posts online talk about using the Raspberry Pi as a web server, why has no one else already complained about this?

So I am expecting this to be some kind of configuration issue, or a driver bug.  If there is a  FIFO which fills up, then there should be a log message about that someplace.  Also, when using a ping to recover, it's interesting to see that the transfer picks up where it left off, without any apparent error other than the delay. It is also interesting that inbound files, even huge ones are transferred very very quickly and without an issue.  If this is a FIFO issue, why does not inbound traffic get affected?  If a buffer is the issue with outbound traffic, it would seem the TCP stack could be adjusted to reduce the window size, smaller chunks could be sent at a time.

One more interesting bit of information, I find that sending a ping towards the PI also 'wakes up' the wired Ethernet.

Robert

I really hate it when people just say weird things like: 100 mbps is old technology so don't expect it to work every time. Or: "the pi is not suited for large amounts of data because USB is shared with Ethernet".

In your case, "2 or 3 megabytes" is an amount of data that the Ethernet chips should be able to transfer in about 200-300ms. Not all that long.

10mbps is old school. the lessons learned from that technology were taken along and used to improve "Ethernet" as a whole, and so 100mbps is very reliable and should work every time, all the time.

In the past, some software bugs have been found in the raspberry pi USB drivers. However, those mostly have been rooted out. Similarly, millions of people around the world will be transferring files like 2 or 3 megabytes in size. And since we don't hear more often that it doesn't work, I would guess that there is something in your specific situation that causes these Ethernet dropouts.

First, if you you ping your upstream router and watch for dropped packets and if one doesn't come back immediately do an ifdown/ifup on eth0, you probably have a workaround that works a lot better than now. But this is an ugly workaround that should not be needed. (TCP sends the first retry after 3 seconds. If you get it working again before those three seconds, there will only be a small delay before it works again, the next retry happens 6 seconds later, so if you wait for "more than three packets lost" you'll create a delay of 9 seconds for users who hit that Ethernet dropout...)

But the real solution lies in finding why things go wrong. I don't think we can rule out "hardware". The Ethernet chip draws all its power from the 3.3V supply line. SD interfacing probably uses that too. And the wireless chip is on an SD interface as far as I know. So... do you have an oscilloscope? Can you set it to trigger at 3.2V and watch the 3.3V line? (Pin 1 on the GPIO connector P1).

If you get 3.3V dropouts, do the same on the 5V line. Check for brownouts on the 5V line.

Oh. The 5V you can check without a scope: Watch the red led. Does it blink when this happens?

Roger,  Thank you for your thoughts and comments.

I expect the PI to be slower to respond compared to a full size tower server, but what I do not expect is for it to fail by locking up.  So, I agree with you that there is something in my setup that is causing the problem.  But my setup SHOULD work, and mostly does.  Please understand that I am not a newbie when it comes to computers, networking, circuit design, programming and such, my gray hair can attest to that..  But this one has me stumped even after a month of on and off trying.

My setup includes a 'shield' of my own design, and with it, I supply power to the PI via the 5 volt pins on the 40 pin connector, and I use a bit of power from the 3.3 volt line.  My MSO-2012 scope on the 3.3 volt line shows some occasional ripple, with peaks of up to 3.48 volts and dips of down to 3.28 volts.  On the 5 volt line, I see voltages between 5.00 and 5.08.

One more thing to throw into the mix, I have two outgoing data streams.  One is on PI's port 80, with the serving of web pages.  This is the one that fails from time to time, but only when a page is initially loaded.  The design of my web page is such that once loaded, no additional transfers are needed, via port 80.  The other data stream is on PI's port 8000 and is an HTML5 WebSocket connection.  The WebSocket stream sends continuous data back and forth to the brower's javascript as fast as possible, typically at least 10 packets per second on a slow tablet, but up to 100 packets per second if the browser is running on a fast enough machine.  This second data stream is designed such that one packet is sent by the PI and then one packet is sent to the pi.  The packets are small, less that 64 bytes plus TCP/IP overhead.  This data stream will run all day with no errors, even if I have several machines each sending/receiving their own packet stream using port 8000 at the same time.  I think the difference is the stream on 8000 is sending smaller packets, and sending them one at a time. 

So I can keep the hardware quite busy sending packets and have it work reliably, as long as the packets are either small or sent one at a time with a reply (meaning an application level reply, not an ACK) .  So I do not think the problem is hardware as such, IE power, overheating, and things of that nature.  Rather i expect that some kind of buffering issue, perhaps caused by the hardware, which, if true, should be compensated for by the driver code, or something in the configuration.

Robert

Ah! great! Finally someone with the proper tools to debug the voltages.. :-)

The peaks on the 3.3V are unexpected and high. But that shouldn't cause any failures, as it is all supposed to keep working between 3.0V and 3.6V. So the (IMHO) most likely culprit is ruled out.

Is there a way that you can tell me what I should do to reproduce the problem? Preferably: simple, preferably no WIFI etc.

Besides, if successful in providing a test-case, this would force you to try and simplify the problem. Does the WIFI come into the mix. If you can't reproduce without the WIFI, maybe something in the wifi driver causes the problem. That would then be a hint as to what is going on.

Another thing you might try is to run TCPDUMP on the 'pi and on the ethernet. (hopefully your router on the ethernet is also a Linux box so that you can run TCPDUMP there.

What I'm expecting to see is that you get 3-5 packets that the pi reports as "sent" when are never seen physically on the ethernet....

Oh, yes... I've seen my fare share of driver lockups. Sometimes due to bugs in chips... (There is an ATM chip that I wrote the driver for. It is a derivative of a bigger chip. The bigger chip rules out deadlocks by having more buffers than channels. The smaller chip doesn't have a deadlock prevention that it needs because it has more channels than buffers.... )

Update... There is a Raspberry pi 2 on my desk (not three. sorry) I've measure the 3.3V, my scope measures "Vavg (ch2) = 3.38V". I see a 15mV spike about every 6.3 microseconds. The spike mostly goes "up" for about 500ns and the "down" that I see on the "overview" scope-shot is acutally part of a much much shorter spike, going sometimes down, sometimes up -10mV to +10mV with about a 20ns duration.... (With only 40mHz bandwidht on my scope that's beyond what I should be able to measure... i.e. take it with a grain of salt....).  

Roger, A good suggestion, thank you.

I used the original jessie file which I downloaded on 6/2/2016 and imaged it onto an 8 gig SD card.  I then booted the PI, and without any changes at all, uploaded a 3 meg file to the /home/pi directory.  Next I tried to download the same file and got this result with FileZilla:

Status:    Starting download of /home/pi/01 - Sgt. Pepper's Lonely Hearts Club Band.mp3

Status:    remote:/home/pi/01 - Sgt. Pepper's Lonely Hearts Club Band.mp3 => local:E:\raspberry pi 3\var\music\down\01 - Sgt. Pepper's Lonely Hearts Club Band.mp3

Error:    Network error: Software caused connection abort

Error:    File transfer failed after transferring 32,768 bytes in 18 seconds

Status:    Disconnected from server

So the problem occurs with the standard software and an 'out of the box' PI-3B board.

Robert

Hi centipede

     I tried to setup a similar situation with my RPi 3 since I have one too. I installed Filezilla on my intel production box running Zorin (Ubuntu like) Linux. I installed the following FTP server:

apt-get install proftpd

Here is the file I used:

I copied the highlighted file from the Zorin to the Raspberry Pi 3 and back:

I had no problems running this on a local network within the same subnet.

Here is the PI software level that is older than yours:

pi@raspberrypi:~/Downloads $ uname -a

Linux raspberrypi 4.1.18-v7+ #846 SMP Thu Feb 25 14:22:53 GMT 2016 armv7l GNU/Linux

So you can compare yours to mine and tel me the difference. I may have a different ftp server than you.

Clem

Never mind I used the wireless.

Ops!

Robert Laughlin wrote:

Next I tried to download the same file and got this result with FileZilla:

 

Filezilla is listed as an FTP client on raspbian. And such graphical clients don't stay single-protocol for long. So even if it starts out as an FTP client, it usually gains ssh support within a few release cycles. So what "server" are you using on the 'pi?

I can copy a file of 15M in a few seconds using rsync over ssh.

sent 30 bytes  received 15,673,683 bytes  4,478,203.71 bytes/sec

By using rsh instead of ssh I can increase the transfer speed up to about 8Mbytes per second without any trouble. All this is on a pi 2, I'll test the PI 3 later today for you (but I expect the same results).

Update: I now saw clem install proftpd, so I did too. proftpd increases the transferspeed of my 15Mb file to 11 Mbyte per second: almost line speed.

Not sure this makes a difference or not, but in my test, FileZilla, version 3.18.0, was running on my desktop machine, the ftp server was on the PI, and was what ever comes with the jessie file.  FileZilla was set for SFTP, using the default transfer mode.  Here is the version of jessie:

pi@raspberrypi:~ $ uname -a

Linux raspberrypi 4.4.11-v7+ #888 SMP Mon May 23 20:10:33 BST 2016 armv7l GNU/Linux