Very slow data transfer from LAN switch to MyCloud NAS

I would be interested if anyone has encountered the following issue . . .

I have put the MyCloud NAS on another switch and noticed that the data throughput has drastically dropped. Examined the NAS’s logs and saw the following logged while transferring files from laptop:

Aug 12 12:36:02 NAS-MC kernel: [314895.876132] PHY: comcerto-0:00 - Link is Down
Aug 12 12:36:07 NAS-MC kernel: [314900.876138] PHY: comcerto-0:00 - Link is Up - 1000/Full
Aug 12 23:37:33 NAS-MC kernel: [354587.156123] PHY: comcerto-0:00 - Link is Down
Aug 12 23:37:36 NAS-MC kernel: [354590.156131] PHY: comcerto-0:00 - Link is Up - 1000/Full
Aug 12 23:37:56 NAS-MC kernel: [354610.156151] PHY: comcerto-0:00 - Link is Down
Aug 12 23:37:58 NAS-MC kernel: [354612.156142] PHY: comcerto-0:00 - Link is Up - 1000/Full
Aug 12 23:38:10 NAS-MC kernel: [354624.156134] PHY: comcerto-0:00 - Link is Down
Aug 12 23:38:12 NAS-MC kernel: [354626.156148] PHY: comcerto-0:00 - Link is Up - 1000/Full
Aug 12 23:38:20 NAS-MC kernel: [354634.156125] PHY: comcerto-0:00 - Link is Down
Aug 12 23:38:21 NAS-MC kernel: [354635.156138] PHY: comcerto-0:00 - Link is Up - 1000/Full
Aug 12 23:38:53 NAS-MC kernel: [354667.156133] PHY: comcerto-0:00 - Link is Down
Aug 12 23:38:56 NAS-MC kernel: [354670.156139] PHY: comcerto-0:00 - Link is Up - 1000/Full
Aug 12 23:39:40 NAS-MC kernel: [354714.156129] PHY: comcerto-0:00 - Link is Down
Aug 12 23:39:43 NAS-MC kernel: [354717.156210] PHY: comcerto-0:00 - Link is Up - 1000/Full
Aug 12 23:40:11 NAS-MC kernel: [354745.156126] PHY: comcerto-0:00 - Link is Down
Aug 12 23:40:14 NAS-MC kernel: [354748.156146] PHY: comcerto-0:00 - Link is Up - 1000/Full
Aug 12 23:40:44 NAS-MC kernel: [354778.166115] PHY: comcerto-0:00 - Link is Down
Aug 12 23:40:47 NAS-MC kernel: [354781.166123] PHY: comcerto-0:00 - Link is Up - 1000/Full
Aug 12 23:40:53 NAS-MC kernel: [354787.166136] PHY: comcerto-0:00 - Link is Down
Aug 12 23:40:56 NAS-MC kernel: [354790.166142] PHY: comcerto-0:00 - Link is Up - 1000/Full
Aug 12 23:41:02 NAS-MC kernel: [354796.166123] PHY: comcerto-0:00 - Link is Down
Aug 12 23:41:05 NAS-MC kernel: [354799.166121] PHY: comcerto-0:00 - Link is Up - 1000/Full
Aug 12 23:41:25 NAS-MC kernel: [354819.166130] PHY: comcerto-0:00 - Link is Down
Aug 12 23:41:27 NAS-MC kernel: [354821.166129] PHY: comcerto-0:00 - Link is Up - 1000/Full

This stopped when I cancelled the file copy process.

Problematic physical network path:
Laptop -> Linksys E2000 -> TP-LINK TL-SG1005D -> MyCloud NAS

Working physical network path:
Laptop -> Linksys E2000 -> Netgear ProSafe GS108 -> MyCloud NAS

A second NAS’s data throughput is not affected when either network switch is used.

The link rapidly drops and re-establishes the link only when a continuous stream of data is transferred.

If anyone has poor data throughput, please check for this condition. It could be that your router is using the same network switching hardware as the TP-LINK switch.

1 Like

Can you provide before and after data transfer rates for context?  Please share results if/when you discover why this is happening only with My Cloud NAS.

I have not seen it but some thoughts

did you reboot both switches after moving the mycloud? switches maintain devive location and could be getting confused

what are the lights near the network cable doing during the copy?

Way ahead of you. One of the early ruled of trouble-shooting. Power it all down and then power it all up.

Ro Router was allowed to initialise, then followed by the switch and then both WD NAS.

Remember, the second WD NAS that’s not a MyCloud is not affected by this issue.  Also, tried other cables and re-tested cables.

Netgear switch = Over 50 M/bits sec.

TP-LINK switrch = About 7 M/bits sec.

Massive difference.

jdeviney wrote:

Can you provide before and after data transfer rates for context?  Please share results if/when you discover why this is happening only with My Cloud NAS.

The same thing happens with my Mycloud.

