Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[fordem]

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)

[drick]

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.

[fordem]

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.

[jesbo09]

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.

[fordem]

Thanks jesbo - it's always nice to learn something new.

[jesbo09]

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.

[drick]

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".

[drick]

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.

[drick]

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.

[jruz]

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

[drick]

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

[jesbo09]

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.

[drick]

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.

[drick]

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)

[drick]

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