Read speed of usb 2 versus 3.0

I am curious as to why the read speed is no better using 3.0 ports?

Quote:
Using USB 2.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 1.60252 s, 51.1 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.30256 s, 35.6 MB/s

Using USB 3.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 0.142398 s, 575 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.13294 s, 38.4 MB/s

Andy wrote:
I am curious as to why the read speed is no better using 3.0 ports?

Quote:
Using USB 2.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 1.60252 s, 51.1 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.30256 s, 35.6 MB/s

Using USB 3.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 0.142398 s, 575 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.13294 s, 38.4 MB/s

Please give details of the setup.

1) Actual storage device (SSD, NVMe, whatever)
2) Enclosure type and controller chip inside
3) Motherboard port type (USB3.1, USB3, Intel port, addon port)
4) UASP driver present
5) Windows OS with new cache feature
6) Whether Properties on the device, has the cache
enabled or disabled.

The OS can have two kinds of caches.

1) Traditional System Read Cache. Present since Win2K. Capable
of using all available system memory. Data evicted instantly
when memory is needed. This is the "free lunch" cache, first
spotted on SunOS/Solaris, then appearing on MacOSX and also
appearing on OSes like Win2K. On Win2K, it had the best behavior,
because more things that users were doing, benefited from
that cache. Later OSes tended to do more "uncached" operations
to bypass that thing (and for no particularly good reason either).

2) Newer cache behavior on Win8/Win10 perhaps.
Cache uses "real" memory. The memory is "charged" against
the system and actually registers in Task Manager.
The largest I've seen, is 5GB of cached write data,
causing the memory usage graph to rise by a corresponding
amount, and the hard drive light remained lit for around
50 seconds (at 100MB/sec) while that cache drained. This
is not the traditional cache as in (1), and cannot be
evicted in a hurry. And this is not a third-party feature.
It appears to be a feature in Windows, which may be limited
to using a certain fraction of memory as its maximum allowed
cache size. If the power goes off, you lose 5GB of data!

There is obviously something wrong with your 575MB/sec
write result. Now, it's up to you to explain it. USB3
has a theoretical max of 500MB/sec, caused by 5Gbit/sec
link rate, with 8B10B encoding reducing the actual
delivered user data rate to 500MB/sec. Now you're
going to need to give a lot more details.

On flash based storage, usually reads are faster than
writes. Until you get enough parallel channels connected
to the storage device controller chip, to swamp out
such details.

You should allow a lot more time between the write
test, and the read test that follows it. They
shouldn't be back-to-back. And, you should look
for evidence of type (2) above. Keep your
eyes peeled for cache behaviors.

Paul

Does hardware that supports XP actually support USB 3.0 or is it
merely taking advantage of some backward compatibility?

On Tue, 8 Mar 2016 08:00:32 -0800 (PST), Andy
wrote:

I am curious as to why the read speed is no better using 3.0 ports?

Quote:
Using USB 2.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 1.60252 s, 51.1 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.30256 s, 35.6 MB/s

Using USB 3.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 0.142398 s, 575 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.13294 s, 38.4 MB/s

--
Remove del for email

Andy wrote on 3/8/2016 9:00 AM:
I am curious as to why the read speed is no better using 3.0 ports?

Quote:
Using USB 2.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 1.60252 s, 51.1 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.30256 s, 35.6 MB/s

Using USB 3.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 0.142398 s, 575 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.13294 s, 38.4 MB/s

Perhaps you are testing with a USB 2.0 device?
--
Jeff Barnett

On Tuesday, March 8, 2016 at 11:10:13 AM UTC-6, Paul wrote:
Andy wrote:
I am curious as to why the read speed is no better using 3.0 ports?

Quote:
Using USB 2.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 1.60252 s, 51.1 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.30256 s, 35.6 MB/s

Using USB 3.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 0.142398 s, 575 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.13294 s, 38.4 MB/s

Please give details of the setup.

1) Actual storage device (SSD, NVMe, whatever)
2) Enclosure type and controller chip inside
3) Motherboard port type (USB3.1, USB3, Intel port, addon port)
4) UASP driver present
5) Windows OS with new cache feature
6) Whether Properties on the device, has the cache
enabled or disabled.

The OS can have two kinds of caches.

1) Traditional System Read Cache. Present since Win2K. Capable
of using all available system memory. Data evicted instantly
when memory is needed. This is the "free lunch" cache, first
spotted on SunOS/Solaris, then appearing on MacOSX and also
appearing on OSes like Win2K. On Win2K, it had the best behavior,
because more things that users were doing, benefited from
that cache. Later OSes tended to do more "uncached" operations
to bypass that thing (and for no particularly good reason either).

