6.7.0 / 6.7.1 beta : change of the MTU freeze the system after seconds
I cannot change MTU of the active network card, after a few seconds the system will freeze. If I connect the Ethernet cable to the second interface and change the MTU to the first (now inactive), I can go back to the first after a reboot and the new MTU is activ. (I used jumbo frames, 9000)
Re: 6.7.0 / 6.7.1 beta : change of the MTU freeze the system after seconds
I ran into something similar .. when I changed the MTU to 9198 (to match the XS716 switch) on an LACP Bonded 10G .. on the 628x - the NIC lights on the NAS when off /disconnected.. and I had to reboot it.. I reported this to tech support , they said the max MTU was 9016 but to use 9000 - when I set it to 9000 it set with no problems... they said they would open a bug on this firmware 6.7.1-T252 on this & would prevent customers entering a value higher then what is supported.
I know this is not exactly the same issue you have.. but when they fix the bug, regression testing might catch your issue.. have you tested with the latest T252 firmware?
Model: RN628X|ReadyNAS 628X - Ultimate Performance Business Data Storage - 8-Bay
Re: 6.7.0 / 6.7.1 beta : change of the MTU freeze the system after seconds
The problem is the changing of the MTU, the NAS freezes as soon as the modified MTU value is set via the GUI. The max size of the MTU is not the problem, they should not change.
I have set now a MTU of 9200 on RN104 . The USB3 NIC of the laptop, the switch (Netgear GS108Ev2) and the RN104 works fine with this. But you can not change the MTU from GUI. Even if you set it to 4000 by the GUI, it freezes. But there is the Workaround using the other Ethernet port.
Re: 6.7.0 / 6.7.1 beta : change of the MTU freeze the system after seconds
6.7.1 has been officially released in the meantime. You could try installing it to see whether there is an improvement. However, you need to manually install it, as it is not on the update server currently (To get it from there you might need to wait for a few more days).
Here is a link to the release notes (on that page there is also a link to download the fw):
For manual installation on your nas go to the admin webpage /system/settings and in the section "update" hit the button "install firmware". Then follow the dialog to locate the fw on your workstation and get it installed.
Re: 6.7.0 / 6.7.1 beta : change of the MTU freeze the system after seconds
@Retired_Member wrote:
For manual installation on your nas go to the admin webpage /system/settings and in the section "update" hit the button "install firmware". Then follow the dialog to locate the fw on your workstation and get it installed.
Re: 6.7.0 / 6.7.1 beta : change of the MTU freeze the system after seconds
Honestly, on an RN104, there is no point using Jumbo Frames. The performance of the NAS is bottlenecked by the CPU anyway.
Supposing that you could benchmark and prove that there is a performance difference between Jumbo Frames and no Jumbo Frames on an RN104, it would be so small and unnoticeable that the pain of getting it to work, the increased unreliability, would make it not worth bothering trying.
Imho, it should work, but it's not worth the effort of trying to get it to work if it doesn't straight away.
Re: 6.7.0 / 6.7.1 beta : change of the MTU freeze the system after seconds
Well, it looks like you currently are running beta software. With ANY kind of issue related to that and the official release finally delivered, to my understanding one should not hesitate to replace the beta with the official release to avoid any casualties.
Re: 6.7.0 / 6.7.1 beta : change of the MTU freeze the system after seconds
StephenB wrote: "(A) Who are you responding to, and (B) where did you get that info?"
@A: Default addressee in a thread like this is the topic owner and I do not need to explicitely mention that in a new response. @B: The subject of the thread is "6.7.0 / 6.7.1 beta : change of the MTU freeze the system after seconds". This is giving me a strong enough hint to assume, that at the time GH was creating this topic 6.7.1 beta was the current fw on the concerned nas.
Re: 6.7.1 : change of the MTU freeze the system after seconds
I installed version 6.7.1 final and changed the MTU again. The Rn104 freezes immediately, an error message appears on the LCD. After that, I could only reboot via power off / on.
Can anybody else check, it’s very easy to reproduce, simply change MTU setting.
I often copy larger image files and the difference is clear.
Certainly iPerf will give higher speeds. That won't necessarily translate to SMB.
But JF improves performance because it reduces the packets-per-second processing load on the client devices - it doesn't improve the network speed itself. So I'd actually expect JF to make more of a difference on an low-end NAS like the RN100 series than it would on a high-end NAS with a fast CPU.
BTW, one reason for requesting the retest - in my experience Netgear development is far more likely to engage when you find a problem with the current firmware.
Re: 6.7.1 : change of the MTU freeze the system after seconds
Real life numbers have sense. So storage benchmarking and actual file transfer with and without Jumbo Frame.
On an RN104, the throughput is low enough for that 5% theoretical improvement to make a difference in throughput of, at most, several hundred KB/s. Still not worth the effort imho.
On most networks that has almost nothing to do with the speed up (although many articles in the press don't get this).
When you increase the MTU by 6x, the NAS (and PC) are processing 1/6 the number of packets to read or write the same file. That significantly reduces the interrupt rate and per-packet processing overhead in the CPUs. In linux, the rate of kernel/user mode context switches drops.
The CPU benefit was pointed in an old analysis by Alteon (who invented jumbo frames back in the day), backed up with measurements. And it's still the main benefit with slower CPUs. As you saw in the post above, the result with iPerf on the RN100 was that throughput doubled - much more than reduction in link overhead.
If processing can be off-loaded to the NIC hardware, and you enable some other off-loading features (interupt moderation for instance) the CPU performance benefit often largely evaporates. It does depend on how well optimized the NIC driver is - sometimes enabling those features makes throughput worse. Of course if you have a fast CPU in the first place, the throughput benefit is much less.
The impact with SMB will be less than iperf, because the CPU is also busy managing the disks, and that part of the load doesn't depend on the network MTU.
As far as the network itself goes, larger MTUs reduce overhead (as shown in your reference), and can reduce or eliminate packet fragmentation in some applications.
On the negative side, larger MTUs increase latency and jitter, which is a drawback when VOIP and other real-time applications are running on the same network path. Larger packets require more buffering in switches (and also in the client devices). I don't think the cost of that memory matters much - it's more about the latency/jitter that the buffering adds. I've seen an analysis that sizes the memory increase in a 24 port switch at about 3 MB.
As a practical matter, managing MTUs can be a pain, and that matters because MTU discovery often fails. Everything needs to be gigabit, and you are limited to the smallest MTU across all your devices. I don't find that to be worth the hassle - but I get 100MB+ speeds with my x86 NAS without jumbo frames.
Re: 6.7.0 / 6.7.1 beta : change of the MTU freeze the system after seconds
I hear you. But I still think that transfer times won't be very different. Of course, I can be wrong. If OP was able to test Jumbo Frames with iPerf, then next step is to test Jumbo Frames with actual data transfer. That discussion is about the point of using it, but I feel like disturbing the actual purpose of the thread: If the NAS freezes when changing the MTU, that's a bug. It should be looked at by NETGEAR.
If the NAS freezes when changing the MTU, that's a bug. It should be looked at by NETGEAR.
I think the OP still needs to confirm that it happens with the 6.7.1 production version. That should be easy to check, as this doesn't seem to be intermittent.
I suggest PMing @mdgm-ntgr, reporting the bug and requesting that Netgear investigate. It's reasonable to ask if they can reproduce it on their systems. Include a link to the first post, and also a link to the 6.7.1 production post. That skips over the digressions on the pros and cons of JF.
Clicking on the three dots in the upper right of the post and choosing "highlight" is the easiest way to get a direct link to a post in the middle of a thread. Then copy/paste the browser's address bar.
