Hi everybody,

We recently bought a few trimslice pros and were surprised to find the SSD performance to be quite poor using the supplied kernel/OS. Has anybody else used the trimslice pro and had a similar experience, or perhaps more importantly, achieved good IO performance?

Raw reads with dd on /dev/sda top out at about 10MB/s. The P4 SSD has a theoretical sustained read performance of 160MB/s so it probably is not the disk. Likewise, USB 2.0 is roughly 60MB/s, so that probably isn't it either. I've not successfully tracked down the performance characteristics of the GL830 usb-to-sata chip, but maybe that's the issue. Anyone?

The 10 MB/s figure matches what I saw on my Trimslice Pro when measuring with bonnie++. I don't know what's causing it.

What's the read speed on an external usb stick / enclosure? The GL830 does seem like a reasonable place to have the bottleneck. I only found this, but I would imagine that the chip is in a lot of external hd enclosures:

http://translate.google.com/translate?h ... rmd%3Divns

That's a fine question- I'll pick up an external enclosure and will report back in a couple days.

By the way, the thread started because of the OMAP-based Pandaboard also seems relevant. Evidently using the perl scripts contained within do boost SSD performance up to 3x, meaning this is probably some arm-specific kernel interrupt handler bug:

https://bugs.launchpad.net/linux-linaro/+bug/709245

A quick test of a USB enclosure with a 250GB Seagate drive gets 2.1MB/s raw reads with dd. Awful. Ping flooding localhost while doing the dd results in 22 MB/s raw reads. It appears this is certainly a software bug, not an issue with the USB-SATA hardware.

This is similar to what we got with our initial testing of the USB-to-SATA. We'll be looking into the storage performance optimization once we have the basic stuff stabilized.

The block diagram shows that in TrimSlice the SSD sits behind USB. The USB2 raw bandwidth is 480Mb/s = 60MB/s. Typically the overhead is 50% on USB. So 30MB/s is roughly the best we can expect from the SSD. Is it correct?

Why was SSD not put on the PCIe bridge? That would cleanly remove the speed cap on SSD.

I don't think 50% overhead is really an appropriate expectation. You should get reasonably close to 60MB/s if everything is working correctly. Even so, 30MB/s would be a welcome measurement as we are routinely seeing just 10% of that number.

Trust us that we tried hard to implement PCIe to SATA. As far as we can tell it is not possible with Tegra 2 and available PCIe to SATA controllers.

Unfortunately we cannot discuss these electronics design considerations in more detail.