2) Newer cache behavior on Win8/Win10 perhaps.
Cache uses "real" memory. The memory is "charged" against
the system and actually registers in Task Manager.
The largest I've seen, is 5GB of cached write data,
causing the memory usage graph to rise by a corresponding
amount, and the hard drive light remained lit for around
50 seconds (at 100MB/sec) while that cache drained. This
is not the traditional cache as in (1), and cannot be
evicted in a hurry. And this is not a third-party feature.
It appears to be a feature in Windows, which may be limited
to using a certain fraction of memory as its maximum allowed
cache size. If the power goes off, you lose 5GB of data!

There is obviously something wrong with your 575MB/sec
write result. Now, it's up to you to explain it. USB3
has a theoretical max of 500MB/sec, caused by 5Gbit/sec
link rate, with 8B10B encoding reducing the actual
delivered user data rate to 500MB/sec. Now you're
going to need to give a lot more details.

On flash based storage, usually reads are faster than
writes. Until you get enough parallel channels connected
to the storage device controller chip, to swamp out
such details.

You should allow a lot more time between the write
test, and the read test that follows it. They
shouldn't be back-to-back. And, you should look
for evidence of type (2) above. Keep your
eyes peeled for cache behaviors.

Paul

I forgot to post that it was tested with Linux.

Actual device was a Toshiba external drive, 500 Gb.

This is the port device.

http://www.ebay.com/itm/USB-3-0-PCI-...AOSweW5VZoj O

Andy

Andy wrote:
On Tuesday, March 8, 2016 at 11:10:13 AM UTC-6, Paul wrote:
Andy wrote:
I am curious as to why the read speed is no better using 3.0 ports?

Quote:
Using USB 2.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 1.60252 s, 51.1 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.30256 s, 35.6 MB/s

Using USB 3.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 0.142398 s, 575 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.13294 s, 38.4 MB/s
Please give details of the setup.

1) Actual storage device (SSD, NVMe, whatever)
2) Enclosure type and controller chip inside
3) Motherboard port type (USB3.1, USB3, Intel port, addon port)
4) UASP driver present
5) Windows OS with new cache feature
6) Whether Properties on the device, has the cache
enabled or disabled.

The OS can have two kinds of caches.

1) Traditional System Read Cache. Present since Win2K. Capable
of using all available system memory. Data evicted instantly
when memory is needed. This is the "free lunch" cache, first
spotted on SunOS/Solaris, then appearing on MacOSX and also
appearing on OSes like Win2K. On Win2K, it had the best behavior,
because more things that users were doing, benefited from
that cache. Later OSes tended to do more "uncached" operations
to bypass that thing (and for no particularly good reason either).

2) Newer cache behavior on Win8/Win10 perhaps.
Cache uses "real" memory. The memory is "charged" against
the system and actually registers in Task Manager.
The largest I've seen, is 5GB of cached write data,
causing the memory usage graph to rise by a corresponding
amount, and the hard drive light remained lit for around
50 seconds (at 100MB/sec) while that cache drained. This
is not the traditional cache as in (1), and cannot be
evicted in a hurry. And this is not a third-party feature.
It appears to be a feature in Windows, which may be limited
to using a certain fraction of memory as its maximum allowed
cache size. If the power goes off, you lose 5GB of data!

There is obviously something wrong with your 575MB/sec
write result. Now, it's up to you to explain it. USB3
has a theoretical max of 500MB/sec, caused by 5Gbit/sec
link rate, with 8B10B encoding reducing the actual
delivered user data rate to 500MB/sec. Now you're
going to need to give a lot more details.

On flash based storage, usually reads are faster than
writes. Until you get enough parallel channels connected
to the storage device controller chip, to swamp out
such details.

You should allow a lot more time between the write
test, and the read test that follows it. They
shouldn't be back-to-back. And, you should look
for evidence of type (2) above. Keep your
eyes peeled for cache behaviors.

Paul

I forgot to post that it was tested with Linux.

Actual device was a Toshiba external drive, 500 Gb.

This is the port device.

http://www.ebay.com/itm/USB-3-0-PCI-...AOSweW5VZoj O

Andy

So the PCI Express slot is already the gating item.

PCI Express cannot even go at the link rate, due
to limited buffer space on the hub bus buffer. Only
a chipset USB3 port runs at the full rate. The
"add-on" designs are typically passing through
a x1 interface, and then you have to take the
buffer into account.

http://www.plxtech.com/files/pdf/tec...yload_Size.pdf

