Comment on page
Upload and Download speeds cannot be guaranteed on the cloud platform due to many external contributing factors.
- 2.If your site is hosted in another cloud platform, use their speed test instead.
- 1.A bad ethernet cable can cause intermittent packet loss.
- 2.Interference in the 2.4 and 5ghz spectrum will impact wi-fi signal, 4G, 5G, etc.
- 1.This could be from other wi-fi routers on the same channel, microwave ovens, cordless phones, sunspots, etc.
- 3.An overloaded, underrated, or misconfigured network switch can limit throughput.
- 4.Going through a proxy server or web filter (i.e. imposed by corporate IT) is not supported.Try using a VPN service to bypass it.
- 1.Routing configuration errors or hardware failure at the ISP and beyond
- 2.From time to time, international deep sea cables are damaged by ships, sharks, etc, causing packets to have to take a detour through a slower path until repairs are made
- 1.If inside the continental US this will not be an issue for you
- 3.Denial of service attacks on one or more hosts between client and server
- 1.Round-Trip Time (RTT): Describes the length of time in milliseconds for a packet to make a round trip from user, to server, and back again
- 3.Is often impacted by the total number of hops to the server
- 1.You can run a trace route from the command prompt:
tracert <server address>or terminal/shell:
traceroute <server address>Some firewall admins will block ICMP, which the trace route depends on. Ask them to whitelist your server address if able.In the trace route results you may see a line like this:
* * * (request timed out)for some hops along the way. It means the host is not accepting ICMP traffic. While unhelpful, it does not indicate an issue necessarily.
Maximum TCP Window
64 Kilobytes is the largest chunk most operating systems will work with. For the throughput calculation you can leave "WIN" the default 64K.
- 2.Unit conversion may be necessary depending on how your client represents data (e.g. Megabits to MegaBytes or even Mebibytes 😱)
Peak Times & The Road Less Traveled
We have observed certain periods of high traffic that recur on a daily basis. During these times you may encounter reduced transfer speeds or transient errors (403/503). Connection speeds are not actively throttled but it's a shared resource. If your use case demands a dedicated resource speak to your sales representative about hosted on-prems.
8-9AM ET is our peak usage period for human users. We estimate this is due to reading an email at the top of the business day and needing to send or receive files as a result.
Automation users tend to be scheduled to connect at the top of every hour
:00and every 10 or 15 minutes thereafter. Shifting by a few minutes and/or seconds can make a huge difference.
Start jobs at unique times for best results on the cloud platform. E.g. 1:07, 3:58, 7:43, 11:11You could even begin your script with a
wait(30)to avoid connecting at the top of the minute.Robust automations use a
try...catchloop to handle transient errors and reconnect after 90 seconds to reduce manual interventions.
Contact Technical Support