Hi. On Fri, 19 Jun 2015 20:38:12 +0200 Sven Hartge <s...@svenhartge.de> wrote:
> Reco <recovery...@gmail.com> wrote: > > On Fri, Jun 19, 2015 at 02:47:20PM +0200, Petter Adsen wrote: > >> On Fri, 19 Jun 2015 14:09:45 +0200 > >> basti <black.flederm...@arcor.de> wrote: > >>> On 19.06.2015 14:03, Sven Hartge wrote: > >>>> basti <black.flederm...@arcor.de> wrote: > > >>>>> iotop show me a read speed around 3 MB/s, there is a Class 10 UHS > >>>>> card (10-15 MB/s read, 9-5 MB/s write I guess). > > >>>> More than 3MByte/s is not really achievable with a Pi-1, because > >>>> the CPU is very weak and the Ethernet-Chip is attached via USB. > >>>> > >>>> Under the best conditions you may be able to transfer up to > >>>> 45MBit/s, but a maximum transfer rate of about 35MBit/s is normal. > > >>> The Problem is not the speed of 3 MB/s it's the load of 12 and more. > >> > >> The load is so high because USB is very CPU-intensive. If you were to > >> use the on-board Ethernet, you would not see such a high load. > > > What? Are you serious? I have this Nokia N900 lying behind me which is > > connected by IP-via-USB (aka usbnet aka g_ether) and with the order of > > magnitude slower ARM CPU it reliably shows 40mbps with no noticeable > > load. > > Maybe the USB hardware implementation is better in the N900? The one in > the Pi is quite bad and finicky. I happen to have Pi too. Not that I need an NFS server on it, NFS client is sufficient for my needs, but still. > In addition to that, data transfer via USB is quite CPU-intensive, as > Petter wrote and overwhelms the single CPU core of the Pi if it needs to > drive the SD card at the same time. Hm. I plugged an Ethernet cable into it, read and wrote a big file via NFS. Got consistent 50mbps. According to iperf, I could go as high as 82.2 mbps. Not the fair gigabit I have on this LAN, but close to theoretical 100mbit limit of the NIC. During the NFS test, two kernel threads were the worst CPU consumers, kworker/0 and ksoftirqd/0. During the iperf test, the worst CPU consumers were iperf itself and ksoftirqd/0. According to the /proc/interrupts, the top interrupt consumer was IRQ32, which is: dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1 On the other hand, a simple cat /dev/zero > file test provided me with 100% iowait, but no actual CPU usage. Perf mysteriously failed on me. It did record something, but 'perf report' refused me to show anything. Must be something with this custom Raspbian kernel. So, I agree that using Pi's Ethernet interface eats CPU, but saying 'USB eats CPU' is oversimplifying thing quite a bit. Specifically, if NFS is involved. What I suspect was happening with your NFS server is the multiple knfsd threads in D-state (i.e. blocked by iowait by slof MMC card) *plus* this USB Ethernet interrupts. I'd start with lowering knfsd count. > If the source or destination of the transmitted data is on an USB medium > it gets even worse because all USB ports share the same root port on the > SoC. I'm too lazy to check it, so I'll trust you on this. > Besides: I always found the load on Linux NFS servers to be higher than > on a Samba-Server with equal throughput. I guess the calculation of the > load is different for the NFS kernel server process than for userland > fileservices. I have to trust you on this too. Never bothered myself with inferior network filesystems (Samba) due to the existence of superior one (NFS4). And, speaking of those network filesystems. Have you tried to use iSCSI to do whatever you're trying to do with NFS? What about a simple sshfs? Reco -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150619222457.216fb96452d765f16fb17...@gmail.com
