From Apis Networks Wiki

Account Bandwidth

How much is additional bandwidth?

Additional bandwidth is calculated as <package price at monthly rate>/<bandwidth in package> * 45% = cost per additional GB. For example, at the Minimalist level, which is $4.95 per month with 10 GB of bandwidth, each additional GB of bandwidth is $4.95/10 GB * 45% = $0.223/GB. To purchase additional bandwidth file a ticket from within the control panel.

Will my site be cut off after exceeding my bandwidth limit?

No, your site will be not terminated once it has exceeded its bandwidth allocation; however, you will receive notices nightly informing you that your site has gone over its limit. First time offenses are waived, but you are strongly urged to either upgrade packages or just upgrade bandwidth. Subsequent gross violations (in excess of more than 10%) will be fined $0.75 per GB. Gross violations in excess of 200% of a site's bandwidth capacity will be suspended after 200% capacity. Extraneous circumstances are waived.

For example, if a site has a 10 GB quota and goes over by 2.5 GB during the first month it will be waived (125% usage). On the following month if the site once again pushes 12.5 GB of bandwidth, then it will be fined $0.75*3 GB = $2.25 for that billing cycle. Finally, on the third month, if the site pushes 20 GB before the end of its cycle (200% usage), then the site will be suspended until bandwidth is upgraded for the site.

Special Considerations for Digg/Slashdot/High Volume Sites

If you are anticipating or experience a high volume of inbound traffic through a link aggregate site, such as Digg, Slashdot, or Reddit, we ask that you please file a ticket in the control panel to prevent bandwidth overage charges. We will waive all bandwidth during the cycle if your site is featured prominently on any of the sites. We also ask that you make a link back to us and our special software, adaptive service monitor in exchange for the bandwidth waive.

When does bandwidth cycle?

Your cycle begins on the day of the month on which your account was setup. This can be determined through the Site Summary section of the control panel.

Network Information

Our network piggybacks off AtlantaNAP in Gnax's facility located at 1100 White St. SW Atlanta, GA 30310. All of our servers are located on Gnax's gold network, making liberal use of Avaya RouteScience (now CNA) on top of BGP to constantly reroute traffic to the optimal path. There are 2 border routers on the network. We receive feeds from the following 1 Gbps trunks:

• Level 3
• PCCWBTN
• Qwest
• Savvis
• Spring
• Telia

Bandwidth graphs are available from Gnax's site.

Problems

High latency/site inaccessibility

Please bear in mind that the majority of network interference controllable by us we are aware of and likely waiting for a response from the data center. All services are internally monitored, so be sure to check your network connectivity through this section before filing a ticket.

Network traffic between the server and a user's computer go through multiple routers, each of these routers is called a hop. A hop aggregates traffic and sends it to its next destination; hops are the main cause of high latency to the server. A traceroute allows you to see the traffic as it originates from your computer and goes to the server. A troubled hop is one that is either (a) completely inaccessible (no packets make it through), (b) limited accessibility such that on a handful of the packets go through while the others are dropped, or (c) packets go through; however, the high latency makes it extremely difficult to receive a response (> 500 ms)

On Windows go to Start -> Run -> tracert 64.22.68.1

On Linux/Mac type in traceroute 64.22.68.1

64.22.68.1 is the address of our switch in the data center. The last hop past 64.22.68.1 is your server; however, we strongly discourage replacing 64.22.68.1 with your domain name due to possible DNS issues.

A healthy traceroute would look similar to this (reformatted for easy reading),

traceroute to 64.22.68.1 (64.22.68.1), 30 hops max, 38 byte packets
 1  192.168.0.1     0.695 ms    0.636 ms    0.622 ms
 2  24.99.54.1      5.889 ms    9.225 ms    9.167 ms
 3  68.86.110.221   8.160 ms    9.329 ms    7.048 ms
 4  68.86.106.29   13.899 ms   16.385 ms    8.450 ms
 5  68.86.106.25    7.917 ms    9.549 ms   17.326 ms
 6  68.86.106.21    7.880 ms    7.857 ms   11.350 ms
 7  68.86.90.126    8.743 ms   22.408 ms   15.862 ms
 8  68.86.90.125   17.250 ms   10.003 ms   20.443 ms
 9  68.86.85.169   31.393 ms   30.331 ms   28.739 ms