When a Southbridge USB3 logic block is connected
to the Northbridge, it uses at least the equivalent
of a x4 connection. Even if the connection runs at
50% efficiency, you get a x2 rate, and enough to run
at least a benchmark test at full speed. Whereas,
plugin chips tend to have x1 interfaces, and if the
bus efficiency isn't 100%, then the max USB3 rates
are limited. This is why add-on cards are inferior,
because the company making the chip didn't put an
x2 or x4 interface on it.

And so, a bandwidth report seeing more than is
possible, tells you there is a system file cache
present.

*******

From an administrator account, you could try

echo 3 /proc/sys/vm/drop_caches

where the possible values are

1 = pagecache
2 = dentries,inodes
3 = both

Doing that, should make no different to
Linux program running speed. But what it
can do, is flush the system file cache.

To be done just before a benchmark step.
To make the benchmark more honest.

Paul

On Thursday, March 10, 2016 at 2:35:47 PM UTC-6, Paul wrote:
Andy wrote:
On Tuesday, March 8, 2016 at 11:10:13 AM UTC-6, Paul wrote:
Andy wrote:
I am curious as to why the read speed is no better using 3.0 ports?

Quote:
Using USB 2.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 1.60252 s, 51.1 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.30256 s, 35.6 MB/s

Using USB 3.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 0.142398 s, 575 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.13294 s, 38.4 MB/s
Please give details of the setup.

1) Actual storage device (SSD, NVMe, whatever)
2) Enclosure type and controller chip inside
3) Motherboard port type (USB3.1, USB3, Intel port, addon port)
4) UASP driver present
5) Windows OS with new cache feature
6) Whether Properties on the device, has the cache
enabled or disabled.

The OS can have two kinds of caches.

1) Traditional System Read Cache. Present since Win2K. Capable
of using all available system memory. Data evicted instantly
when memory is needed. This is the "free lunch" cache, first
spotted on SunOS/Solaris, then appearing on MacOSX and also
appearing on OSes like Win2K. On Win2K, it had the best behavior,
because more things that users were doing, benefited from
that cache. Later OSes tended to do more "uncached" operations
to bypass that thing (and for no particularly good reason either).

2) Newer cache behavior on Win8/Win10 perhaps.
Cache uses "real" memory. The memory is "charged" against
the system and actually registers in Task Manager.
The largest I've seen, is 5GB of cached write data,
causing the memory usage graph to rise by a corresponding
amount, and the hard drive light remained lit for around
50 seconds (at 100MB/sec) while that cache drained. This
is not the traditional cache as in (1), and cannot be
evicted in a hurry. And this is not a third-party feature.
It appears to be a feature in Windows, which may be limited
to using a certain fraction of memory as its maximum allowed
cache size. If the power goes off, you lose 5GB of data!

There is obviously something wrong with your 575MB/sec
write result. Now, it's up to you to explain it. USB3
has a theoretical max of 500MB/sec, caused by 5Gbit/sec
link rate, with 8B10B encoding reducing the actual
delivered user data rate to 500MB/sec. Now you're
going to need to give a lot more details.

On flash based storage, usually reads are faster than
writes. Until you get enough parallel channels connected
to the storage device controller chip, to swamp out
such details.

You should allow a lot more time between the write
test, and the read test that follows it. They
shouldn't be back-to-back. And, you should look
for evidence of type (2) above. Keep your
eyes peeled for cache behaviors.

Paul

I forgot to post that it was tested with Linux.

Actual device was a Toshiba external drive, 500 Gb.

This is the port device.

http://www.ebay.com/itm/USB-3-0-PCI-...AOSweW5VZoj O

Andy

So the PCI Express slot is already the gating item.

PCI Express cannot even go at the link rate, due
to limited buffer space on the hub bus buffer. Only
a chipset USB3 port runs at the full rate. The
"add-on" designs are typically passing through
a x1 interface, and then you have to take the
buffer into account.

http://www.plxtech.com/files/pdf/tec...yload_Size.pdf

When a Southbridge USB3 logic block is connected
to the Northbridge, it uses at least the equivalent
of a x4 connection. Even if the connection runs at
50% efficiency, you get a x2 rate, and enough to run
at least a benchmark test at full speed. Whereas,
plugin chips tend to have x1 interfaces, and if the
bus efficiency isn't 100%, then the max USB3 rates
are limited. This is why add-on cards are inferior,
because the company making the chip didn't put an
x2 or x4 interface on it.

And so, a bandwidth report seeing more than is
possible, tells you there is a system file cache
present.

*******

From an administrator account, you could try

echo 3 /proc/sys/vm/drop_caches

