Modules and speed

I’m just testing my networking code in “user-land” at the moment, and the maximum download speed I can get on my PandaBoard ES is around 6MB/sec. ( 49376Kbit/sec )
It’s slightly depressing I can’t get nearer to 100Mbit, that speed is more or less 50% of what the theoreticall speed is.
Would (as I’m planning) having the read / write section in a module mean I have a decent chance of pushing it towards an ideal target of 75-80% ?
I’ve commonly seen a PC (linux) transfer data via scp on a 100Mbit connection at just a tad over 11MB/sec.
It’s slightly depressing my internet can push at up to 15MB/sec (in the rare time a server has that kind of bandwidth allowed or avaliable per connection) but my PandaBoard can’t even manage above 6.

I’m not planning on delving into modules for at least a month or two (Ramadan is coming, not a good time to bend my mind), but if I could get any suggestions etc.
e.g. do I need to put my module into high priority mode or something.
There’s a whole section on modules I need to read, probably on a daily basis for a month until I get the hang of how they work.
I notice that if I have music running via Digital CD it plays an mp3 clearly, without jumps with no affect on the download speed, so there is clearly more “umph” avaliable.
FYI at the moment I’m using select with zero timeouts and running it in a tight loop, printing anything out affects the speed – which I would expect.

Or would it be possible to increase the “internal” buffer for networking above 17kbtyes within RISC OS? Not sure what it is, but there does seem to be a hard limit of around 17376 bytes that can be read and I think it’s that what is causing the throttling in TCP, the other value that pops up a lot is 1448bytes, not sure why….it’s rather odd to be honest!
Does that ring a bell with anyone?

the other value that pops up a lot is 1448bytes, not sure why….it’s rather odd to be honest!
Does that ring a bell with anyone?

link MTU – header elements => maximum data transmission in one packet. Typical switch link MTU is 1500

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=%2Fcom.ibm.itsm.perf.doc%2Ft_network_aix_srv_clnt_mtu_mss.html

http://www.tegola.org.uk/howto/pmtud.html

loads of other articles around.

Ah, of course! That should have clicked to be honest, the number did seem familiar and 17376 is 12 blocks (of MTU).
AIX, VIO/GPFS/HACMP etc. urrghh, reminds me of an old sig. “Whip me, beat me, make me maintain AIX” – I couldn’t agree more!
So the last question is would it be possible to increase this buffer size (double it) on RISC OS, as it seems to be the same for a RISC PC as for a pandaboard and a raspberry Pi. So I’m assuming this is an OS buffer rather than a hardware one? But that’s a rather random assumption, as it’s entirely possible 17k is the standard buffer in most/all NIC’s.
If/When we get a gigabit interface for newer hardware, it’s going to be nearly impossible to utilise the NIC to it’s full potential (or by my calculations less than 5% of a gigabit NIC – I know at standard MTU it doesn’t scale like that)
Or is the bottleneck going to be somewhere else, like in the tcp/ip handling?

I noticed changes that seemed interesting to the USB driver, so thought I’d benchmark the networking on the pandaboard again.
It doesn’t seem to be any faster on peak speeds, but there don’t seem to be any peak speeds now. Before it was fluctuating up and down.
It would kind of make sense given the changes to the USB driver.
At least that seems to have helped the “throttling” effect on the USB which is great!
It seems fairly steady now at around 5.9MB/sec with only minor fluctuations.
Nice bit of work and “bug hunting” :-D Cheers