Router Zyxel Keenetic Ultra, 1000M FDX for Mycloud’s and computer’s connection.

When I copy a great amount of data it starts quite fast, but then goes down to 0, waits for something for a few seconds and then returns back to about 70 mbps, then back again to 0 and up again. That’s not how the hard disk drive use to work.

While having big files (over 7 Gb) in Utorrent it always indicates disk cache overflow 100% and again I have a zero download speed for some time.

Myron, though it’s fairly rare these days, there are systems with which auto negotiation is unreliable.

Does it exhibit the same bahavior on different ports of the same switch?

All the ports on the TP-LINK switch.

I would assume you’ve already tried another cable…

My suggestion would be to use ethtool command on the Cloud to disable autonegotiation and fix the connection to 1000/Full and see if that changes anything.

If it “works,” don’t consider it a permanent “fix…”  just a hint that autonegotation on the TP-Link is not working with the My Cloud.

I’ve not had a need to use ethtool. I could take time to learn hor to use it, or (Nudge… Nudge… Wink… Wink…) you could reply back with the commands on how to enable, disable, and fix auto-negotiation?  :smiley:

i did suspect auto-negotiation. By rights one end should be fixed and the other end should determine what it’s supposed to operate as. Usually autonegotiation on the computing device should be fixed.  With me going back to the Netgear switch, all is fine and dandy, but the TP-LINK switch is back in it’s box. I guess I’ll get to use it somewhere else some day.

Oh, I know all too well not to make it a permanant start-up in case the network port goes down and a power-cycle of the MyCloud NAS may be needed.

Yes, I did try another cable. I put on a cable I made. Not stranded wire but solid core wire just to be absolutly sure.

Actually, best practice is to either run Autonegotiation at BOTH ends, or do fixed at both ends.

If one does Fixed at one end, there’s no signalling to indicate to the other end what it should do (other than Speed, which is determined differently) – so doing Auto / Fixed usually winds up causing Duplex mismatches because the Fixed end is Full, and the Auto end will default to Half.

Anyway, the command to disable auto and do Fixed Gig/Full is 

 ethtool -s eth0 speed 1000 duplex full

To put it back:

ethtool -s eth0 autoneg on

1 Like

I suspect you have the 4.x firmware in the MyCloud…That’s why the other NAS isn’t affected…

Some other users noticed the “hopping” transfer of files with ups and downs too and reinstall the old 3.x firmware which wasn’t affected by that behavior. I did too and transfer is way better…

You can find the procedure to downgrade somewhere else in this forum.

WD should replace the 4.x as soon as possible…

Thanks Tony. on your advise I think I’ll leave it on auto neg.  Nearly got it right. By accident I used /dev/eth0 when I should have used eth0. Head was on auto-pilot.

So, Wijllie, you’re stating that it was a software issue?

By any chance when you’re on v3 of the My Cloud firmware, could you access the Linux shelll via. SSH, invoke the command ethtool eth0 and post the results of that command here?

On mine it is:

NAS-MC:~# ethtool eth0
Settings for eth0:
        Supported ports: [TP MII]
        Supported link modes: 10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supported pause frame use: Symmetric Receive-only
        Supports auto-negotiation: Yes
        Advertised link modes: 10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: external
        Auto-negotiation: on
        Current message level: 0x00000036 (54)
                               probe link ifdown ifup
        Link detected: yes

… and from the NAS that has no problems:

NAS:~# ethtool eth0
Settings for eth0:
        Supported ports: [MII]
        Supported link modes: 10baseT/Full
                                100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes: 10baseT/Full
                                100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: external
        Auto-negotiation: on
        Link detected: yes

What is PHYAD?

what I found:

Physical Address (PHYAD)

Both PHY devices are attached to the MDIO bus. Each of these has a

different physical address. To address the intended PHY, its physical address should be

known by the MDIO master (in this case an Ethernet MAC) and placed into the PHYAD field

of the MDIO frame (see MDIO Transactions).

The PHYAD field for an MDIO frame is a 5-bit binary value capable of addressing 32 unique

addresses. However, every MDIO slave must respond to physical address 0. This

requirement dictates that the physical address for any particular PHY must not be set to 0

to avoid MDIO contention. Physical Addresses 1 through to 31 can be used to connect up

to 31 PHY devices onto a single MDIO bus.

Physical Address 0 can be used to write a single command that is obeyed by all attached

PHYs, such as a reset or power-down command.

Don’t know what this exactly mean in plain English :wink:

This is my outprint, looks the same…

/$ ethtool eth0
Settings for eth0:
	Supported ports: [TP MII]
	Supported link modes: 10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Advertised link modes: 10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Half 1000baseT/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 0
	Transceiver: external
	Auto-negotiation: on
	Current message level: 0x00000036 (54)
			       probe link ifdown ifup
	Link detected: yes

Myron wrote:

So, Wijllie, you’re stating that it was a software issue?

 

