S3 Plus slow: will not upload faster than 1mbps

[BinofYumenes]

We are using a QNAP TS-453A, connected via a single ethernet cable to a gigabit switch, on an internet connection with a 25mbps upload speed (periodically tested and quite reliably the case).

Whatever we do, we can't seem to get S3 Plus to upload at higher speeds than 1mbps. When I check the "recent transfer rate" in the job status it invariably tops out in the 95-100KBps range.

I checked the rate limit screen and there's no difference with it enabled or disabled. I can make it upload even slower by setting the rate limit to something like 10KBps, but I can't get it above 100KBps ever.

Our initial S3 Plus backup of 600GB has been running nonstop since May and it's only 25% done today (almost October).

During this time, I used rsync from the CLI of the very same QNAP NAS to copy the entire 600GB volume to a remote location and it took about 4 days start to finish.

I've also uploaded files directly to S3 using s3cmd from another machine in the same office (connected to the same switch) and got near full speed.

The facts: The NAS is not heavily loaded, it can send files within the office at close to 1gbps, the office internet connection can upload to S3 at 25mbps, and the NAS itself can upload across the internet at 25mbps. It just won't do it in S3 Plus.

Therefore, the bottleneck truly seems to be in the S3 Plus software.

What do do? The estimated completion time of the backup is well into 2018. That's not reasonable for data that I know for a fact can be transmitted in under four days. Do we abandon S3 plus or is there a solution that makes it usable?

[Toxic17]

have you tried replacing the LAN cable, just in case its is faulty? are there any crc errors listed on the LAN interface?

ssh into your NAS

type:

[~] # ifconfig

you should see an output, please post your findings. you can mask the IP if you want...

[Toxic17]

Also

[~] # ethtool eth0

[~] # ethtool eth1

[BinofYumenes]

I don't think it's the cable, as I was able to rsync the entire contents of the volume in one go without delays - four days of sustained traffic. It's on a new 1m cat6 cable directly to the switch. And we do not observe any day-to-day slowdowns with local access (via SMB). Before posting I tried again and had no trouble saturating the external link with scp copies in both directions between the NAS and a remote server. Meanwhile S3 Plus keeps doddering along at 95KBps.

ifconfig:

Code: Select all

bond0     Link encap:Ethernet  HWaddr 32:F2:51:XX:XX:XX  
          UP BROADCAST NOTRAILERS MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:08:9B:XX:XX:XX  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:639354151 errors:0 dropped:4 overruns:3930 frame:0
          TX packets:926036471 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:241318056788 (224.7 GiB)  TX bytes:1099732219848 (1.0 TiB)
          Memory:81800000-8187ffff 

eth1      Link encap:Ethernet  HWaddr 00:08:9B:XX:XX:XX  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:81900000-8197ffff 

eth2      Link encap:Ethernet  HWaddr 00:08:9B:XX:XX:XX  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:81600000-8167ffff 

eth3      Link encap:Ethernet  HWaddr 00:08:9B:XX:XX:XX  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:81700000-8177ffff 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:8570173 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8570173 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4496764966 (4.1 GiB)  TX bytes:4496764966 (4.1 GiB)

ethtool (eth0 only; we don't have anything plugged into eth1):

Code: Select all

Settings for eth0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: off (auto)
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: yes

[Toxic17]

looks good, any VPN's to the NAS, just wondering if the data to s3 is being routed another way.

try a traceroute on your NAS to the s3 servers

[BinofYumenes]

Nope, no VPN, it goes straight through. Here's a traceroute from the NAS, it looks about the same as if I do it from a desktop on the same office network:

Code: Select all

# traceroute 52.216.81.112
traceroute to 52.216.81.112 (52.216.81.112), 30 hops max, 46 byte packets
 1  router (192.168.1.1)  0.231 ms  0.161 ms  0.140 ms
 2  xe-3-1-2-sur03.michiaganave.dc.bad.comcast.net (68.85.147.53)  8.545 ms  10.429 ms  5.817 ms
 3  ae-5-0-ar01.capitolhghts.md.bad.comcast.net (68.86.204.205)  10.104 ms  18.569 ms  17.452 ms
 4  ae13-ar01.capitolhghts.md.bad.comcast.net (68.87.168.61)  10.066 ms  9.918 ms  8.437 ms
 5  be-33657-cr02.ashburn.va.ibone.comcast.net (68.86.90.57)  14.305 ms  16.196 ms  12.931 ms
 6  hu-0-11-0-5-pe07.ashburn.va.ibone.comcast.net (68.86.85.102)  10.991 ms  8.561 ms  8.846 ms
 7  as16509-5-c.ashburn.va.ibone.comcast.net (50.242.148.66)  8.680 ms  13.423 ms  12.771 ms
 8  54.239.108.138 (54.239.108.138)  49.731 ms  54.239.108.140 (54.239.108.140)  19.008 ms  54.239.108.38 (54.239.108.38)  25.151 ms
 9  54.239.111.41 (54.239.111.41)  11.100 ms  54.239.108.235 (54.239.108.235)  11.553 ms  54.239.111.45 (54.239.111.45)  15.408 ms
10  205.251.245.250 (205.251.245.250)  11.559 ms  205.251.244.205 (205.251.244.205)  13.629 ms  205.251.244.207 (205.251.244.207)  11.412 ms
11  *  *  *
12  *  *  *
13  *  *  *
14  *  *  *
15  *  *  *
16  *  *  *
17  s3-1-w.amazonaws.com (52.216.81.112)  10.512 ms  9.974 ms  11.441 ms

Pings are sweet and steady at 10ms; I let it go for five minutes and got zero lost packets.

[seamanjeff]

Was there ever any resolution to this?

[jk_atx]

Same issue.