With OS X 10.6 the hardware is willing but the software quite frankly sucks.
First apologies for not posting this update sooner. I actually received my IOCELL 351UNE back on 12/23. (In time to be a Christmas gift to myself of dubious value?

) Not sure what I was waiting for, but it's way past time to say something about my experience with it so far.
I haven't done much and I was primarily focused on seeing how the device works with my MacBook under OS X 10.6, Snow Leopard. As far I could tell, the same OS specific software is used to support all NDAS devices access from that OS. I have installed an older Seagate 400GB ST3400620AS 7200.10 SATA drive in the 351UNE.
The 351UNE shows up as hardware version 2.0, revision 16. My older model, an OWC NASPerform, shows only as hardware version 1.1. But both are configured on both Windows 7 Home (64-bit) and Mac OS X 10.6 or 10.5 using the same NDAS configuration utility for either the Windows or Mac OS, respectively.
My Kill-A-Watt showed power usage of around 16 watts when the drive was in use and around 8 watts when the 351UNE switched to whatever "power saving" mode it uses.
The 351UNE with v2.0 hardware experiences the same performance "bug" as the NASPerform hardware v1.1. Using wireless 802.11n via Snow Leopard, OS X 10.6.2, I found reading from the device was reduced to KiB/s versus MiB/s rates when writing to the device. Things were slightly better in that I could read from the 351UNE at ~0.61 MiB/s versus ~0.13 MiB/s for the NASPerform. (Possibly a consequence of a slightly "better" NIC on the newer device and/or the 351UNE's gigabit ethernet support??)
In the same context I saw write speeds from ~4.7 to ~8.2 MiB/s or roughly 10 times faster. I attribute the wide write speed variations to the fact that I wasn't trying to be very "controlled" about my wireless environment. All I did to test transfer rates was to note the approx start & end times to the nearest second by looking at the clock on the MacBook. I then used a spreadsheet to divide total bytes transferred by the transfer time in seconds.
Aside from not starting any other file transfers, I continued to use the MacBook as I normally would while the "test" was running. I used drag'n drop to do the file transfers to/from the NDAS device.
The bottom line for me is that reads are always at least 10 times slower than writes when using 802.11n and Snow Leopard. I can only explain this as being caused by "bad" device driver code.
Other things I have noticed that I believe support this conclusion are:
- I do not see this reduction in 802.11n read versus write speeds when the MacBook is running Leopard, OS X 10.5.8. In other words, the problem disappears when using the same hardware but an earlier version of the OS.
- I also did not see the read speed reduction when I ran Windows 7 RC1 under OS X 10.6 using Parallels v5. Both reads and writes were in the MiB/s range even though I was running Win 7 in a virtual machine running in Snow Leopard. (To put it another way, if I use the Windows 7 NDAS driver on my MacBook running Snow Leopard, I don't see this problem).
- Error messages (see excerpt below) in the Snow Leopard kernel log.
Dec 18 23:36:29 MacBook kernel[0]: [com_ximeta_driver_NDASPhysicalUnitDevice:591][updateStatus] Change Status from 2 to 4
Dec 28 11:29:01 MacBook kernel[0]: [com_ximeta_driver_NDASPhysicalUnitDevice:591][updateStatus] Change Status from 2 to 4
Dec 28 11:29:01 MacBook kernel[0]: [com_ximeta_driver_NDASPhysicalUnitDevice:591][updateStatus] Change Status from 4 to 6
Dec 28 11:29:03 MacBook kernel[0]: Warning - com.Seagate.driver.PowSecDriver declares no kernel dependencies; using com.apple.kernel.6.0.
Dec 28 11:29:03 MacBook kernel[0]: Couldn't alloc class "com_seagate_FDEBootStrap"
Dec 28 11:29:03: --- last message repeated 1 time ---
Dec 28 11:29:03 MacBook kernel[0]: com_seagate_IOPowSec00 overriding init
Dec 28 11:29:03 MacBook kernel[0]: com_seagate_IOPowSec00: No USBInterface found
Dec 28 11:29:03 MacBook kernel[0]: com_seagate_IOPowSec00: GetVendorAndModelIDInfo failed
Dec 28 11:29:03 MacBook kernel[0]: Couldn't alloc class "com_seagate_FDEBootStrap"
Dec 28 11:29:13: --- last message repeated 4 times ---
Dec 28 11:29:13 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 0
Dec 28 11:29:18 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 1
Dec 28 11:29:21 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 0
Dec 28 11:29:51 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 3
Dec 28 11:29:52 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 4
Dec 28 11:30:12: --- last message repeated 1 time ---
Dec 28 11:30:12 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 3
Dec 28 11:30:13 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 2
Dec 28 11:30:13 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 1
Dec 28 11:30:41 MacBook kernel[0]: Insomnia: Lid was closed
Dec 28 11:30:41 MacBook kernel[0]: Insomnia: kIOPMClamshellOpened sent to root
Dec 28 11:32:43 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 3
Dec 28 11:33:54 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 2
Dec 28 11:33:54 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 0
Dec 28 11:33:55 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 4
Dec 28 11:33:55 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 3
Dec 28 11:33:55 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 2
Dec 28 11:33:56 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 0
Dec 28 11:33:56 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 2
Dec 28 11:33:57 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 0
Dec 28 11:33:57 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 2
Dec 28 11:33:59: --- last message repeated 1 time ---
Dec 28 11:33:57 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 1
Dec 28 11:33:59 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 0
Dec 28 11:33:59 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 3
Dec 28 11:34:00: --- last message repeated 1 time ---
Dec 28 11:34:00 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 1
Dec 28 11:38:36: --- last message repeated 1 time ---
Dec 28 11:38:36 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 9
Dec 28 11:38:36 MacBook kernel[0]: [com_ximeta_driver_NDASDevice:1880][processReadCommand] too Long time!!! Reduced 7
Dec 28 12:17:30: --- last message repeated 1 time ---
I've started the process of trying to get Ximeta to fix this, but haven't heard back from anyone other than their level 1 tech support contact. Perhaps everyone else is still on vacation?
-irrational john