By any chance when you’re on v3 of the My Cloud firmware, could you access the Linux shelll via. SSH, invoke the command ethtool eth0 and post the results of that command here?

On mine it is:

NAS-MC:~# ethtool eth0
Settings for eth0:
Supported ports: [TP MII]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Current message level: 0x00000036 (54)
probe link ifdown ifup
Link detected: yes

… and from the NAS that has no problems:

NAS:~# ethtool eth0
Settings for eth0:
Supported ports: [MII]
Supported link modes: 10baseT/Full
100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Full
100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: external
Auto-negotiation: on
Link detected: yes

What is PHYAD?

I found and watched the following video on You Tube. Maybe this will help some users.

https://www.youtube.com/watch?v=FcJLbFdHvJE

Posted by,
cat0w (USA)

Wijllie wrote:

what I found:

 

Physical Address (PHYAD)

 

Both PHY devices are attached to the MDIO bus. Each of these has a

different physical address. To address the intended PHY, its physical address should be

known by the MDIO master (in this case an Ethernet MAC) and placed into the PHYAD field

of the MDIO frame (see MDIO Transactions).

The PHYAD field for an MDIO frame is a 5-bit binary value capable of addressing 32 unique

addresses. However, every MDIO slave must respond to physical address 0. This

requirement dictates that the physical address for any particular PHY must not be set to 0

to avoid MDIO contention. Physical Addresses 1 through to 31 can be used to connect up

to 31 PHY devices onto a single MDIO bus.

Physical Address 0 can be used to write a single command that is obeyed by all attached

PHYs, such as a reset or power-down command.

 

 

Don’t know what this exactly mean in plain English :wink:

Here’s the English:

A PHY is a PHYsical, electrical interface (as opposed to a logical one)

An MDIO = Management Data Input and Output and a BUS means multiple devices share an elelctric wire (a bus)

There are actually TWO physical interfaces (there can be up to 32), and each has an address (a PHYAD - PHYsical inetrface address, as opposed to a MAC (Media Access Control) address)

That’s not really important.  That’s all digit-head talk.  All you need to know eitehr BOTH SIDES set to autonegotiate OR you fix BOTH sides of the connection.  If you do only one or the other, it is very bad news.

I has the same issue with with a TrendNet TEG-S8g switch, and was able to fix it with a higher quality cable and moving some ports around.  I suspect that there may have been some problems caused be a neighboring port.  I also suspect I should use a higher quality Gigibit switch for high-speed NAS data transfer.

remaker wrote:


Wijllie wrote:

what I found:

 

Physical Address (PHYAD)

 

Both PHY devices are attached to the MDIO bus. Each of these has a

different physical address. To address the intended PHY, its physical address should be

known by the MDIO master (in this case an Ethernet MAC) and placed into the PHYAD field

of the MDIO frame (see MDIO Transactions).

The PHYAD field for an MDIO frame is a 5-bit binary value capable of addressing 32 unique

addresses. However, every MDIO slave must respond to physical address 0. This

requirement dictates that the physical address for any particular PHY must not be set to 0

to avoid MDIO contention. Physical Addresses 1 through to 31 can be used to connect up

to 31 PHY devices onto a single MDIO bus.

Physical Address 0 can be used to write a single command that is obeyed by all attached

PHYs, such as a reset or power-down command.

 

 

Don’t know what this exactly mean in plain English :wink:


 

Here’s the English:

A PHY is a PHYsical, electrical interface (as opposed to a logical one)

An MDIO = Management Data Input and Output and a BUS means multiple devices share an elelctric wire (a bus)

 

There are actually TWO physical interfaces (there can be up to 32), and each has an address (a PHYAD - PHYsical inetrface address, as opposed to a MAC (Media Access Control) address)

 

That’s not really important.  That’s all digit-head talk.  All you need to know eitehr BOTH SIDES set to autonegotiate OR you fix BOTH sides of the connection.  If you do only one or the other, it is very bad news.

 

I has the same issue with with a TrendNet TEG-S8g switch, and was able to fix it with a higher quality cable and moving some ports around.  I suspect that there may have been some problems caused be a neighboring port.  I also suspect I should use a higher quality Gigibit switch for high-speed NAS data transfer.

Thx for the info :) 

So the PHYAD 0 and 1 just means which port it is connected to, but how can you see you have problems with a gigabit switch or Cat5e or higher cable? How can you test that setup, only by exchanging the switches and cables? Would be a high cost solution to find out, is there no other solution to test your setup? With some kind of woftware maybe?

What I experienced was on a fully configured gagabit network. Seems the My Cloud doies not want to work with a TP-LINK eco Gigabit switch. For me this tutorial does not apply.> * * *
cat0w wrote:

I found and watched the following video on You Tube. Maybe this will help some users.

 

https://www.youtube.com/watch?v=FcJLbFdHvJE

 

Posted by,
cat0w (USA)