• April 19, 2024, 06:51:07 PM
  • Welcome, Guest
Please login or register.

Login with username, password and session length
Advanced search  

News:

This Forum Beta is ONLY for registered owners of D-Link products in the USA for which we have created boards at this time.

Pages: 1 [2]

Author Topic: What Model of NAS are good for you  (Read 13985 times)

mig

  • Level 3 Member
  • ***
  • Posts: 217
Re: What Model of NAS are good for you
« Reply #15 on: September 10, 2010, 01:11:44 PM »

I disagree with "clearly". Memory is not an issue and is only used for caching in this case.

Memory is the issue.

Please read Bill Meade's article from 2007 http://www.smallnetbuilder.com/content/view/29936/79/1/4/

Quote from: Bill Meade at www.smallnetbuilder.com
...it looks like the current state of the art in NAS performance follows the first 3 laws of finance: get the cache, get the cache, get the cache.
« Last Edit: September 10, 2010, 01:23:43 PM by mig »
Logged

dosborne

  • Level 5 Member
  • *****
  • Posts: 598
Re: What Model of NAS are good for you
« Reply #16 on: September 10, 2010, 02:48:16 PM »

We will have to disagree then. Memory as you described it is RAM, used for program loading. Cache memory is completely different.
Logged
3 x DNS-323 with 2 x 2TB WD Drives each for a total of 12 TB Storage and Backup. Running DLink Firmware v1.08 and Fonz Fun Plug (FFP) v0.5 for improved software support.

mig

  • Level 3 Member
  • ***
  • Posts: 217
Re: What Model of NAS are good for you
« Reply #17 on: September 10, 2010, 04:15:18 PM »

We will have to disagree then. Memory as you described it is RAM, used for program loading. Cache memory is completely different.

You don't have to disagree with me (I'm just a nobody).  You have to disagree with Bill Meade
(who writes about NAS technology for a living).  I think the article does a good job of describing RAM
and Cache use in a NAS, without any mention of program loading.  And still comes to the conclusion...
Quote from: Bill Meade at www.smallnetbuilder.com
The best place to put your money to optimize NAS performance is to beef up the RAM on a NAS and each networked client.

Perhaps your difference of opinion comes from you being in the "egg" camp (as Bill describes it) and Bill (and myself) are in the "chicken" camp.
Logged

chriso

  • Guest
Re: What Model of NAS are good for you
« Reply #18 on: September 11, 2010, 07:42:30 PM »

You don't have to disagree with me (I'm just a nobody).  You have to disagree with Bill Meade
(who writes about NAS technology for a living).  I think the article does a good job of describing RAM
and Cache use in a NAS, without any mention of program loading.  And still comes to the conclusion...
Perhaps your difference of opinion comes from you being in the "egg" camp (as Bill describes it) and Bill (and myself) are in the "chicken" camp.

Since I started some of this with my "clearly" comment, I going to throw a few more things out.  First I shouldn't have said "clearly", I should have said "clear to me", because clearly based on experience and other factors what is clear to one person isn't to the other.  But let me now tell you why I believe what I believe.

First the idea that the drive is the problem.  The drive when put in a high performance machine would easily support the operations in question without the performance hit described.  Second the person describing the problem already stated that if the do BT on one drive and work off of the second drive it is still slow (as in a second drive and its ability to deliver data didn't fix the problem).  The drive(s) are not the problem.  You brought up the fact about it might be the drive controller.  I say no way.  If I ask the DNS-323 to copy files from one disk to another, I will see quite good performance, and it will be far above any performance that you see in any network traffic.

That brings us to the network.  If say the network can perform at X Mbps with no load on the CPU, like just transferring data through it from data that is in memory then the network system in the DNS-323 can handle that much.  That basically brings us down to the CPU/Memory/Bus.  Well in the above test of memory to network test, the CPU, Memory, and Bus are all being used.  So they can do at least that speed.  Plus the disk to disk transfer, which has transfer speeds far exceeding the BT and working at the same time requirements for the Bus, says it is not the Bus transfer speed that is the bottleneck.

That leave me with the CPU and the Memory.  Since I have never used BT I don't know its CPU requirements so I left it at CPU and/or Memory.  But memory would be my first guess.  Because BT is most likely just a transfer protocol and they tend to be I/O and/or memory bound.  And the belief that it can't be memory seems really strange point of view to me since here is what that memory (Yes RAM, a disk is not memory unless you are talking about virtual memory) is used for.  First off it is used to hold all the programs running and their data, this includes the OS, and its drivers and such.  Second it is used to cache disk I/O, mine is typically consuming 10 Meg just for the cache, and the cache is dynamically changed as the need arises.  Next, about those programs and memory.  Different programs ask for different amounts of memory.  Like I said I have no idea how much memory BT uses, but BT was certainly written for systems that have a lot more memory on them.  And if someone is trying to keep track of files and data contents, and they are trying to make things faster they all count on going to the memory instead say doing something on the hard drive to speed things up.  This works great until you run out of memory, and then the OS has no choice, but to swap things out to the hard drive, and it can quickly become a war of what swapping in and out.  I use s3cmd (python) to transfer my backups to offline, and if I use the sync command on a directory with more then say 1000 files in it, it will run out of memory and go into swap hell, and the DNS-323 will have to be rebooted, so instead I use a Perl script to call s3cmd to transfer the require files one at a time.  So it really does depend on how the memory is used, and if the programmer was aware of the fact that memory might be limited or not.

Back to the CPU.  Short of BT doing some fancy computing, the operations are all about moving data around like from network to hard drive.  As such this really shouldn't taxi the CPU much, and for my backups both locally and offline I don't see it really keeping the CPU that busy (as shown by top) so I would think it is the same with BT.

As people might have guessed by these statements I'm not casual user, as a matter of fact some might call me an expert.  And you do learn a few things working in the computer field for 35 years with 30+ years of programming experience (started as a hardware guy, and switch to software).
« Last Edit: September 11, 2010, 07:45:13 PM by chriso »
Logged
Pages: 1 [2]