Quote:
|
Originally Posted by radio
I did see those spikes on your earlier post, but never really thought about them. I suppose they are the same. It's hard to tell, but they do look regular. I assume you expect this problem to stay once I mirror the drives? - or maybe not if the cache is used more in the raid computations.
|
I did test with RAID 0, Mirror, and Single Drive operation, but I honestly can't remember for sure what the effects were. -IF- I remember correctly, the mirror and single drive operation had no real data spikes that I remember.
Quote:
|
Originally Posted by radio
Can I set the cache size with debug? Perhpas do some more testing before I toast it. I needed more ram to build the array. FYI.
|
Yes, there are some cahce settings in debug, but I don't think they stick if the unit is turned off. I could be wrong, let us know...
Quote:
|
Originally Posted by radio
The CPU load idea does not make sense to me because this happens durring very minor transfers (23k/sec)
|
I don't see the spikes at all in small transfers. Even during large transfers, these spikes are less pronounced than you are showing. The spikes I have seen (on multiple SNAP 4000 units) have been very quick, meaning they only dropped the average transfer speed by at most 0.2 MB/sec. They were very momentary and not a real problem.
I have streamed music from my SNAP 4000 units (I like to listen to my music on my notebook in another room while I am working). Not once have I heard even a single glitch, even when streaming 320 BPS files.
Once again, I have to attribute this to either the 256 MB memory, the 320 GB drives, or the combination of both. CPU load does have an effect on a RAID arrarys using that CPU for XOR operations. That same CPU is what has to drive the data transfers to and from memory (or cache), as well as to and from the NIC.