Thank you for your answer, it's not my field of expertise and I sure need a hand.
The disk queue length seems to be a good indicator of the problem, unfortunatly I'm not familiar with the related settings...
Anyway I tried monitoring the various counters available through esxtop, from what I gather the queue lengths seemed OK.
(the software hba's is not configurable and reported as AQLEN=1024, the vmkernel's was setup as dynamicallay throttled and reported as DQLEN=32 or 128 depending on load; I tried setting it up to fixed/64 but it didn't change the results)
But what seemed wrong is that the number of active commands in the queue was always ACTV=0, 1 or 2.
In the VM (windows XP) perfmon also reportd a queue depth always <= 1 when copying files.
Heres an example, esxtop in "u" mode, with a windows VM copying a file (worst case scenario, on avg ACTV is 0 or 1):
DEVICE PATH/WORLD/PARTITION DQLEN WQLEN ACTV QUED %USD LOAD CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s DAVG/cmd KAVG/cmd GAVG/cmd QAVG/cmd
naa.60a98000503xx - 128 - 2 0 1 0.02 638.96 630.38 8.58 19.21 0.39 1.51 0.01 1.51 0.00
The same thing, but during an iometer run with "# of Outstanding IO = 8":
DEVICE PATH/WORLD/PARTITION DQLEN WQLEN ACTV QUED %USD LOAD CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s DAVG/cmd KAVG/cmd GAVG/cmd QAVG/cmd
naa.60a98000503xx - 128 - 8 0 6 0.06 3750.80 3705.50 45.30 112.86 0.45 2.03 0.00 2.04 0.00
So now I'm wondering why the queue stays empty and the transfer rate so low...testing on a physical windows showed the queued length going up to 32 as soon as a file copy is started...
PS: also thanks for the NetApp link, It's so obvious I never thought about it...
