With that in mind, I ran the bonnie++ tests again while pinging the PandaBoard (from the same system running minicom to access the serial console of the PandaBoard). The first row is copied-and-pasted from the last test. The second row holds the new results.
| Version 1.96 | Sequential Output | Sequential Input | Random Seeks | ||||||||||
| Size | Per Char | Block | Rewrite | Per Char | Block | ||||||||
| K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | K/sec | % CPU | /sec | % CPU | ||
| USB HD | 2G | 43 | 99 | 9017 | 16 | 4538 | 6 | 369 | 99 | 12357 | 9 | 93.9 | 6 |
| Latency | 215ms | 5849ms | 5889ms | 52858us | 108ms | 7643ms | |||||||
| USB HD with ping | 2G | 38 | 99 | 19038 | 39 | 9709 | 14 | 364 | 99 | 24947 | 21 | 162.7 | 11 |
| Latency | 220ms | 1714ms | 1319ms | 62165us | 16327us | 1542ms | |||||||
That's amazing! Sequential Writes more than doubled: from 9017 K/sec to 19038 K/sec. And Sequential Reads doubled: from 12357 K/sec to 24947 K/sec!
There seems to be a bug somewhere, maybe in the smsc95xx driver? If this can be fixed, using a USB hard drive could greatly improve the storage speeds on the PandaBoard.
Jeff: Please see a fix the USB HDD performance issue as noted in: http://groups.google.com/group/pandaboard/browse_thread/thread/6dc03bf5897694e6
ReplyDeleteThanks for the pointer! I'll look into that. The thread seems to indicate it's a problem with gcc-4.6.0, however, Fedora 13 used gcc-4.4.5, and the kernel I tested with was compiled with gcc-4.3.3, so this may be a different problem.
ReplyDeleteI hear this has been fixed. I wasn't able to find a page noting the resolution. Do you have any links handy?
ReplyDeleteI'm also wondering if this affects USB cameras, as we use those with the pandaboard and would appreciate the USB throughput