Downgrading ReadyNAS firmware from 6.10.x - Redux

[DoctorBrown]

I know this subject has been covered in the past, but almost all the articles are from many years ago. And none are helpful for my issue. I've been using my reliable ReadyNAS 102 for many years now. It's now been upgraded to 6.10.8. The problem I'm having is the throughput is only able to get to about 100 Mb/s. I know in the past, it used to be about 500Mb/s. I'm not sure when this started but I just noticed a month or so ago.

I've gone though everything I can think of, but nothing's worked. I have another thread here where I'm getting help working on that part, but in this thread I want to know more about the currently known pitfalls of trying to downgrade the firmware to see if that's playing a role. Another user responded to my other thread and said their throughput was near what I was getting in the past. So this may be a shot-in-the-dark.

So far I've been able to downgrade to 6.10.0, but not older, at least by the methods documented by Netgear or other posts. I'm also aware of some information that suggests that it's not possible due to changes in the bootloader.

I'd appreciate it greatly if anyone can shed more details or point me to more info on the Downgrading processes limits and methods. I'm at the point of considering chucking this one. And getting a non-Netgear system.

Again, thanks for any insights.

[Sandshark]

Because ARM based ReadyNAS use UBOOT to load the OS, they are far more fragile WRT OS downgrades than an Intel based system.  As for the limits, they are officially that you can only go backwards beyond the first decimal place, which is as far as you've already gone. (6.10.x to 6.10.1 is OK, but not to 6.9.x).

I have never downgraded an ARM based system beyond the Netgear recommendation.  I have done so on an Intel system, but always as a part of a factory default.  USB recovery doesn't check the version, so that's one way to accomplish it.  Another is to edit the file and give it a bogus version number that looks like an upgrade.  But you are at your own risk as to potentially bricking the NAS.  The reason for this being a part of a factory default is that it insures that there are no leftover configuration files from the previous version that are not backwards compatible, since most are not changed directly by an OS version change.

[DoctorBrown]

---

@Sandshark.

---

Thank you for the very useful info. It seems unwise to try to downgrade this any further.

Is there anything you can think of that I might do to figure out why my NAS is so slow? I've ssh'd into the NAS and used top to monitor the CPU usage and it's very high when using Windows Explorer to copy large files, about 90%.

I'm at a loss to figure this out.

[Sandshark]

Your NAS is slow because the 100 series are the least capable OS6 based ReadyNAS.  Both the processor and RAM are limitations.  I suppose it's possible that the upgrade to OS6.10.x used enough additional memory that everything slowed down.  Do you have any apps running?  Disabling them might help.

[DoctorBrown]

---

@Sandshark wrote:.....  I suppose it's possible that the upgrade to OS6.10.x used enough additional memory that everything slowed down.  Do you have any apps running?  Disabling them might help.

---

Thanks for replying. That's what I'm considering about the upgrade. The system does seem CPU limited. And no, I don't have any apps running. The confounding thing is I'm chatting with someone in another thread that has the exact same CPU and Upgrade and he's getting 70MB/s.

[StephenB]

---

@Sandshark wrote:

Your NAS is slow because the 100 series are the least capable OS6 based ReadyNAS. 

Sure, but @DoctorBrown's NAS is much slower than my RN102, so there is something going on.

I am wondering if enabling flow control in the pc (and the switches if they have that option) would help.  It's possible that packet overruns in the NAS might be part of the puzzle.

Also, I have jumbo frames disabled on my network, so that might also be part of the puzzle.

[DoctorBrown]

I have more data. I ssh'd into the system and ran htop to monitor the CPU and Memory usage. Here's the data

All these test were done using a 1 GB file.
                    MBps    CPU usage    
Disk to Disk w/cp:   64.9   >90% Kernel

From my Windows 10 System using IPv4, jumbo frames off:
iPerf3:             115.0   >95% Kernel
Win Explorer:        14.7   ~75% Normal, ~20% kernel
Win cmd copy:        14.7   ~75% Normal, ~20% kernel
Win cmd SCP           4.9   ~60% Normal, ~45% kernel

Memory usage in all test was <30%

 What seems to be happening is the CPU is maxed out. Clearly the system can handle the 1 GB network or the disk throughput, but adding them together pushes it over the edge. Are there other hardware parms I can check?

---

 Why @StephenB is able to get much higher throughput on the same CPU is a mystery to me. Would you be able to measure any of this on your system. I'm sure it would be enlightening.

[StephenB]

---

@DoctorBrown wrote:

 Why @StephenB is able to get much higher throughput on the same CPU is a mystery to me. Would you be able to measure any of this on your system. I'm sure it would be enlightening.

---

It might take a couple days to get to it.

---

@DoctorBrown wrote:

Are there other hardware parms I can check?

---

I am thinking it would be good to see the network stats, to see if there are a lot of packet drops (overruns) during the transfer tests.  Running ifconfig before and after the test would let you see that.

If there are, then testing with ethernet flow control enabled on the windows machine and switches would be useful.  

[DoctorBrown]

---

@StephenB wrote:

I am thinking it would be good to see the network stats, to see if there are a lot of packet drops (overruns) during the transfer tests.  Running ifconfig before and after the test would let you see that.

I ran a Wireshark trace on the computer side while running a file transfer and iPerf3 and didn't see any tcp errors or other anomalies. After a 1GB file transfer, the ifconfig dropped packet count went from 8604 to 8691 out of 17+ Million packets (since the interface up time). There are 0 overruns. ifconfig:

#ifconfig
eth0      Link encap:Ethernet  HWaddr 28:c6:8e:xx:xx:xx
          inet addr:192.168.xxx.xxx  Bcast:192.168.xxx.xxx  Mask:255.255.255.0
          inet6 addr: 2601:xxxx:xxxx:xxxx:xxxx::xxxx:xxxx/64 Scope:Global
          inet6 addr: fe80::xxxx:xxxx:xxxx:xxxx/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1518  Metric:1
          RX packets:17570276 errors:1 dropped:8691 overruns:0 frame:0
          TX packets:883974 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:532
          RX bytes:25854686421 (24.0 GiB)  TX bytes:104586322 (99.7 MiB)
          Interrupt:26

---

@StephenB wrote:

It might take a couple days to get to it.

No problem if it takes a few days, I appreciate all you've done.

[StephenB]

---

@DoctorBrown wrote:
;UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1518 Metric:1

---

One difference here, as my system is set to use the default 1500 byte MTU.  

Another thing I didn't mention - I disable ipv6 on my ReadyNAS.  If you aren't, that might be worth a quick test.  Some years ago there were scenarios where Windows would end up using an ipv6 link-local address to connect with the NAS, even if ipv6 wasn't enabled in the router. That did reduce performance at the time.

[DoctorBrown]

---

@StephenB wrote:One difference here, as my system is set to use the default 1500 byte MTU.  

Another thing I didn't mention - I disable ipv6 on my ReadyNAS.  If you aren't, that might be worth a quick test. 

---

Yup, tried them both, same result. I even disabled IPv6 on my computer. I also tried running IPv6 alone. Again no dice.