100Mbit?  So 10MB/sec?  That is pretty low.

I would assume the backup job is probably single threaded vs. the IOMETER test, and may not be as sequential as you think.

Do you have any STP data from the backup job?  

Thanks for your response! Yeah... 10-15Mb/s

I simulated single thread read with IOMeter and I get same 10-15Mb/s

Sorry, but what you mean by STP data?

What IO size are you using with the IOMETER test?

STP is performance data collected from the Symmetrix.  It can be collected with ECC, or with Solutions Enabler using the storstp daemon.

I'm test with different IO size - from 4Kb to 4Mb (best throughput was on bigest size)

Yes, I look at perfomance in ECC, and throughput of tested device is very low and only front end port felt the difference between my test and normal work. I guess it cahe effect... hmm... maybe I should try to tune QoS... but whole symmetrix load is not so huge (max ~120Mb/s throughput and 13k IOPS - it is for 200 15K rpm and my problem 30 SATA disks).

And I still don't get it... I tested cache effect (test with IOMeter device with 10Gb space) and I get throughput 600Mb/s for huge IO size and 37K IOPS for small IO size (my colleague get 50K IOPS from cache). Any way if it cache effect it must work better...

Perhaps more important is the size of files that reside on this volume - the average size of 1MB minimum 1Kb maximum 5Mb?

I would be interested in the results of a pure IOMETER sequential read, single thread with say 128k IOs.  Typically the Symmetrix doesn't get improved throughput with IO sizes larger than that, and could actually go down above 256k.

The cached IO rate is going to depend on the number of FA slices you are using.  Each one has a dedicated CPU which will gate the maximum rate.

sorry to say, but i have same problem,

also did same test on flash drive but same result.

nothing wrong on switch.

128K 100% sequential read, single thread: 45Mb/s and 360 IOPS

64K 100% sequential read, single thread: 50Mb/s and 760 IOPS

32K 100% sequential read, single thread: 65Mb/s and 2000 IOPS

16K 100% sequential read, single thread: 45Mb/s and 2800 IOPS

Boom, do you have the perfomance analyzer?

That's better than 10, but still not great.  Is that with one thread or more?

One thread. Huge block size is better. If I set block size less than 16K the perfomance is significantly degrades.

Yes, I would expect that any IO size below 64k would reduce throughput.  The sweet spot should be 128k or 256k IOs.  Larger than 256k could reduce performance.

What code are you running on your VMAX?

How large are your TDAT devices?  How many SATA drives?  I'd like to know how many splits per disk you have.  I think having only one split per disk in the pool is going to give the best performance.  The allocation in a thin pool is round robin, so with more than one split per disk, sequential read will do many seeks over the disk.  This isn't much of an issue for fiber drives, but SATA drives don't as well with random seeks.

Current Enginuity 5874.207.166 (11-th of May EMC support will upgrade to lastest version)

56 DATA Devices each dev has 234795Mb/250448Cyl capacity, 2-way mir on 28 SATA drives (1Tb each one) and 4 hypers per disk

3 concatenated meta consist of 3 TDEV's each one 234345Mb/250000Cyl

As far as I know 5874.210 is the EMC target code now, and there is a fix in this release that may help the large block reads.  See emc217750

Also if this doesn't improve the performance much, you might want to try a pool configured with only one hyper per physical disk.

Also if this doesn't improve the performance much, you might want to try a pool configured with only one hyper per physical disk.

but then what do you do with the rest of the capacity on the drive ?

I think create second pool