10  68.86.89.58   191.994 ms  250.664 ms  220.224 ms
11  63.216.31.130  44.880 ms   43.011 ms   41.911 ms
12  63.247.69.177  41.994 ms   43.158 ms   51.172 ms
13  209.51.131.74  44.000 ms     *         42.946 ms

Note the second ping response time of * in the last hop. This is intentional and caused by the MLPS uplink.

An unhealthy or problematic network may resemble something significantly different. Below are three common scenarios. Depending upon the point of congestion we may or may not be able to assist you. First, look at the hostnames. Anything ending in .gnax.net is addressable by the data center. For example, any hop after the following border router would be fixable,

6     500 ms     750 ms     900 ms  gige-AIX.gnax.net [198.32.132.26]

On the other hand, if the problematic hop resembled a similar output as the following, your ISP or one of its peers would need to fix it. In most cases, these problems are widespread enough to likely be acknowledged by the ISP

 
 5  te-9-4-ur01.a5atlanta.ga.atlanta.comcast.net (68.86.106.25)  15.518 ms  7.628 ms  6.560 ms
 6  te-9-4-ur01.a6atlanta.ga.atlanta.comcast.net (68.86.106.21)    *         *        7.872 ms

traceroute to 64.22.68.1 (64.22.68.1), 30 hops max, 38 byte packets
 1  192.168.0.1     0.695 ms    0.636 ms    0.622 ms
 2  24.99.54.1      5.889 ms    9.225 ms    9.167 ms
 3  68.86.110.221   8.160 ms    9.329 ms    7.048 ms
 4  68.86.106.29   13.899 ms   16.385 ms    8.450 ms
 5  68.86.106.25    7.917 ms    9.549 ms   17.326 ms
 6  68.86.106.21    7.880 ms    7.857 ms   11.350 ms
 7  68.86.90.126    8.743 ms   22.408 ms   15.862 ms
 8  68.86.90.125   17.250 ms   10.003 ms   20.443 ms
 9  68.86.85.169   31.393 ms   30.331 ms   28.739 ms
10  68.86.89.58   491.994 ms  591.664 ms  800.224 ms
...

traceroute to 64.22.68.1 (64.22.68.1), 30 hops max, 38 byte packets
 1  192.168.0.1     0.695 ms    0.636 ms    0.622 ms
 2  24.99.54.1      5.889 ms    9.225 ms    9.167 ms
 3  68.86.110.221   8.160 ms    9.329 ms    7.048 ms
 4  68.86.106.29   13.899 ms   16.385 ms    8.450 ms
 5  68.86.106.25    7.917 ms    9.549 ms   17.326 ms
 6  68.86.106.21    7.880 ms    7.857 ms   11.350 ms
 7  68.86.90.126    8.743 ms   22.408 ms   15.862 ms
 8  68.86.90.125   17.250 ms   10.003 ms   20.443 ms
 9  68.86.90.126    8.743 ms   22.408 ms   15.862 ms
10  68.86.90.125   17.250 ms   10.003 ms   20.443 ms
11  68.86.90.126    8.743 ms   22.408 ms   15.862 ms
12  68.86.90.125   17.250 ms   10.003 ms   20.443 ms

traceroute to 64.22.68.1 (64.22.68.1), 30 hops max, 38 byte packets
 1  192.168.0.1     0.695 ms    0.636 ms    0.622 ms
 2  24.99.54.1      5.889 ms    9.225 ms    9.167 ms
 3  68.86.110.221   8.160 ms    9.329 ms    7.048 ms
 4  68.86.106.29   13.899 ms   16.385 ms    8.450 ms
 5  68.86.106.25    7.917 ms    9.549 ms   17.326 ms
 6  68.86.106.21    7.880 ms    7.857 ms   11.350 ms
 7  68.86.90.126    8.743 ms   22.408 ms   15.862 ms 
 8  * * *
 9  * * *
10  * * *
 

Note that dropped packets denoted by a * response time are not always indicative of network problems. Some routers drop ICMP packets, which are used to determine ping.