On Sun, 25 August 2013 22:26:57 -0600, Scott Hallowell wrote: > > I spent a little time trying to characterize difference between my > system and the comparison NAS. One thing I looked at, which may or > may not indicate anything, was the Queue Depth in info for the LUN > under configFS on both my system and the comparison system. I put > together a little script to cat the contents of info to a configFS > entry every second or so while the copy was commencing. On my system, > I'd see the size of the "left" queue depth drop to around 103, at it's > lowest point when writing from a Windows 7 system. It gets down to 81 > when running from a WIndows 2008 system. I have a Max of 128 entries > listed. On the comparison NAS system, the Max number of queue entries > is 32, and the "left" queue depth never goes below 31. To me this indicates a latency issue. If you can measure the average latency from windows or any other initiator, you could quickly confirm. And the likely cause is the usual: cheating. Caching all data in memory will turn the problem from latency-limited to bandwidth-limited - at the cost of the odd data corruption if you happen to crash or get a power failure. If you would like to purchase this ultra-fast storage device and don't want a guarantee to actually get your data back, I can make you a good offer. ;) Jörn -- Courage is not the absence of fear, but rather the judgement that something else is more important than fear. -- Ambrose Redmoon -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
