Extremely slow network on RPi

Dear all,

At last! I’ve a Raspberry Pi running on my desk and I think it’s a little miracle. It’s even faster than my good old Iyonix.

However, the latter is certainly not true for network speeds. Whether I copy something over the local network, or try to open a website in NetSurf, speed never exceeds a couple of hundred bytes per second.

I’ve tried both the automatic and the manual network settings. The latter are identical to those on my Iyonix, but to no avail.
What could possibly go wrong?

Kind regards,
Paul Sprangers

Check out this thread started by Herbert zur Nedden nine days ago:

http://www.riscosopen.org/forum/forums/11/topics/1893

It doesn’t fully explain the slowness of incoming transfers, though. I wonder if this batch (I assume you also have one of the Club’s, handed out last Saturday?) is a bit ‘iffy’. Mine is a little disappointing as well. Not because of networking (haven’t even started looking at that yet…), but because the HDMI output doesn’t work well on my Samsung 2333HD. It produces a picture I can only describe as nasty, while my Iyonix’s picture is crisp and clear.

I’ve seen the thread before during my search for an answer, but Herbert is only referring to problems when uploading through the local network. His download speeds seem to be normal.

On my RPi, however, any network speed is horribly slow, whether it’s about writing or reading throughout the local network, or trying to surf on the internet.

You’re right in assuming that I got mine from the Club last Saturday. Contrary to your experience, the HDMI output seems to be allright, although sound is still lacking (I added the hdmi_drive=1 line to the Config.txt file – to no avail).

Contrary to your experience, the HDMI output seems to be allright, although sound is still lacking (I added the hdmi_drive=1 line to the Config.txt file – to no avail)

hdmi_drive=2 worked for me. See here

As far as networking speeds go I see a similar result to Herbert zur Nedden, downloads are reasonable but writes to the NAS are very slow. This is with a wired connection to the Pi.

It’s not a similar result to Herbert. My downloads are not reasonable. Any network communication is extremely slow – to or from NAS, to or from the internet, to or from whatever.

But I’m going to try the hdmi_drive=2 solution for the sound. Thanks.

OK, the hdmi_drive=2 generates a beep at the splash screen indeed, but then there’s an eternal silence again.
Anyhow, the original – and far more important – problem (the awfully slow network speeds) isn’t solved yet. Anyone?

Just a shot in the dark try changing your RJ45 cable

@Paul
You can use Mixer to control the volume off different sound sources. With my Lapdock it works fine.
Network speed: You must have a other problem with your network speed. The cable is a good idea. The EtherUSB part for the SMSC chipset is the same for the Beagle xM, Panda and RPi. I have no bigger differnces and the slow speed is only in the upload direction. I know Thomas look/works at this. His SurfStick driver (ComCentre) has a higher upload speed with the three boards as my RPi via EtherUSB…

I’ve used the same cable that usually connects my Iyonix to the network, but the incredible low network speeds remain the same, either via LanMan98, or ShareFS, or the internet. Is it reasonable to assume that my RPi happens to be a bit mmm… iffy indeed?

@Frank,

About the flaky HDMI display: may I assume that you tried your original MDF as well?

I would consider trying a second Pi if you have one i have two and never had any problems with network transmissions or Display.
if you ping the router what do you get? if you have you tried Iyonix what do you get? bear in mind that the Iyonix has faster network speeds.
Is the router a 1Gb device or 10/100??
Have you tried power cycling the router??

@Paul,

Yup. Tried everything I could think of to improve things. Also tried several HDMI cables and wasted hours fiddling with settings everywhere, both on the Pi and on the monitor. The image remains ‘fuzzy’ with white shadows around any black items, such as characters.
I’m not sure whether the Pi or the monitor is responsible. I don’t have another monitor or another HDMI source to check.

where are you?? is there anyone near you to help with testing??

This is probably something you have tried – but might be useful to image up Raspbian or something and see if the slow network speed persists under an entirely different OS. This way you would at least figure out if it was a hardware issue or not.

Regarding lack of image quality via HDMI (like “fuzzy” images, white shadows around characters etc.): I have often encountered this when “picture improvement algorithms” are active. Sometimes, TVs think that a computer signal is actually a video signal and do all kind of strange things to “improve” the picture:

• scale it up slightly to hide a non-existing overscan area
• de-blocking of MPEG artifacts not there
• de-noising of a completely clear signal
• sharpening/softening of a perfectly sharp image
• colourspace conversion and gamma correction

So have a look at the settings of your TV and switch of everything that sounds like it could “improve” picture quality.

