hey, what's your average data transfer rate when transferring files from pc to your mybook via ftp? despite of gbit interface in my pc and the mybook, the data transfer rate won't rise above 43mbit/s. what are your experiences?
Hi, yeah, I'm suffering exactly the same problem! I think I may well send this back if 43Mbit/s is all I can get out of it - nothing like the advertised 1Gbit/s!! and it makes larger transfers pretty painful! What was the point in giving it Gigabit ethernet hardware when it's no faster than 100Mbit!? P.S. If anyone's got their MyBookWorld running faster than this, I'd really like to know!
Just to clarify, this is using Samba on Win XP SP2 to access an as of yet completely Stock My Book World 750GB. And I'm getting an identical transfer rate to that mentioned above (around 40Mbits/s). The cabling setup was just the provided ethernet cable between my Gbit PC Lan Card and the MyBookWE (utilizing it's auto-crossover). Any ideas anyone? Also, oddly, the green/orange connectivity/activity LEDs on the ethernet socket of my MyBookWE don't light up - is that normal? It's pretty irritating not to have that diagnostic feature.
An ethernet interface consists of a MAC and a PHY. Whilst the PHY is gigabit capable, is it possible the MAC is only 100 Mbit? The link from Martin Hinners site to Oxford Semiconductors website shows the MAC as 100 Mbit - check it out:-
Either that or the processor is underpowered.
I think the more accurate statement is that the oxsemi ASIC is the bottleneck. While nobody seems to have the datasheet for this little badboy, it was very obviously designed with the "plug n' sell" mentality (simplicity) rather than lean speed. It seems like most of these boutique SoC's have been designed that way.
I'd imagine it's a combination of the ARM's cache, internal buses, poor buffers, etc. I don't think there's really a great solution for this, I think we just have to live with the fact that throughput on this box is what it is.
Easiest way to find out, what part of the system is bottleneck is to try it separately. I tried copying from usb disk attached to mbwe to internal disk (so no LAN, no samba, no ftp, only LINUX) and speed is the same. Processor is probably bottleneck. Maybe bad drivers ( I thing 3-6MB/s is low for 200MHz processor), bad optimalization… who knows….probably WD does! ;-)
Wow, i tried nbench and here are the results:
BYTEmark* Native Mode Benchmark ver. 2 (10/95)
Index-split by Andrew D. Balsa (11/97)
Linux/Unix* port by Uwe F. Mayer (12/96,11/97)
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
NUMERIC SORT : 66.747 : 1.71 : 0.56
STRING SORT : 1.1933 : 0.53 : 0.08
BITFIELD : 1.3768e+07 : 2.36 : 0.49
FP EMULATION : 3.8491 : 1.85 : 0.43
FOURIER : 53.437 : 0.06 : 0.03
ASSIGNMENT : 0.52669 : 2.00 : 0.52
IDEA : 153.43 : 2.35 : 0.70
HUFFMAN : 76.22 : 2.11 : 0.67
NEURAL NET : 0.058955 : 0.09 : 0.04
LU DECOMPOSITION : 1.8389 : 0.10 : 0.07
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 1.691
FLOATING-POINT INDEX: 0.082
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
L2 Cache :
OS : Linux 18.104.22.168
C compiler : gcc version 3.4.2
libc : ld-uClibc-0.9.28.so
MEMORY INDEX : 0.277
INTEGER INDEX : 0.579
FLOATING-POINT INDEX: 0.045
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 22.214.171.124, libc-5.4.38
As you can see, floating point operations are the WEAKEST point on ARM CPU. Do you think, that its also the cause of slow transfer speed? I think, that other results are not so bad :-) (Integer 1,691*P90 :-) ). Maybe kernel and drivers are badly compiled. What do you think? Im not linux master :-).
Damn! mine is a bit worse , tho i had some apps running … FW 2.00.15
BYTEmark* Native Mode Benchmark ver. 2 (10/95) Index-split by Andrew D. Balsa (11/97) Linux/Unix* port by Uwe F. Mayer (12/96,11/97) TEST : Iterations/sec. : Old Index : New Index : : Pentium 90* : AMD K6/233* --------------------:------------------:-------------:------------ NUMERIC SORT : 66.813 : 1.71 : 0.56 STRING SORT : 1.1895 : 0.53 : 0.08 BITFIELD : 1.3752e+07 : 2.36 : 0.49 FP EMULATION : 3.8285 : 1.84 : 0.42 FOURIER : 49.503 : 0.06 : 0.03 ASSIGNMENT : 0.52521 : 2.00 : 0.52 IDEA : 153.79 : 2.35 : 0.70 HUFFMAN : 73.965 : 2.05 : 0.65 NEURAL NET : 0.057971 : 0.09 : 0.04 LU DECOMPOSITION : 1.8315 : 0.09 : 0.07 ==========================ORIGINAL BYTEMARK RESULTS========================== INTEGER INDEX : 1.682 FLOATING-POINT INDEX: 0.079 Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0 ==============================LINUX DATA BELOW=============================== CPU : L2 Cache : OS : Linux 126.96.36.199 C compiler : /home/slug/optware/gumstix1151/toolchain/gumstix-buildroot/build_arm_nofpu/staging_dir/bin/arm-linux-uclibc-gcc libc : static MEMORY INDEX : 0.276 INTEGER INDEX : 0.575 FLOATING-POINT INDEX: 0.044 Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 188.8.131.52, libc-5.4.38 * Trademarks are property of their respective holder.
I have firmware 1.xxx and complete cool&quiet modification (killed almost anything), but results are only slightly different :-).
What about this:
hdparm -t /dev/sda
Timing buffered disk reads: 48 MB in 3.04 seconds = 15.79 MB/sec
hdparm -T /dev/sda
Timing cached reads: 136 MB in 2.01 seconds = 67.81 MB/sec
I think first result is rather slow.
But i dont get this. If you look in oxsemi datasheet brief, it seems, that mbwe uses superchip with great pack of modern technologies :-).
I also noticed:
IO_support = 0 (default 16-bit)
Would it be dangerous to turn on 32 setting?
Read article about slow self-made linux-router-pc:
PII Celeron 333MHz, 128MB DIMM
ide1 - hdc1 Seagate Barracuda 7 120GB, udma2, filesystem Ext3
eth0: Realtek 8139, fullduplex 100Mbit
wlan0-2: Zcom626 - hostap master
Timing buffer-cache reads: 128 MB in 3.20 seconds = 40.00 MB/sec
Timing buffered disk reads: 64 MB in 4.38 seconds = 14.61 MB/sec
Problem is also with cpu usage!
So our mbwe isnt that big shit :-)
I tried another benchmark with interesting results:
---------------------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 4820 90.6 13052 70.0 6291 39.1 5053 94.8 21785 82.5 152.9 9.1
As you can see, if you write each byte separately, write speed is 4,8 MB/s, but if you write by blocks, speed is 13 MB/s and CPU utilization will be also lower. The same for read speed and CPU utilization.
Maybe kernel is not well configured for disk access. Any ideas?