where the possible values are

1 = pagecache
2 = dentries,inodes
3 = both

Doing that, should make no different to
Linux program running speed. But what it
can do, is flush the system file cache.

To be done just before a benchmark step.
To make the benchmark more honest.

Paul

Thanks for the good info.

Andy

On Thursday, March 10, 2016 at 2:35:47 PM UTC-6, Paul wrote:
Andy wrote:
On Tuesday, March 8, 2016 at 11:10:13 AM UTC-6, Paul wrote:
Andy wrote:
I am curious as to why the read speed is no better using 3.0 ports?

Quote:
Using USB 2.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 1.60252 s, 51.1 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.30256 s, 35.6 MB/s

Using USB 3.0

Write speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 0.142398 s, 575 MB/s
Read speed of Toshiba.
10000+0 records in
10000+0 records out
81920000 bytes (82 MB) copied, 2.13294 s, 38.4 MB/s
Please give details of the setup.

1) Actual storage device (SSD, NVMe, whatever)
2) Enclosure type and controller chip inside
3) Motherboard port type (USB3.1, USB3, Intel port, addon port)
4) UASP driver present
5) Windows OS with new cache feature
6) Whether Properties on the device, has the cache
enabled or disabled.

The OS can have two kinds of caches.

1) Traditional System Read Cache. Present since Win2K. Capable
of using all available system memory. Data evicted instantly
when memory is needed. This is the "free lunch" cache, first
spotted on SunOS/Solaris, then appearing on MacOSX and also
appearing on OSes like Win2K. On Win2K, it had the best behavior,
because more things that users were doing, benefited from
that cache. Later OSes tended to do more "uncached" operations
to bypass that thing (and for no particularly good reason either).

2) Newer cache behavior on Win8/Win10 perhaps.
Cache uses "real" memory. The memory is "charged" against
the system and actually registers in Task Manager.
The largest I've seen, is 5GB of cached write data,
causing the memory usage graph to rise by a corresponding
amount, and the hard drive light remained lit for around
50 seconds (at 100MB/sec) while that cache drained. This
is not the traditional cache as in (1), and cannot be
evicted in a hurry. And this is not a third-party feature.
It appears to be a feature in Windows, which may be limited
to using a certain fraction of memory as its maximum allowed
cache size. If the power goes off, you lose 5GB of data!

There is obviously something wrong with your 575MB/sec
write result. Now, it's up to you to explain it. USB3
has a theoretical max of 500MB/sec, caused by 5Gbit/sec
link rate, with 8B10B encoding reducing the actual
delivered user data rate to 500MB/sec. Now you're
going to need to give a lot more details.

On flash based storage, usually reads are faster than
writes. Until you get enough parallel channels connected
to the storage device controller chip, to swamp out
such details.

You should allow a lot more time between the write
test, and the read test that follows it. They
shouldn't be back-to-back. And, you should look
for evidence of type (2) above. Keep your
eyes peeled for cache behaviors.

Paul

I forgot to post that it was tested with Linux.

Actual device was a Toshiba external drive, 500 Gb.

This is the port device.

http://www.ebay.com/itm/USB-3-0-PCI-...AOSweW5VZoj O

Andy

So the PCI Express slot is already the gating item.

PCI Express cannot even go at the link rate, due
to limited buffer space on the hub bus buffer. Only
a chipset USB3 port runs at the full rate. The
"add-on" designs are typically passing through
a x1 interface, and then you have to take the
buffer into account.

http://www.plxtech.com/files/pdf/tec...yload_Size.pdf

When a Southbridge USB3 logic block is connected
to the Northbridge, it uses at least the equivalent
of a x4 connection. Even if the connection runs at
50% efficiency, you get a x2 rate, and enough to run
at least a benchmark test at full speed. Whereas,
plugin chips tend to have x1 interfaces, and if the
bus efficiency isn't 100%, then the max USB3 rates
are limited. This is why add-on cards are inferior,
because the company making the chip didn't put an
x2 or x4 interface on it.

And so, a bandwidth report seeing more than is
possible, tells you there is a system file cache
present.

*******

From an administrator account, you could try

echo 3 /proc/sys/vm/drop_caches

where the possible values are

1 = pagecache
2 = dentries,inodes
3 = both

Doing that, should make no different to
Linux program running speed. But what it
can do, is flush the system file cache.

To be done just before a benchmark step.
To make the benchmark more honest.

Paul

Under XP and using HD Tune to benchmark,

the speed is about 3.5X that of the usb 2.0 ports

Not as fast as a built-in, but I am happy with it.

Andy