I'm now doing quite a lot of compilation on my Chromebook and my Trim Slice. It's OK, provided that two processes don't try to hit the disk at the same time, at which point everything grinds to a halt.
I'm using cheap SanDisk cards in both (not exactly sure of the model, but they're the cheapest branded ones).
Question is, would I be better to:
- Use cards such as the "SanDisk Extreme Pro" http://www.amazon.co.uk/gp/product/B005LFT3QG (Does it make a difference, or is it designed to separate me from my hard-earned money?)
- Try again with using network drive, eg. iSCSI? NFS? NBD? gluster ..? (Note: the Chromebook kernel doesn't support NFS)
- Is there a good performing network device which is less horrible to configure than iSCSI?
Rich.
On Thu, Aug 01, 2013 at 03:42:53PM +0100, Richard W.M. Jones wrote:
I'm now doing quite a lot of compilation on my Chromebook and my Trim Slice. It's OK, provided that two processes don't try to hit the disk at the same time, at which point everything grinds to a halt.
I'm using cheap SanDisk cards in both (not exactly sure of the model, but they're the cheapest branded ones).
Question is, would I be better to:
Use cards such as the "SanDisk Extreme Pro" http://www.amazon.co.uk/gp/product/B005LFT3QG (Does it make a difference, or is it designed to separate me from my hard-earned money?)
Try again with using network drive, eg. iSCSI? NFS? NBD? gluster ..? (Note: the Chromebook kernel doesn't support NFS)
Is there a good performing network device which is less horrible to configure than iSCSI?
Or another alternative might be:
- External USB hard disk of some sort.
Rich.
On Thu, Aug 1, 2013 at 3:42 PM, Richard W.M. Jones rjones@redhat.com wrote:
I'm now doing quite a lot of compilation on my Chromebook and my Trim Slice. It's OK, provided that two processes don't try to hit the disk at the same time, at which point everything grinds to a halt.
I'm using cheap SanDisk cards in both (not exactly sure of the model, but they're the cheapest branded ones).
Question is, would I be better to:
- Use cards such as the "SanDisk Extreme Pro" http://www.amazon.co.uk/gp/product/B005LFT3QG (Does it make a difference, or is it designed to separate me from my hard-earned money?)
I tend to go for the Samsung ones as I've found they're actually eMMC in a SD shell (via a 3rd party) and they tend to last better over all
- Try again with using network drive, eg. iSCSI? NFS? NBD? gluster ..? (Note: the Chromebook kernel doesn't support NFS)
I use NFSv4 over the pcie GiG eth on the Trimslice over to my NAS which is 5x 2Tb so it's much faster and more stable and not prone to random SD corruption.
- Is there a good performing network device which is less horrible to configure than iSCSI?
iSCSI is quite straight forward a few commands on the client and server side overall. What about a SSD or HDD connected to the chromebooks USB-3 port?
Peter
On 08/01/2013 03:42 PM, Richard W.M. Jones wrote:
I'm now doing quite a lot of compilation on my Chromebook and my Trim Slice. It's OK, provided that two processes don't try to hit the disk at the same time, at which point everything grinds to a halt.
I'm using cheap SanDisk cards in both (not exactly sure of the model, but they're the cheapest branded ones).
Question is, would I be better to:
- Use cards such as the "SanDisk Extreme Pro" http://www.amazon.co.uk/gp/product/B005LFT3QG (Does it make a difference, or is it designed to separate me from my hard-earned money?)
Yes. They are one of few SD/CF/USB flash devices that offer performance comparable to mechanical disks on random writes. See here: http://www.altechnative.net/2012/01/25/flash-module-benchmark-collection-sd-... (link at the bottom of the article, scroll down to the 2nd table for random read/write performance).
Another thing you can do is use nilfs2 for your compile FS-es to make all the writes always linear. This effectively negates the poor random-write performance, at the expense of garbage collection churn. I used this approach for a while on my AC100s, but eventually I just got a SuperTalent RC8 USB stick which is a full fat SATA SSD with a USB-SATA adapter in front of it, in USB stick form factor. Very expensive, but extremely performant. Performance figures for it are in the list linked above. Also, you may be interested to see this:
http://www.altechnative.net/2012/02/07/morebetter-internal-storage-on-the-to...
- Try again with using network drive, eg. iSCSI? NFS? NBD? gluster ..? (Note: the Chromebook kernel doesn't support NFS)
Or use one of the SSDs with both SATA and USB interfaces, such as some of the Integral Z series models. That gives you a cost effective SSD you can run off of USB.
I used various network block device and file system options on my build far, which good success, it should work fine over wired ethernet.
- Is there a good performing network device which is less horrible to configure than iSCSI?
iSCSI is not that bad, you need about 5 config lines on the server, and bout 2 lines on the command line on the client. NBD might be a tiny bit simpler.
Gordan
On 1 August 2013 08:42, Richard W.M. Jones rjones@redhat.com wrote:
I'm now doing quite a lot of compilation on my Chromebook and my Trim Slice. It's OK, provided that two processes don't try to hit the disk at the same time, at which point everything grinds to a halt.
I know that several ARMS talk to disks via the USB chain versus a dedicated SATA like connection. This causes all kinds of issues when 2 things talk down the bus to the disk drive (just like if it is a spinning disk). The same with network and other peripheals. It will depend on how the hardware sees it and talks to it to know if it will work well or not. [My kingdom for an ARM PCI bus :)]
On Thu, Aug 1, 2013 at 4:48 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 1 August 2013 08:42, Richard W.M. Jones rjones@redhat.com wrote:
I'm now doing quite a lot of compilation on my Chromebook and my Trim Slice. It's OK, provided that two processes don't try to hit the disk at the same time, at which point everything grinds to a halt.
I know that several ARMS talk to disks via the USB chain versus a dedicated SATA like connection. This causes all kinds of issues when 2 things talk down the bus to the disk drive (just like if it is a spinning disk). The same with network and other peripheals. It will depend on how the hardware sees it and talks to it to know if it will work well or not. [My kingdom for an ARM PCI bus :)]
Send me your kingdom... there's now a number of ARM devices with PCI-e buses, or SATA/NICs plugged directly into the SoC so not hanging off crappy USB/SPI/GPIO/i2c buses :-D
Peter
On 1 August 2013 09:53, Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Aug 1, 2013 at 4:48 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 1 August 2013 08:42, Richard W.M. Jones rjones@redhat.com wrote:
I'm now doing quite a lot of compilation on my Chromebook and my Trim Slice. It's OK, provided that two processes don't try to hit the disk at the same time, at which point everything grinds to a halt.
I know that several ARMS talk to disks via the USB chain versus a dedicated SATA like connection. This causes all kinds of issues when 2 things talk down the bus to the disk drive (just like if it is a spinning disk). The same with network and other peripheals. It will depend on how the hardware sees it and talks to it to know if it will work well or not. [My kingdom for an ARM PCI bus :)]
Send me your kingdom... there's now a number of ARM devices with PCI-e buses, or SATA/NICs plugged directly into the SoC so not hanging off crappy USB/SPI/GPIO/i2c buses :-D
But are the devices Richard has those?
Peter
On Thu, Aug 01, 2013 at 09:59:47AM -0600, Stephen John Smoogen wrote:
On 1 August 2013 09:53, Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Aug 1, 2013 at 4:48 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 1 August 2013 08:42, Richard W.M. Jones rjones@redhat.com wrote:
I'm now doing quite a lot of compilation on my Chromebook and my Trim Slice. It's OK, provided that two processes don't try to hit the disk at the same time, at which point everything grinds to a halt.
I know that several ARMS talk to disks via the USB chain versus a dedicated SATA like connection. This causes all kinds of issues when 2 things talk down the bus to the disk drive (just like if it is a spinning disk). The same with network and other peripheals. It will depend on how the hardware sees it and talks to it to know if it will work well or not. [My kingdom for an ARM PCI bus :)]
Send me your kingdom... there's now a number of ARM devices with PCI-e buses, or SATA/NICs plugged directly into the SoC so not hanging off crappy USB/SPI/GPIO/i2c buses :-D
But are the devices Richard has those?
The Trim Slice *has* a PCI bus (apparently unusual for ARM). However mine doesn't have SATA because it's the cheaper model, and I'm not clear how the micro SD and SD card ports are routed.
Rich.
On 08/01/2013 12:41 PM, Richard W.M. Jones wrote:
On Thu, Aug 01, 2013 at 09:59:47AM -0600, Stephen John Smoogen wrote:
On 1 August 2013 09:53, Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Aug 1, 2013 at 4:48 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 1 August 2013 08:42, Richard W.M. Jones rjones@redhat.com wrote: I know that several ARMS talk to disks via the USB chain versus a dedicated SATA like connection. This causes all kinds of issues when 2 things talk down the bus to the disk drive (just like if it is a spinning disk). The same with network and other peripheals. It will depend on how the hardware sees it and talks to it to know if it will work well or not. [My kingdom for an ARM PCI bus :)]
Send me your kingdom... there's now a number of ARM devices with PCI-e buses, or SATA/NICs plugged directly into the SoC so not hanging off crappy USB/SPI/GPIO/i2c buses :-D
But are the devices Richard has those?
The Trim Slice *has* a PCI bus (apparently unusual for ARM). However mine doesn't have SATA because it's the cheaper model, and I'm not clear how the micro SD and SD card ports are routed.
So, the SATA models of the Trim Slice use a USB-SATA bridge, so your still in that boat.
On the subject of devices that do have native SATA support.
1) http://cubieboard.org/ 2) http://utilite-computer.com/ (The Trim Slice successor, although its SATA is on an mSATA interface.)
Send me your kingdom... there's now a number of ARM devices with PCI-e buses, or SATA/NICs plugged directly into the SoC so not hanging off crappy USB/SPI/GPIO/i2c buses :-D
But are the devices Richard has those?
The Trim Slice *has* a PCI bus (apparently unusual for ARM). However mine doesn't have SATA because it's the cheaper model, and I'm not clear how the micro SD and SD card ports are routed.
The Gig ethernet is attached to the PCI-e slot on the trimslice. The SSD on the expensive model is attached via USB so is still pretty average IMO.
You need to remember that tegra2 is now basically 2 generations old :-)
Peter
On 1 August 2013 11:38, Peter Robinson pbrobinson@gmail.com wrote:
Send me your kingdom... there's now a number of ARM devices with PCI-e buses, or SATA/NICs plugged directly into the SoC so not hanging off crappy USB/SPI/GPIO/i2c buses :-D
But are the devices Richard has those?
The Trim Slice *has* a PCI bus (apparently unusual for ARM). However mine doesn't have SATA because it's the cheaper model, and I'm not clear how the micro SD and SD card ports are routed.
The Gig ethernet is attached to the PCI-e slot on the trimslice. The SSD on the expensive model is attached via USB so is still pretty average IMO.
You need to remember that tegra2 is now basically 2 generations old :-)
Peter
But I only got this thing last year... sigh.
On 08/01/2013 05:41 PM, Richard W.M. Jones wrote:
On Thu, Aug 01, 2013 at 09:59:47AM -0600, Stephen John Smoogen wrote:
On 1 August 2013 09:53, Peter Robinson pbrobinson@gmail.com wrote:
On Thu, Aug 1, 2013 at 4:48 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 1 August 2013 08:42, Richard W.M. Jones rjones@redhat.com wrote:
I'm now doing quite a lot of compilation on my Chromebook and my Trim Slice. It's OK, provided that two processes don't try to hit the disk at the same time, at which point everything grinds to a halt.
I know that several ARMS talk to disks via the USB chain versus a dedicated SATA like connection. This causes all kinds of issues when 2 things talk down the bus to the disk drive (just like if it is a spinning disk). The same with network and other peripheals. It will depend on how the hardware sees it and talks to it to know if it will work well or not. [My kingdom for an ARM PCI bus :)]
Send me your kingdom... there's now a number of ARM devices with PCI-e buses, or SATA/NICs plugged directly into the SoC so not hanging off crappy USB/SPI/GPIO/i2c buses :-D
But are the devices Richard has those?
The Trim Slice *has* a PCI bus (apparently unusual for ARM). However mine doesn't have SATA because it's the cheaper model, and I'm not clear how the micro SD and SD card ports are routed.
Indeed, Tegra2 supposedly has PCIe, but it's so well engineered that nobody to date (to my knowledge) has actually managed to get it working on a commercially available device. CompuLab supposedly tried to get PCIe SATA working, but gave up in the end and went with USB SATA instead.
Gordan
The fastest disk I/O on trimslice, based on my testing, is via iSCSI over the ethernet port. It can do gigE (125MByte/sec) where usb/sata on arm seems to be limited to 27 MByte/sec or so (37 MByte/sec on intel i7).
On 08/02/2013 05:38 AM, DJ Delorie wrote:
The fastest disk I/O on trimslice, based on my testing, is via iSCSI over the ethernet port. It can do gigE (125MByte/sec) where usb/sata on arm seems to be limited to 27 MByte/sec or so (37 MByte/sec on intel i7).
Are you really MB/s rather than IOPS bound?
Gordan
The fastest disk I/O on trimslice, based on my testing, is via iSCSI over the ethernet port. It can do gigE (125MByte/sec) where usb/sata on arm seems to be limited to 27 MByte/sec or so (37 MByte/sec on intel i7).
Are you really MB/s rather than IOPS bound?
37 MBytes/sec is close to the USB480 limit, considering overhead, I think. I don't know why the arm devices seem to be limited to 27 MBytes/sec on USB disks, but those were the numbers I saw.
On 2 Aug 2013 18:09, "DJ Delorie" dj@redhat.com wrote:
The fastest disk I/O on trimslice, based on my testing, is via iSCSI over the ethernet port. It can do gigE (125MByte/sec) where usb/sata on arm seems to be limited to 27 MByte/sec or so (37 MByte/sec on intel i7).
Are you really MB/s rather than IOPS bound?
37 MBytes/sec is close to the USB480 limit, considering overhead, I think. I don't know why the arm devices seem to be limited to 27 MBytes/sec on USB disks, but those were the numbers I saw.
Mbps is not directly relates to IOPS ultimately you could have 16gbps fcp interface but if the storage attached to that is slow without decent caching etc the performance will still be terrible
Peter _______________________________________________
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Mbps is not directly relates to IOPS ultimately you could have 16gbps fcp interface but if the storage attached to that is slow without decent caching etc the performance will still be terrible
The same disk was used for all the usb tests, and had way more mbytes/sec over eSATA.
The iSCSI tests were done with a ramdisk.
On 08/02/2013 06:21 PM, DJ Delorie wrote:
Mbps is not directly relates to IOPS ultimately you could have 16gbps fcp interface but if the storage attached to that is slow without decent caching etc the performance will still be terrible
The same disk was used for all the usb tests, and had way more mbytes/sec over eSATA.
The iSCSI tests were done with a ramdisk.
You are missing the point, which was to question whether the real workload you are applying is sensitive to MB/s rather than IOPS as most workloads are. A 7200 rpm disk performing 4KB random operations will top out at under 120 IOPS, which is 480KB/s. If that is what your workload does, it doesn't matter whether the inrerface can do 20MB/s, 30MB/s or 300MB/s, you will still in reality be limited to 480KB/s.
Gordan
-
DJ Delorie -
Gordan Bobic -
Peter Robinson -
Richard W.M. Jones -
Scott Sullivan -
Stephen John Smoogen