Sven Hartge wrote: > Reco wrote: > > Sven Hartge wrote: > >> Maybe the USB hardware implementation is better in the N900? The one > >> in the Pi is quite bad and finicky. I am coming to this discussion late but I had to confirm that the USB chip in the Raspberry Pi is very limiting. It has a maximum bandwidth of around 50Mbps and everything including ethernet goes through it. This means that if you have one data stream that it will get a maximum of 50Mbps. If you have two streams, such as if using the Raspberry Pi for a router and it is routing packets in one interface and out a different one, then the maximum throughput is 25Mbps with one stream in and one stream out. I have a good friend who has worked on the drivers for the pi and he told me that the usb chip generated a minimum of 2000 interrupts per second even at idle. I will pass that along as hearsay because it seems plausible. For example this CEC limitation makes the Raspberry Pi acceptable for an 802.11b WiFi access point at 11Mbps but not able to keep up with 'g' or 'n' speeds. It is simply hardware limited. If you have 8 nfsds running and let's say each of them try to use only one data stream then each will get only 6.25Mbps maximum. They will spend a lot of time in the run queue blocked on I/O waiting for the network to respond. basti wrote: > Per default nfs starts with 8 servers > root@raspberrypi:~# head -n 2 /etc/default/nfs-kernel-server > # Number of servers to start up > RPCNFSDCOUNT=8 As you have found doing any type of real transfer will immediately consume 8 processese because each daemon will be in the run queue ready to run but waiting for I/O. The biggest problem is that each daemon will consume *memory*. The daemon won't consume cpu while it is blocked waiting on I/O. But it will consume memory. Memory for the nfs daemons. Memory for the kernel to track the multiple network streams active. Memory for file system buffer cache. Everything takes memory. The Raspbery Pi has a limited 512M of ram. I like seeing the bar graph of the memory visualization from htop. I suggest installing htop and looking at the memory bar graph displaying the amount of consumed memory and the amount available for cache. > So I try to transfer a 3GB file from the raspberry to my laptop via > WLAN(n). This operation kills my raspberry. I get a load of 12 and > more. 10 Minutes after I interrupt this operation the load was still > at 10. In addition to the 8 processes consuming memory from the 8 nfsds there will need to be additional cpu to deal with the driver for the usb chip. It will need to handle the accounting for the multiple network streams. A single stream will take less resources than 8 streams. And anything else that happens along. That extra accounts for the load of 10 you are seeing. But the real problem is probably the lack of memory. The many processes stacked up and the I/O buffers will likely have consumed everything. > So I deside to reduce the number of servers to 2. Now it's a bit > better, the load is only around 5. That was a good configuration modification. About the best you can do. > Can somebody reproduce this behavior? Yes. Easily! It is simply a natural consequence of the limited hardware of the Raspberry Pi. I have become a fan of the newer Banana Pi. It is very Raspberry-like but has a different CEC and doesn't have that very limited 50Mbps usb chip found on the Raspberry. On the Banana Pi there is 1G of ram, twice that of the Raspbery. It is a dual core arm, again twice the Raspberry. It is an armv7l architecture and therefore runs stock Debian. And best yet for your purposes it has much higher speed I/O. On the Banana Pi I can routinely get 750Mbps through a single ethernet connection. That is about the same performance as an Intel Atom D525. The Banana Pi makes a much better practical machine than the Raspberry. The price of the Banana is currently running around US $42 only $7 more than the Raspberry. It is a much more capable machine. I don't know about the new Raspberry quad core. Does it have the same limited usb chip as the original? Bob
Attachment:
signature.asc
Description: Digital signature