D-Link Forums
The Graveyard - Products No Longer Supported => D-Link Storage => DNS-323 => Topic started by: GIS_Kid on April 21, 2009, 07:46:31 PM
-
I've searched the forums, and found other threads pertaining to similar issues... but none seem to be as slow as 8 mbps over a gigabit lan... this seems super slow! Are these the speeds that I can expect, or could there be an issue? I've got a dlink gigabit router and nforce gigabit lan...
core 2 duo 3ghz
4 gigs of ram
fast sata drives...
Please point me in the right direction :)
-
I was gonna post a similar question, but since you started it. I thought my 10mbps to 12mbps was bad, but yours is worse :-[
For info, this is my hardware and the data path (PC to DNS-323) - Samsung 1Tb Sata HD (internal) > Gig network adapter on a Shuttle PC running Vista > Dlink DIR-615 Gigabit Router > DNS-323 Raid1 with 2 Samsung 1Tb Sata HD (internal)
fw 1.06
-
Are we discussing megabits per second here, or megabytes per second?
8, 10 or 12 - if that is megabits per second, it's ridiculously slow - if it's megabytes second, it's reasonable.
First - a gigabit network does not guarantee gigabit throughput, especially when you're measuring file transfer speeds (as compared to network throughput speeds).
A file transfer starts on one disk and finishes on another - the speed is going to limited to the slowest of the interfaces, and is also affected by things like disk fragmentation and file size - transferring 2GB of data can be dramatically different when you compare a single 2GB file to 1000 x 2MB files.
Now - this is a topic that has been discussed adnauseum - a search of the forum should bring up several threads, including links to file transfer and I believe network speed testers.
-
Thanks for the reply. I was indeed speaking in megabytes per second. I should have come to these forums prior to purchase. If I had known the speeds would be this unbelievably brutal, I wouldn't have bought the unit. I'm not sure where else I can use my 2 tb drives if I return this thing.
I was assuming I'd be achieving speeds similar to those I get on my corporate lan. I guess I was wrong.
as for your comment:
"Now - this is a topic that has been discussed adnauseum - a search of the forum should bring up several threads, including links to file transfer and I believe network speed testers."
as I mentioned, I DID do a search of the forums and found some similar threads. They didn't seem to answer my question. But thanks for your admonishment nonetheless ::).
-
Is the Receiving client 100base-TX? If so, do you have flow control enabled?
I highly reccomend disabling flowcontrol on all your 100bTX clients (especially if they are RECEIVING data from a GB client) This can be done in your router/switch (if you have a layer 2 switch or above) you can also do it software in windoze under deviceman on each client.
perhaps that might help. If not then i would suspect something wrong in your topology, poor cables/slow client PC (virii ect)/poor switch+router.
Also keep in mind READS from the NAS will always be faster than WRITES to the NAS so if were talking 9-12MB/s WRITES. this is definitly within parameters, i would think you have limited exp with NAS as cheaper NAS devices come nowhere near this performance. THere is certainly faster devices, but their like 500+ dollars (yeesh)
-
Also keep in mind READS from the NAS will always be faster than WRITES to the NAS so if were talking 9-12MB/s WRITES. this is definitly within parameters, i would think you have limited exp with NAS as cheaper NAS devices come nowhere near this performance. THere is certainly faster devices, but their like 500+ dollars (yeesh)
This is not necessarily true - a read from the NAS is a write to the local drive - and the speed at which the local drive can be written needs to be considered.
I have one particular desktop - 3GHz, dual core P4, 512 MB RAM, gigabit ethernet and the exact same model of 80GB SATA disk that is in the DNS-323 - reading from the DNS-323 is a dismal 5 MB/sec (single 2GB file), wheras writes are almost twice the speed of a read.
-
8 to 12 MB/s is very normal for this NAS device. however I have see in the upwards of 20 MB/s but it all depends on a lot of factors. it is very true that this device is slower then other NAS devices but we are talking other NAS devices that cost way more then what this unit does. Just to let you know I get about 40 to 50 MB/s from my raid 5 SATA array on my PC server. but the cost of that equipment is way more then the 150ish for this device.
For the most part this device is OK, it has it's quirks, but does the job I need and that is back up data from main storeage.
-
My DNS-323 is connected to a Gig-E switch. I ran a Sandra File System Benchmark from my Core-2 DUO PC with Gig-E NIC to the DNS-323 samba share via mapped drive letter and got the following test results using a 2 GIG Test File and 1 Meg Block Size:
Buffered Read: 30 MB/Sec
Sequential Read: 23 MB/Sec
Random Read: 15 MB/Sec
Buffered Write: 25 MB/Sec
Sequential Write: 18 MB/Sec
Random Write: 14 MB/Sec
Random Access Time: 23 Msec
No other users were accessing the device during the tests. A "Top" running on the DNS-323 showed 95%+ CPU utilization on the DNS during some of the tests, indicating that the CPU on the DNS-323 is often the limiting factor. The DNS was configured Raid-1.
-
Nice work Jesbo.
-
In addition to the tests I posted earlier, here's a log of a few FTP transfers of a 4.6 Gig file. FTP upload (DNS-323 write) as you can see was much faster than the FTP get. Of particular note... The DNS-323 CPU was 100% busy during the upload, but was only 50% busy during download.
Local directory now I:\.
ftp> bin
200 TYPE is now 8-bit binary
ftp> put test.dat
200 PORT command successful
150 Connecting to port 5002
226-File successfully transferred
226 246.707 seconds (measured here), 18.47 Mbytes per second
ftp: 4777378304 bytes sent in 246.67Seconds 19367.33Kbytes/sec.
ftp> get foo.dat
200 PORT command successful
150-Connecting to port 5004
150 4665408.5 kbytes to download
226-File successfully transferred
226 514.467 seconds (measured here), 8.86 Mbytes per second
ftp: 4777378304 bytes received in 514.46Seconds 9286.16Kbytes/sec.
ftp>
-
Now - this is a topic that has been discussed adnauseum - a search of the forum should bring up several threads, including links to file transfer and I believe network speed testers.
fordem, what speed test tools are used here as a "standard"? i did a search of speed test, and got a lot of results but no links.
i'm installing sisoft now, but seem to recall that reading in one of the other posts that someone here had written a utility to test this?
-
Try searching for NASTester - that is the utility that was written for the task at hand.
Take a look at this (http://forums.dlink.com/index.php?topic=4690.0) thread - look for a post by mig about 8 posts down.
-
thanks, that is what i was looking for.
interesting results, i pulled that down and ran it from the "worst" location on my network which is 3 hops away from my 323.
avg of 3.62MB/sec with a high run of 5.33MB/sec. these numbers don't jive with what i see when i'm running backups, so i'm not sure which to trust.
on the fastest segment however, the system i ran it from hit the 323 so hard, it lost the network share. :)
no results, program crashed. i'm taking that as a good sign.
-
thanks, that is what i was looking for.
interesting results, i pulled that down and ran it from the "worst" location on my network which is 3 hops away from my 323.
avg of 3.62MB/sec with a high run of 5.33MB/sec. these numbers don't jive with what i see when i'm running backups, so i'm not sure which to trust.
on the fastest segment however, the system i ran it from hit the 323 so hard, it lost the network share. :)
no results, program crashed. i'm taking that as a good sign.
Just so you know - traditionally "a hop" would be between one router and the next, which I doubt is the context in which you are using the term. Do a traceroute and see how many "hops" you get - I'm betting on one.
Now - when using NASTester, try a 2GB file size (assuming you're running a gigabit LAN), and reduce the number of iterations - you may get the impression the app has crashed or hung, because it does not update the screen between iterations - just leave it a little longer.
File size has a significant impact on throughput - 2GB of data as a single file will transfer a heck of a lot quicker than 1000 x 2MB files - for each file read/written the disk drives' heads must move from the data storage area to the allocation table area (see note below) and back, and they cannot write during this move.
One of my servers, when NASTester is used with a 2GB file, can write at approximately 24MByte/sec, yet a backup from the same server delivers approximately 0.5Mbyte/sec if it's done on a folder by folder basis.
Note - before anyone decides to take me to task for the use of the term "allocation table" - every random access data storage system uses some sort of block allocation table, with DOS it was known as the file allocation table, with the ext2 file system used by linux it's referred to as a "bitmap", but it serves the same purpose - it allows the file system to keep track of which blocks have been used and which are available.
One last thing - if you can "hit" the 323 hard enough to lose the network share - it's pointing to a problem with your network, you're getting some sort of an error that is forcing the ip stack to retransmit and when the retransmits reach a critical point the network crashes, which is why the share is lost - the 323's network subsystem is capable of moving data at speeds approaching 400 mbit/sec - significantly faster than it can be written to the disks.
-
sorry, you are correct. in my instance hop=a switch from source to destination.
I just changed the setting to 2GB, and the same thing happened. I'm getting error messages inside the tool BTW, not that the app is hanging.
I'm not clear on what is wrong with my network, or why it would only surface when running this test but perhaps you can educate me further on what i'm doing wrong since you seem to be a but ahead of my learning curve.
-
drick
It's hard to network diagnosis remotely and possibly even harder for the inexperienced - essentially you need to get a network analyzer in there and look at the error numbers.
I can, however, explain why it does not show up consistently ...
A tcp/ip network is designed to be "self healing" in so far as it will detect transmission errors and fix them by retransmitting the corrupt packets - in a large network with redundant links (such as the internet), you can actually have a link fail entirely and the users be completely unaware.
In smaller networks - such as yours & mine - we have no redundant links, and tcp/ip's self healing nature tends to mask errors rather than reveal them so we can fix them. When the transmit rates are low, a few megabytes/sec the occasional error and retransmit goes unnoticed, but as the transmit rates increase, the error rate increases, and with it, the number of corrective retransmits required - the problem is that this further increases the transmit rates, and with that the errors and retransmits.
Have you ever watched a snowball rolling downhill? As it rolls it gathers more snow, becomes larger, and larger, and larger ....
Well - the same thing happens here - the transmit rate increases, the errors increase the retransmits increase, increasing the transmit rate further, etc. until the retransmits makeup more than the actual data and the connection times out.
The problem is fairly common in wireless networks in areas where there is a high density of wireless installations, and this is in fact where I first found it - the Intel ProWireless cards allow you to observe error statictics - but it can occur in any network even wired ones.
How do you fix it without the analyzer - start by examining your network cables - make sure they are correctly terminated and installed (if you crimped them yourself, there is a little more to it than just matching the wire colors - specific wire pairs must be terminated on specific pins in the connectors to avoid a condition known as split pairs)
-
fordem,
all of my wiring is cat 5e or cat6 cable that were bought in a store and appears to be correct. the other set of cables are ones that are in the walls of my SOHO which cannot be changed, that however is for the "slow" segment of my network which i expect to not be high performance (read in FastE at best not GigE).
using Intel's testing utility all of my cables show up as good, but there doesn't seem to be a way for me to attach it to the post, sorry.
-
Have the cables in the walls been certified as compliant with CAT5, 5e or 6 - doesn't really matter which - what I'm looking for is to know that the installer tested them and certified then as being compliant.
There is a condition known as 'split pairs' which is caused by incorrect termination that wil cause the symptooms you are seeing.
-
One thing I've learned over the years...
Throughput problems on the local LAN segment can be due to a duplex mismatch between the PC's network card and the switch or router into which it is connected. You can check this fairly easily by starting a CMD window and using a "netstat -e" command. If the errors count >0 and gets larger every time you issue the command (while your file copy or backup is running), then chances are you have a mismatch. Set your network adapter duplex properties to full duplex as opposed to auto or auto-negotiate and see if it resolves the issue. Local LAN errors should always be 0 if the NIC and switch/router port are in sync and your cables and connectors are all up to snuff.
-
Thanks jesbo - it's always nice to learn something new.
-
You're welcome... Duplex mismatch issues have killed performance on many occasions for me. Normally the two ends will negotiate the correct ethernet settings and all is hunky dory. But when they don't performance sucks. The error correction and retransmit logic overcomes the errors and the data gets through, but at a huge penalty in performance. Often you don't even realize its an issue unless you are copying large files or doing backups across the network.
-
Have the cables in the walls been certified as compliant with CAT5, 5e or 6 - doesn't really matter which - what I'm looking for is to know that the installer tested them and certified then as being compliant.
There is a condition known as 'split pairs' which is caused by incorrect termination that wil cause the symptooms you are seeing.
let me be more specific.
the ones in the wall are CAT5 if i'm lucky, not CAT5E or CAT6 and i cannot check or change them even if they are bad.
what i want to confirm is that on the segment that does NOT use these cables is set up "correctly".
-
One thing I've learned over the years...
Throughput problems on the local LAN segment can be due to a duplex mismatch between the PC's network card and the switch or router into which it is connected. You can check this fairly easily by starting a CMD window and using a "netstat -e" command. If the errors count >0 and gets larger every time you issue the command (while your file copy or backup is running), then chances are you have a mismatch. Set your network adapter duplex properties to full duplex as opposed to auto or auto-negotiate and see if it resolves the issue. Local LAN errors should always be 0 if the NIC and switch/router port are in sync and your cables and connectors are all up to snuff.
in my case i have all my NIC's and the 323 already hard set to Gig and full duplex, but thanks for the suggestion.
i'll test the netstat later in the week time permitting when traffic is hitting the 323.
-
i have 2 Intel Pro/1000 MT server NIC's in route to replace both current NIC's, this will eliminate any contention that the NIC is the problem for me.
i'm also checking to see if i have any incorrect settings on my core switch to eliminate that from the mix as well. i really wonder if all this is going to end up with the net result being that the 323 is just slow, but it's good to get my networking IQ up a little bit i suppose.
-
For comparison sake, I just did an informal speed test of my DNS-323 - while making a backup copy of files before upgrading my firmware (1.03 to 1.07).
Using Robocopy I achieved a read speed of...
1025 MegaBytes/minute (yields about 17 MB/second)
106.8 GB in 1 hour 46 minutes
My DNS-323 has two 500GB, 7200RPM drives in a RAID-1 config. Both computer and DNS are on 1GbE across a D-Link DIR-655.
I'll try to do an informal write test as well. FYI - for straight file transfer on a Windows system there's nothing better than Robocopy (free from MS).
Cheers,
Jim
-
jruz,
good call on the robocopy (now MSFT Rich Tools / Rich Copy 4.0), i pulled that down and it's WAY eaier than all the other suggestions mentioned here and easy to use. the only thing i wasn't clear on is where the log is located? i just took the "final" number from the bottom right of the tray as my results.
i tried the opposite, writing 10.5Gb (all Linux iso's if it matters) using RC4 (all default options) to the 323 and here are the numbers i got:
13,217,907 bytes/sec (not sure how you did the math on conversion, so i'm posting the raw numbers)
took about 15m
my dns config is:
dns 323
jumbo frames at 4k
ethernet hard set to 1000mbps/full
2x750GB HDD's in RAID 1
Win Server 2k8 x32
Netgear GA311 NIC / Realtek 5218_0427 drivers (which are buggy on 2k8)
4k jumbo frames - interesting note here, per the windows task manager network tab, the NIC never used more than 13% of the available bandwidth on the write to 323 option
ethernet hard set to 1000mbps/full
2x750GB HDD's in RAID 1 (using Intel ICH8 raid controller)
then taking the same set of data and copying back from 323 to the server:
1st observation is that the NIC on the server jumped up to almost %18 usage
2nd observation is that there were several huge drop offs where the copy stalled / stopped on the NW monitor
12,215,465 bytes/sec
again around 15m
-
I have had 0 luck using jumbo frames on my own LAN. I leave it disabled on the DNS-323 and set standard frame size on my PC LAn adapters. The only setting I increase on my PC adapters is the number of transmit and receive buffers... I set them both to 512.
When I try to use jumbo frames, access to the DNS-323 slows to a crawl and I frequently lose the shares (they disappear). Jumbo frames can be tricky and I never had the time or energy to debug why they do not work. My PC NIC, the Gigabit Switch and DNS-323 all appear to support jumbo frames to 9K, but I have yet to have it work reliably.
-
i've been wondering about that as well, so decided to give it a try.
disabled jumbo frames on the 323 and the GA311. it looks like i cannot modify the transmit buffers above 128 on the NIC, receive was already set at 512.
same data set copy to 323
15m @ 12,472,206
same data set copy from 323
13.5m @ 13,567,839
so one is a little slower the other a little faster.
-
then just for giggles, i tried copying the same data from the same source file server to another server on my network.
target server W2K8 Ent x64
Broadcom NIC
jumbo frames off (MTU1500)
copy to
17m @ 10,586,736
copy from
5m @ 33,456,602 (WOW)
-
same thing, except with jumbo frames on / 3k MTU on both NIC's
copy to
17m @ 10,727,759
copy from
6m @ 29,483,315
-
finally, with jumbo frames on / 6k MTU on both NIC's
copy to
14m @ 13,280,182
copy from
8m @ 23,009,948
-
now back to the task at hand, optimizing the 323. changing the mtu on NIC and 323 to 6000 as that seemed to be the best balance on the servers.
copy from file server to 323
13m @ 13,783,465
copy from 323 to file server
16m @ 11,264,611
weird.. i give up for tonight
-
as if this wasn't complicated enough, 6k block size now causes video streaming to run like crap. dropping to 3k fixes this, so now re-running with 3k on both ends.
copy from file server to 323
14m @ 13,649,969
interesting side note here is that the traffic flow through the NIC was very consistent at around 12% vs. the huge peaks and valleys seen with the 6k block size.
copy from 323 to file server
18m @ 10,499,374
on this copy, the major peaks and valleys are back again with some interesting troughs at 0%
---
so, it looks like i need to wait for my new NIC's to arrive before doing any more testing.