RN214 - Extremely slow with zip files

---

Zurd wrote:

 

You suggested that I disabled the bond so I did. I also removed one ethernet cable, so now I only have one ethernet cable plugged and here is the result with a 312.8 MB zipped file with 766 folders and 5517 files inside:

The net here is that with bonding disabled we are getting similar results. That's assuming all your tests are extraction tests.  You could use -t to see how all the clocks compare.

One potential problem with round-robin bonding is that when you are going from 2 gbps->1gbps you create congestion (because the NAS can put data on the wire twice as fast as the client can accept it).  At some point the switch ends up dropping packets, because its buffers overun.  TCP congestion control then kicks in.  TCP congestion control is designed to back off the send rate sharply when packets are lost - to prevent the possibility of a network collapse.  So in this particular scenario, you end up underutilizing the network capacity.

You might want to check if you have ethernet flow control enabled in the switch (often it is not on by default).  If you enable that, you could try re-establishing the bond.

---

Zurd wrote:

 

No 7zip in command line is not restrictive, I can output or zip with a command from and to a NAS, I've done it plenty of times on different computers, no idea what problem you're having but it should work.

The problem I ran into is that -o lets me extract to a different folder, but it is ignored when zipping (at least in windows).  No matter what I typed, the zip file was created in the folder I was zipping (not in the folder I was in).  So I could have extracted NAS->SSD, but I couldn't zip NAS->SSD. This was in windows.  I didn't spend a lot of time fiddling with it, as I normally don't use the 7za command line.  In any event, you can see the commands I actually tested, as they were included with my results.  

---

Zurd wrote:

So it is faster right now but I still think something is wrong, it should be faster. In your test of extraction (which are different tests that I did) from SSD to SSD (12s) compared to NAS to NAS (80 seconds), it is 667% slower, huge difference.

---

This difference appears to be latency (you can see the huge gap between process times and global time in my slow extraction). 

So at the time I chalked that up to SMB.  Extraction presents a very different load from zipping (reading one large file -> writing lots of small files vs. reading lots of small files -> writing one large file).  

I'd expected that disabling strict sync would help on that particular test.  But you didn't find that, which is interesting. My suspicion is that SSD tiering on the NAS would fix it - something I've thought about using, but haven't gotten around to trying. 

If I get to it, I might try a NAS->SSD extraction test.

---

Zurd wrote:

Because of this, I think it's a good thing to not have it [strict sync] enabled. If you install Samba, it is not enabled by default. I wonder why Netgear would turn it on by default.

 

---

For one thing, most NAS users aren't using linux clients. FWIW I think the Samba documentation might be over-touting "unix reliability". While my Windows systems often did crash many years back, I haven't found that to be the case with Windows 7 or Windows 10.

I suspect Netgear is prioritizing data safety over performance. With the setting disabled, more writes are cached in the NAS.  If the power on the NAS fails (or if it crashes) those writes are lost.  That can increase the odds that the RAID array will be out-of-sync (resulting in a corrupted file system or a RAID array that can't be mounted).   If the NAS is UPS protected, then you probably can safely disable it.