I need to run a UDP stream from a gigabit-enabled x86 host to a Raspberry Pi , and to avoid congestion, which occurs due to the bitrate mismatch, I have enabled flow control on the switch port the Pi is connected to.

However, if I try and check flow control with ethtool, I get:

pi@raspberrypi2 ~ $ sudo ethtool -a eth0 
Pause parameters for eth0:
Cannot get device pause settings: Operation not supported

If I try to enable flow control with ethtool -A, the same result occurs:

pi@raspberrypi2 ~ $ sudo ethtool -A eth0 autoneg on rx on tx on
Cannot get device pause settings: Operation not supported

Does the NIC simply not support flow control? In a world where gigabit ethernet is the standard, that would be definitely be unfortunate.

  • "In a world where gigabit ethernet is the standard" -> If you mean because a 100BASE-TX can't stay above water in such a context without hardware flow control, it should be irrelevant for TCP based connections because TCP implements flow control from the receiving end. No proper host will, e.g., accidentally DoS the pi that way, so having to do this from the switch would always remain theoretical. – goldilocks Jul 8 '15 at 12:26
  • Indeed, TCP applications are unaffected. But if you'd like to use UDP, as in raspberrypi.stackexchange.com/questions/10532/… or if your application requires multicasting, you are likely to run into a variety of problems. As the RPi is perfectly suited to multimedia applications, this is a common scenario. – kiko Jul 9 '15 at 16:48
  • Yes, but unless you are trying to use the pi to multiplex hundreds of streams at once (which I am sure it will fail at anyway), current streaming media does not come anywhere close to gigabit speeds; 100 Mbps should be plenty enough for anything. If you simply want to download a media source as fast as you can (i.e., much faster than it could be played back at 1:1 time), you're doing it with TCP. – goldilocks Jul 9 '15 at 17:00
  • ...Reading your other question does call this into question -- but I think you are on the right track at questioning how avconv works. If it simply goes as fast as it can, that's a problem (you could time the volume of data on the sender side to confirm this, obviously if it exceeds 100 Mbps that's the problem). – goldilocks Jul 9 '15 at 17:06

It seems to have negotiated flow-control by default (without asking for it):

$ sudo mii-tool -v eth0
eth0: negotiated 1000baseT-HD flow-control, link ok

Note: I'm on the Pi 2. Strangely it should be 100baseTx-FD (full-duplex) and it seems I have a problem that my Pi negotiated half-duplex. But journalctl says that it is full-duplex 100Mb/s (kernel: smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC1E1) So I'm not sure about mii-tool reliability. But looking at the source code of the module, there are some codes which is your interface is full-duplex could set up flow control for rx and tx.

You could use mii-tool to verify your current settings or to change them.

| improve this answer | |
  • Are you sure flow-control is actually working? I ask because I've been unable to capture any pause frames generated by the RPi NIC. I enabled flow control on the x86 host side, on both switch ports and I ran mii-tool as you suggested above. Packet captures on the x86 side pause frames being generated (by the switch NIC) but I see nothing on a capture on the RPi side. I realize capturing pause frames can be tricky as per serverfault.com/questions/415993/… but in application testing I still verify packet loss. – kiko Jul 9 '15 at 16:53
  • @kiko I also don't see anything on Wireshark. I have set-up a Linux box with a 1Gb/s NIC connected to the switch with flow control ON, and the Pi also connected to the switch and with flow control ON. Of course the flooding only happen from the faster NIC, and I can see on the switch that pause frames are being sent to the faster NIC (but I don't see them in Wireshark). At least I can see that flow control is working on half of the connection. I would need to find a slower device than the Pi to test, I'm afraid I don't one around. – Huygens Jul 14 '15 at 12:08
  • Perhaps the right way to test it would be to remove the switch from the equation, connecting the Pi directly to the host? – kiko Jul 15 '15 at 13:25
  • Yes that would be the right way, or by using a dumb switch. But I'm afraid you will have to try that out for yourself. I don't have performance problem which would require me to investigate the use of flow control. So flow control is disable on each port of my switch and the Linux TCP flow control algo is doing a good job for me. – Huygens Jul 15 '15 at 15:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.