RT-AC86U Samba freezes during transfer

[dantekb43]

Hi everyone,

I have an external SATA SSD plugged into the USB 3.0 Port on my RT-AC86U running Merlin 386.1 beta.

When I try to transfer data through any protocol (tried Samba, NFS, FTP), there appears to be this strange behavior where the transfer starts full speed (~ 100MB/s, gigabit ethernet to my Windows PC) then 1-2 seconds later the transfer "freezes" for like 10-20 seconds, and then it wakes up again continuing the transfer.
In the end, its like ~100MBs for 2-3 seconds, then 0 MB/s for 10-20 seconds, rinse and repeat until the file is transferred.

As you can see from the screenshot, one core usually stays at 100%, and RAM usage sits at 94% on the WebGUI when the transfer happens (usually it stays on 100-150 MB free)
The weird thing is, analyzing through "htop" via ssh, when the freezing happens, the CPU shows both cores at 0% on htop.

And yes, the SSD works normally, i was using it mounted on a raspberry pi 4 on my network, could transfer files through SMB normally on the pi.

Things that I've tried to fix this:

• Rolling back to 384.19 stable, same behavior
• I had Diversion and Unbound installed and running, stopped and removed those, same behavior
• Full factory reset, with nothing else configured besides the SMB protocol, same behavior
• Tried other protocols (SMB,NFS,FTP, even the DLNA media server), same behavior

Thanks for the help in advance

 

[rlj2]

sure your note dealing with buffer on your ssd? normally a transfer will start super high, then gradually start dropping down. Try to check what the average copy of a large file is.

 

[dantekb43]

sure your note dealing with buffer on your ssd? normally a transfer will start super high, then gradually start dropping down. Try to check what the average copy of a large file is.

Thanks for the quick reply, but I'm pretty sure that it isn't. With a 4GB file, a transfer like that would take 40-60 seconds, it takes more than 10 min, with this constant freeze-go-freeze-go behavior.
The drive can take 100MB/s on gigabit ethernet, because as i said, i was using the same drive on a raspberry pi 4 with no issues (the drive is ext4 formatted to be more specific).

I was expecting lower speeds overall because the pi has a faster CPU/RAM than a router, but nowhere near this behavior, i don't believe that this is normal, 512MB of RAM should be more than enough for file transfers, even through non-TLS FTP.
Keep in mind that, when the freeze happens, the drive "locks up", i can't access anything else on it, or watch content through DLNA.

I also though it could've been the swap being on the same drive, but nope, removed the swap file and i still have same behavior.

 

[Draken]

Funnily I was troubleshooting exactly the opposite issue. I am absolutely fine on an ssd on the router but I have the above behaviour when copying from the Raspberry pi.

I have just downloaded FileZilla and the transfer seems to be doing OK using it, so my guess would be that it is a protocol/config (?) issue of some kind, but I would be very curious if anyone can answer the question.

 

[ColinTaylor]

Try using the USB 2 socket and seeing if you get more consistent transfer speeds.

 

[Draken]

Try using the USB 2 socket and seeing if you get more consistent transfer speeds.

I wasnt expecting it and hence I havent tried it myself but it seems to have worked in my case. Speed is lower but much more stable now. Many thanks.

 

[L&LD]

If you're into more drastic measures, you may want to see if you can Secure Erase the SSD.

That behavior looks like the drive is doing internal maintenance for whatever reason. Instead of a Secure Erase, maybe even a full (Quick) format on a Windows PC running Windows 7 or higher is all it needs?

Testing TRIM - The SSD Improv: Intel & Indilinx get TRIM, Kingston Brings Intel Down to $115 (anandtech.com)

Now look at the two runs if we format the drive in between. The format under Windows 7 triggers a TRIM of all invalid data, meaning all the jibberish we generated in the first run is gone and the second run now runs at full speed:

 

[dannno]

I'm having the same exact issue with my RT-AX86U that I just bought today.

I didn't test with the stock firmware, but it seems that when writing to any USB storage, the ram usage maxes out and doesn't ever come back down.

I initially thought it was because my external drive was formatted NTFS, so I tried with a 16gb USB3 thumb drive. I formatted it EXT4 with AMTM, and when I created the 2gb swap file the RAM usage went to 97% and still hasn't come down after about 5 minutes. I've tried both USB ports too to try and rule things out. SAMBA file transfers cause the same issue.

Router: RT-AX86U
Build: 386.1_beta2
USB Drive 1: Sandisk Cruzer 16gb USB3.0
USB Drive 2: Sandisk SSD Plus 256gb in generic USB3->SATA adapter

Edit: Did some testing and it seems like its Cache that is filling up? This was a 1.5gb ISO transfer that went from 110mb/s to 335kb/s and froze. i canceled it and it sat for a few minutes before this screenshot.

 

[thecheapseats]

<snip>I was expecting lower speeds overall because the pi has a faster CPU/RAM than a router, but nowhere near this behavior<snip>, i don't believe that this is normal, 512MB of RAM should be more than enough for file transfers, even through non-TLS FTP.
Keep in mind that, when the freeze happens, the drive "locks up", i can't access anything else on it, or watch content through DLNA.

I also though it could've been the swap being on the same drive, but nope, removed the swap file and i still have same behavior.

what's the chipset mfg in the usb-to-sata cable/device?... I'd assume it's a good to go if raspi xfrs fast... but do check lsusb on the raspi for chipset if unknown to you as well as xfr speed using the cli... raspi xfrs can buffer starve to disk if your chipset is optimal/fast... if it's slowing/locking on the router - smells like chipset issues...

 

[thecheapseats]

<snip>Funnily I was troubleshooting exactly the opposite issue. I am absolutely fine on an ssd on the router but I have the above behaviour when copying from the Raspberry pi.<snip>

chipset brand in the usb-to-sata cable/enclosure?...