USB outbound SLOW on Raspberry Pi
Colin (478) 2433 posts |
I don’t have a Pi. Can you tell me if transfers to hard discs are slow as well? If transfers to hard disc are OK then it shows that bulk transfers can be fast. SCSISoftUSB transfers data in large chunks. Are you having to make lots of small transfers? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jan Rinze (235) 364 posts |
Both my BB and Panda suffer from slow outbound network traffic. On the BB the result is worst with 100kB/sec. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Chris Hall (132) 3494 posts |
Using LANMan98 (rather than LANMan or ShareFS) improves things considerably:
I get 15 to 20 Mbytes/s for block load and save using the SD card and SDFS (Pandaboard faster than Beagleboard, both dependent on speed of SD card itself). |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Thomas Milius (1471) 64 posts |
We made tests over network using localloopback. All will be fine. I also don’t have a RPi. Regarding disc writes speed seems to be fine but one user reported penetrant corruption of his SSD in conjunction with RPi. It can be shown that parts of the network transfer outbound on the RPi are running as fast as on ag the BB xM however you can show that inside the transfer the speed toggles from fast to slow and back. I assume that some network packages are getting corrupted during their way over EtherUSB and the host controller. FTPc will also make no joy (ok also EtherUSB) but you can use it in conjunction with UMTS/GSM with my COMCentre Package and Acorn PPP. Whilst it its working fine on the BB xM with the combination it will fail on the RPi. Raik Fischer told me that the effect should have been present also on earlier RPI Version not using the SMSC chip. EtherUSB on the BB xM works fine for me. So it must be a small difference in the behaviour of both machines casuing this silly effect. Overall the main difference is the USB host controller driver in my opinion. May be that some defaults are different than the BB xM driver and EtherUSB relies on the not RPi settings or something other is wrong. It seems that the effect occurs seldom but cause penetrant swaps. Candidates from my view of sight are the short package transfer or cases where transfer length matches a multiple of the pipe size. Also something which could be examined is the handling of the interrupt pipe of the SMSC network chip. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Colin (478) 2433 posts |
Chris. I’m afraid your benchmarks mean little to me. What is a HD read/write and how is it different to a FS read/write and the percentages are a percentage of what? Looking at the numbers alone does make a mockery of this thread as the Pi performs favourably against the other machines. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Colin (478) 2433 posts |
Thomas. I have done tests on an Iyonix forcing FORCE_SHORT_TRANSFER on every bulk transfer and found it reduced SCSISoftUSB transfers by about 10% – I cant remember exactly but I didn’t consider it significant. However SCSISoftUSB only makes large multiple packet sized transfers and under normal conditions would only have 1 short transfer per file transfer and so the device would see the transfer as a single transaction. Has anyone tried using a USB ethernet adapter on a Pi and does that behave the same? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Chris Hall (132) 3494 posts |
I’m afraid your benchmarks mean little to me. What is a HD read/write and how is it different to a FS read/write and the percentages are a percentage of what? The benchmarks are explained here – the ‘HD read’ and ‘HD write’ are for block load and save of a 1Mbyte file (expressed in Mbytes/sec) whereas the ‘FS read’ and ‘FS write’ are for byte by byte file transfers (expressed in kbytes/sec) with the percentages based on a StrongArm RiscPC. The network read speed on a Pi (to load a 1Mbyte file) is shown above as 3 times faster than the rest. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Colin (478) 2433 posts |
Thanks. Is the byte by byte using OS_BGet or fgetc from C |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jan Rinze (235) 364 posts |
Did a bit more testing, et voila: the MCS7830 backend seems to be the very slow one. (tried the USB adapter from the BB on the Panda and compared results with the onboard Ethernet.) |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Raik (463) 2026 posts |
What Thomas mean… |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jan Rinze (235) 364 posts |
USB ethernet adapters are very hard to find these days. I have 3 at home which all have the MCS7830. :-( |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
patric aristide (434) 418 posts |
What do you mean by saying that? No problem whatsoever using this one: http://www.amazon.co.uk/USB-2-0-Fast-Ethernet-Adapter-100/dp/B0012E8Z0U In case you’re talking about uploads I did however manage to crash Omni when trying to transfer some data to my NAS. Haven’t tried LanMan98 yet. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Chris Hall (132) 3494 posts |
Is the byte by byte using OS_BGet or fgetc from C OS_BGet/OS_BPut from assembler, counts how many bytes have been transferred in one second. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jan Rinze (235) 364 posts |
@patric: buying an adapter on amazon will not help here. If it is a MCS7830 it will become my 4th wrong usb adapter. Conrad, Amazon and many other webshops won’t tell you which chipset is used. Buying randomly would deplete my funds. Found one from Velleman with the ASIX 88772 chipset. I need to recompile RISC OS since EtherUSB does not know its specific USB ID. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
patric aristide (434) 418 posts |
@Jan Rinze Seems you’re right, plugged it in and had a look at proc/bus/usb/devices: T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jan Rinze (235) 364 posts |
One interesting observation on the BB: With MUSB (OTG connected to powered HUB) I get with either network adapter around 400kB/s feels like tumblin’ down the rabbit hole.. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
James Peacock (318) 128 posts |
@Jan Rinze
It is not necessary to recompile. You can set an environment variable to allow EtherUSB to attempt to use devices it doesn’t recognise by default. See its !ReadMe file. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Steffen Huber (91) 1945 posts |
I think the USB-Ethernet adaptors for the Nintendo Wii feature one of the ASIX chipsets supported by EtherUSB. I had one from LevelOne which worked fine with the BeagleBoard and EtherUSB. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jan Rinze (235) 364 posts |
@James |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Jan Rinze (235) 364 posts |
It might be an idea to have a command *EJaddproduct |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Chris Gransden (337) 1148 posts |
I’ve found that overclocking the Raspberry Pi greatly affects the outbound network speed. The higher the overclock the faster the upload rate. With the default settings in CONFIG.TXT downloading a file using WebJames and Netsurf the outbound speed is about 20KBytes/s. Adding the following to CONFIG.TXT the outbound speed increases to 300KBytes/s. arm_freq=950 core_freq=500 sdram_freq=550 force_turbo=1 With these settings the outbound speed increases further to 1.2MBytes/s. arm_freq=1100 core_freq=700 sdram_freq=600 over_voltage=6 force_turbo=1 It looks like there could be some sort of timing issue which is causing the slow outbound speeds. Hopefully this will help to pinpoint where the problem is. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Colin (478) 2433 posts |
Does saving a large block of memory to a USB disc show similar improvements? |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Chris Gransden (337) 1148 posts |
Saving to USB disc stays the same. Write speed on the USB key I used is roughly the same as it is on a Pandaboard. The network speeds I got above were using a Pandaboard as the client. If I use a PC running linux and firefox as the client the transfer starts off at 1.2MBytes/s and drops to less than 100KBytes/s after about a second with the highest overclock. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Raik (463) 2026 posts |
The problem is also discussed by some members of the German Archimedes Group. Thomas had an interesting suggestion. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Thomas Milius (1471) 64 posts |
In the moment I am still examining the USB Host controller driver of the RPi. My in the moment unfortunately unproven theory is that there might be a bug inside handling of USB 2.0 PING protocol. This would match some entries inside log files we generated a while ago. It seems that the speed swap occurs in case that the internal buffer of the SMSC ethernet controller gets full however. For USB this means that SMSC will send an NAK at the next package to the host controller or at high speed devices an NYET which should cause at high speed entering a special PING protocol. If there would be an error in this area, so my theory, the slow down shouldn’t occur in full speed mode. Raiks tests are showing the exspected behaviour even of course there is still the possibility that the slow full speed transmission will never lead to such a special situation. I hope to be able to examine the according parts of the source during the next days. |