Been there, done that. Switched off or on anything that looked like it could mess with the picture quality. Literally spent hours doing that. I won’t say it didn’t make any difference, but definitely not enough to result in a satisfactory display.
Just tried the blasted thing on my neighbour’s monitor and it looked even worse than it did on mine before I started fiddling with it.

Edit: I put disable_overscan=1 in config.txt and now it almost looks like it should…

The critical thing is to end up with the resolution matching the native resolution. A good test picture would be one where adjacent pixels are different colours. Hence a 1920×1080 backdrop with a 2×2 pixel tile with four different colours repeated across the screen. Then you will see ‘beats’ if the resolutions don’t match.

The critical thing is to end up with the resolution matching the native resolution

Correct. It needs to be the same at all three stages! GPU, RISC OS & Screen

The monitor EDID output may either be wrong or the Pi misunderstanding it. To fix that set the screen resolution in config.txt
Then set RISC OS to output the native resolution.
And if the display is not filling the screen. Set the overscan correctly. For some, disable_overscan=1 may be all you need, for some displays left, right, top and bottom will need set manually.

Disabling overscan fixed most of the problems. A bit of re-tweaking some other settings and the display now looks well enough.
The monitor was obviously trying to compensate (and not quite succeeding – Steffen was close, however there was an overscan area) because the GPU was compressing the screen slightly. I finally found a setting that made the monitor show what the image looked like without scaling to fit the screen. The Raspberry Pi Forum had a thread about getting rid of the borders…

And now I’m staying out of this thread, before Paul accuses me of hijacking his topic… :-)

There seems to be two ways of specifying the resolution in config.txt.
framebuffer-width=1366
framebuffer_height=768
or
hdmi_group=2
hdmi_mode=39
is their any particular preferred way?
I get a very milky blurry image compared to the vga from my Iyonix on the same monitor. In fact the iyonix is so sharp it shows up different width vertical lines in the text depending on where it is placed. It makes me think that something isn’t syncing with the OS units or whatever.
Using a 1280 width evens things out, but is not square.
Thanks

Mmm… back to the slow network speeds on my RPi.

I’ve done some *ping tests and the figures on my RPi are roughly the same as those on my Iyonix (pinging the gateway was even considerably faster on the RPi!). Strangely, the router couldn’t be pinged by either computer, because the host seems to be down…? Anyway, the network is functioning, albeit extremely slow on the RPi side, at least when it comes to actually do something, other than typing *ping.

The suggestion that I should try another OS, preferably the Raspbian one, is something that I will certainly try, somewhere after the weekend.

The suggestion to try another RPi, however, encounters some reluctance. I know, they’re very cheap, but my experience until now doesn’t exactly inspire me to buy more of them.

By the way, I’m in The Netherlands, a country small enough to try to find nearby RISC OS users – although the forums and newsgroups have always been helpful enough.

Well, my RPi downloads from the internet at the same speed as the Iyonix and BB, all being limited by my broadband connection speed of, I think at the moment, 3300 Mbps stable rate. It has just downloaded a file from the ROOL site at a speed, as reported by Netsurf, of about 320 MB/s. On my LAN, it seems a bit slower than the BB, but not greatly.

Pings are probably not showing much, since the ping times will be in the 10s of ms, and are not representative of the data transfer rate itself.

Have you checked with eg TaskUsage that there isn’t anything consuming lots of cpu cycles, although in my case it is the networking (eg ShareFS) which consumes bandwidth and everything else almost stops while file transfer is in progress.

Does the RPi feel fully responsive during general use? Because everything goes through the usb stack it may be the actual ‘disc’ read/write speed that is impacting on network transfers.

The router should be pingable if the network is set up correctly – every one I have had responds to pings.

Thanks, Chris, for your thoughts.
My RPi feels very responsive during general use. It’s defenitely a fast little beast. I’ve downloaded quite some software from my backup memorystick to the RPi’s memory card and it all went very smooth. Nevertheless, I tried TaskUsage, but the only bandwith consuming application turned out to be Organizer (a tiny 1%). So, it’s really the network only that refuses to be responsive.

By the way, the router now appears to be pingable again; I don’t know what was going on a few hours ago, but I didn’t touch anything.

What do you get when you do
*ejinfo -verbose
in a task window. In particular what are the error counts after trying some transfers?

When I do *ejinfo, I get a lot of information, but only the Statistics summary says something about errors.
Here’s that summary:

Or do you want me to copy the complete output of *ejinfo?