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.
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.
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.
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.
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.
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?
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
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.
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
/$ 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
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
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.
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
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.
