Every night, 6-10pm downloads from Github become impossible (Fibre)

B

Blackhand

Expert Member
Joined
Dec 22, 2004
Messages
1,313
Reaction score
1,541
Every night I have some sort of issue between 6-10pm, but the most pressing one is that downloads from Github releases fail.

Example: https://github.com/ufoscout/docker-compose-wait/releases/download/2.3.0/wait (582 kb)
Basically a download from AWS S3.
The download will either stall or download extremely slowly (1h+).

This is not an issue during daytime hours and slowly resolves itself after 10pm. I can confirm by remoting into another machine at work or using LTE that the issue is not with Github or S3.

During these hours there are other random issues as well. In particular EU World of Warcraft latency and packet loss becomes erratic.

Most things in general do work fine however, such as streaming from Netflix and general browsing. Speedtests also fly.

Interestingly enough:
Code: 
ping www.mybroadband.co.za -t

Pinging www.mybroadband.co.za [104.20.9.169] with 32 bytes of data:
Reply from 104.20.9.169: bytes=32 time=5ms TTL=59
Reply from 104.20.9.169: bytes=32 time=2ms TTL=59
Reply from 104.20.9.169: bytes=32 time=3ms TTL=59
Reply from 104.20.9.169: bytes=32 time=4ms TTL=59
Reply from 104.20.9.169: bytes=32 time=4ms TTL=59
Reply from 104.20.9.169: bytes=32 time=4ms TTL=59
Reply from 104.20.9.169: bytes=32 time=2ms TTL=59
Reply from 104.20.9.169: bytes=32 time=3ms TTL=59
Reply from 104.20.9.169: bytes=32 time=4ms TTL=59
Reply from 104.20.9.169: bytes=32 time=4ms TTL=59
Reply from 104.20.9.169: bytes=32 time=5ms TTL=59
Reply from 104.20.9.169: bytes=32 time=3ms TTL=59
Reply from 104.20.9.169: bytes=32 time=3ms TTL=59

Ping statistics for 104.20.9.169:
    Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 5ms, Average = 3ms

However:
Code: 
ping www.afrihost.co.za -t

Pinging www.afrihost.co.za [169.1.1.221] with 32 bytes of data:
Reply from 169.1.1.221: bytes=32 time=83ms TTL=56
Reply from 169.1.1.221: bytes=32 time=83ms TTL=56
Request timed out.
Reply from 169.1.1.221: bytes=32 time=77ms TTL=56
Request timed out.
Reply from 169.1.1.221: bytes=32 time=109ms TTL=56
Reply from 169.1.1.221: bytes=32 time=81ms TTL=56
Request timed out.
Request timed out.
Reply from 169.1.1.221: bytes=32 time=91ms TTL=56
Reply from 169.1.1.221: bytes=32 time=78ms TTL=56
Request timed out.
Request timed out.
Reply from 169.1.1.221: bytes=32 time=87ms TTL=56
Reply from 169.1.1.221: bytes=32 time=81ms TTL=56
Request timed out.
Reply from 169.1.1.221: bytes=32 time=71ms TTL=56

Ping statistics for 169.1.1.221:
    Packets: Sent = 17, Received = 10, Lost = 7 (41% loss),
Approximate round trip times in milli-seconds:
    Minimum = 71ms, Maximum = 109ms, Average = 84ms

These ping tests were taken during the same window of problems.
That leads to me guess that something is congested or falling over during these hours.
 
Not the first time I've seen this exact same complaint on Afrifail
 
Blackhand said:
Every night I have some sort of issue between 6-10pm, but the most pressing one is that downloads from Github releases fail.

Example: https://github.com/ufoscout/docker-compose-wait/releases/download/2.3.0/wait (582 kb)
Basically a download from AWS S3.
The download will either stall or download extremely slowly (1h+).

This is not an issue during daytime hours and slowly resolves itself after 10pm. I can confirm by remoting into another machine at work or using LTE that the issue is not with Github or S3.

During these hours there are other random issues as well. In particular EU World of Warcraft latency and packet loss becomes erratic.

Most things in general do work fine however, such as streaming from Netflix and general browsing. Speedtests also fly.

Interestingly enough:
Code: 
ping www.mybroadband.co.za -t

Pinging www.mybroadband.co.za [104.20.9.169] with 32 bytes of data:
Reply from 104.20.9.169: bytes=32 time=5ms TTL=59
Reply from 104.20.9.169: bytes=32 time=2ms TTL=59
Reply from 104.20.9.169: bytes=32 time=3ms TTL=59
Reply from 104.20.9.169: bytes=32 time=4ms TTL=59
Reply from 104.20.9.169: bytes=32 time=4ms TTL=59
Reply from 104.20.9.169: bytes=32 time=4ms TTL=59
Reply from 104.20.9.169: bytes=32 time=2ms TTL=59
Reply from 104.20.9.169: bytes=32 time=3ms TTL=59
Reply from 104.20.9.169: bytes=32 time=4ms TTL=59
Reply from 104.20.9.169: bytes=32 time=4ms TTL=59
Reply from 104.20.9.169: bytes=32 time=5ms TTL=59
Reply from 104.20.9.169: bytes=32 time=3ms TTL=59
Reply from 104.20.9.169: bytes=32 time=3ms TTL=59

Ping statistics for 104.20.9.169:
    Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 5ms, Average = 3ms

However:
Code: 
ping www.afrihost.co.za -t

Pinging www.afrihost.co.za [169.1.1.221] with 32 bytes of data:
Reply from 169.1.1.221: bytes=32 time=83ms TTL=56
Reply from 169.1.1.221: bytes=32 time=83ms TTL=56
Request timed out.
Reply from 169.1.1.221: bytes=32 time=77ms TTL=56
Request timed out.
Reply from 169.1.1.221: bytes=32 time=109ms TTL=56
Reply from 169.1.1.221: bytes=32 time=81ms TTL=56
Request timed out.
Request timed out.
Reply from 169.1.1.221: bytes=32 time=91ms TTL=56
Reply from 169.1.1.221: bytes=32 time=78ms TTL=56
Request timed out.
Request timed out.
Reply from 169.1.1.221: bytes=32 time=87ms TTL=56
Reply from 169.1.1.221: bytes=32 time=81ms TTL=56
Request timed out.
Reply from 169.1.1.221: bytes=32 time=71ms TTL=56

Ping statistics for 169.1.1.221:
    Packets: Sent = 17, Received = 10, Lost = 7 (41% loss),
Approximate round trip times in milli-seconds:
    Minimum = 71ms, Maximum = 109ms, Average = 84ms

These ping tests were taken during the same window of problems.
That leads to me guess that something is congested or falling over during these hours.
Click to expand...

What sort of Fibre account do you have with us at the moment? Do you see your speedtest speeds degrade at all during this period?
 
I have the exact same issue. The files on github are served from AWS S3 in all instances that I have seen throttled.

@AfriGeni are you throttling AWS S3 based on the type of account? This happens regardless of reaching the FUP threshold of 120GB on my 10GBps account.
 
evilskaap said:
I have the exact same issue. The files on github are served from AWS S3 in all instances that I have seen throttled.

@AfriGeni are you throttling AWS S3 based on the type of account? This happens regardless of reaching the FUP threshold of 120GB on my 10GBps account.
Click to expand...

The only accounts that are actively throttled are the Home Uncapped accounts, and that will only happen if you exceed the usage threshold for that Home Uncapped account over the past 30-days. Are you only noticing the drop in speed to AWS or are there any other services that are affected? How do your speedtests look during that period?
 
AfriGenie said:
What sort of Fibre account do you have with us at the moment? Do you see your speedtest speeds degrade at all during this period?
Click to expand...

I have a Openserve Premium Uncapped account.

Edit: I have done a couple speedtests during these times and I don't see any significant speed difference. I will run more tests tonight though to confirm.
 
Last edited:
Blackhand said:
I have a Openserve Premium Uncapped account.

Edit: I have done a couple speedtests during these times and I don't see any significant speed difference. I will run more tests tonight though to confirm.
Click to expand...

Thanks. We definitely don't throttle the Premium Uncapped accounts, if it's an HTTP download it be the P2P and HTTP shaping affecting it.
 
AfriGenie said:
Thanks. We definitely don't throttle the Premium Uncapped accounts, if it's an HTTP download it be the P2P and HTTP shaping affecting it.
Click to expand...

Github is usually an https download. Can also be git(not sure why one would use this instead of https? Maybe due to no overhead so faster?) and ssh. https://gist.github.com/grawity/4392747
 
Last edited:
So testing now at 8pm and Github downloads completely stall and were working just fine earlier today. Same as usual.

Speedtests are completely normal.
Image downloads from dockerhub are working fine.
Streaming from Netflix and Youtube is working fine.
Downloads from http://cdn-fastly.deb.debian.org and http://security.debian.org have also completely tanked, I cannot complete a simple
Code: 
apt-get update && apt-get install -y unzip

As in the original post, a ping test to www.mybroadband.co.za exhibits good latency and no packet loss.
A ping test to afrihost.co.za has high latency, jitter and packet loss.

Here is a traceroute to each:

Code: 
tracert www.mybroadband.co.za

Tracing route to www.mybroadband.co.za [104.20.9.169]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  Amos [192.168.1.1]
  2     *        *        *     Request timed out.
  3     6 ms     6 ms     2 ms  cpt-rx2.ip.adsl.co.za [169.1.5.82]
  4    83 ms    81 ms    77 ms  cpt-net1.ip.adsl.co.za [169.1.5.128]
  5     4 ms     2 ms     2 ms  cloudflare.ixp.capetown [196.10.140.198]
  6     2 ms     2 ms     3 ms  104.20.9.169

Trace complete.

Code: 
tracert www.afrihost.co.za

Tracing route to www.afrihost.co.za [169.1.1.221]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  Amos [192.168.1.1]
  2     *        *        *     Request timed out.
  3     3 ms     3 ms     3 ms  cpt-rx2.ip.adsl.co.za [169.1.5.82]
  4    81 ms    80 ms    76 ms  cpt-net1.ip.adsl.co.za [169.1.5.128]
  5    87 ms    86 ms    86 ms  169-1-21-196.ip.afrihost.co.za [169.1.21.196]
  6    51 ms    49 ms    31 ms  169-1-5-75.ip.afrihost.co.za [169.1.5.75]
  7    24 ms    21 ms    23 ms  169-1-5-77.ip.afrihost.co.za [169.1.5.77]
  8    67 ms    62 ms    62 ms  luzonex.net.afrihost.co.za [169.1.1.221]

Trace complete.

Code: 
tracert github-production-release-asset-2e65be.s3.amazonaws.com

Tracing route to s3-1-w.amazonaws.com [52.216.228.168]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  Amos [192.168.1.1]
  2     *        *        *     Request timed out.
  3     6 ms     5 ms     7 ms  cpt-rx2.ip.adsl.co.za [169.1.5.82]
  4    81 ms    72 ms    67 ms  cpt-net1.ip.adsl.co.za [169.1.5.128]
  5    81 ms    71 ms    68 ms  41.164.52.40
  6    11 ms    13 ms    16 ms  ix-ae-7-0.tcore2.klt-cape-town.as6453.net [41.206.165.25]
  7   176 ms   153 ms   154 ms  if-ae-2-2.tcore1.klt-cape-town.as6453.net [41.206.164.253]
  8   155 ms   154 ms   154 ms  if-ae-5-2.tcore2.pv9-lisbon.as6453.net [80.231.159.85]
  9   151 ms   154 ms   154 ms  if-ae-2-2.tcore1.pv9-lisbon.as6453.net [80.231.158.5]
 10   155 ms   153 ms   154 ms  if-ae-1-3.tcore1.sv8-highbridge.as6453.net [80.231.158.30]
 11   149 ms   150 ms   147 ms  if-ae-2-2.tcore2.sv8-highbridge.as6453.net [80.231.139.1]
 12   155 ms   156 ms   154 ms  if-ae-11-2.tcore1.l78-london.as6453.net [80.231.139.42]
 13   147 ms   150 ms   147 ms  if-ae-17-2.tcore1.ldn-london.as6453.net [80.231.130.130]
 14   160 ms   167 ms   180 ms  80.231.60.123
 15   161 ms   152 ms   155 ms  ae-13.r24.londen12.uk.bb.gin.ntt.net [129.250.4.25]
 16   224 ms   223 ms   226 ms  ae-5.r24.nycmny01.us.bb.gin.ntt.net [129.250.2.18]
 17   226 ms   227 ms   226 ms  ae-1.r08.nycmny01.us.bb.gin.ntt.net [129.250.5.62]
 18   220 ms   218 ms   222 ms  ae-1.a00.nycmny01.us.bb.gin.ntt.net [129.250.6.55]
 19   295 ms   309 ms   294 ms  ae-0.amazon.nycmny01.us.bb.gin.ntt.net [129.250.201.118]
 20   309 ms   325 ms   315 ms  52.93.4.77
 21   226 ms   226 ms   225 ms  52.93.4.6
 22     *        *        *     Request timed out.
 23   231 ms   230 ms   231 ms  54.240.229.149
 24     *        *        *     Request timed out.
 25   256 ms   249 ms   245 ms  54.239.111.152
 26   227 ms   226 ms   226 ms  54.239.108.199
 27   272 ms   251 ms   275 ms  52.93.24.34
 28   230 ms   233 ms   232 ms  205.251.244.95
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Trace complete.
 
Blackhand said:
So testing now at 8pm and Github downloads completely stall and were working just fine earlier today. Same as usual.

Speedtests are completely normal.
Image downloads from dockerhub are working fine.
Streaming from Netflix and Youtube is working fine.
Downloads from http://cdn-fastly.deb.debian.org and http://security.debian.org have also completely tanked, I cannot complete a simple
Code: 
apt-get update && apt-get install -y unzip

As in the original post, a ping test to www.mybroadband.co.za exhibits good latency and no packet loss.
A ping test to afrihost.co.za has high latency, jitter and packet loss.

Here is a traceroute to each:

Code: 
tracert www.mybroadband.co.za

Tracing route to www.mybroadband.co.za [104.20.9.169]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  Amos [192.168.1.1]
  2     *        *        *     Request timed out.
  3     6 ms     6 ms     2 ms  cpt-rx2.ip.adsl.co.za [169.1.5.82]
  4    83 ms    81 ms    77 ms  cpt-net1.ip.adsl.co.za [169.1.5.128]
  5     4 ms     2 ms     2 ms  cloudflare.ixp.capetown [196.10.140.198]
  6     2 ms     2 ms     3 ms  104.20.9.169

Trace complete.

Code: 
tracert www.afrihost.co.za

Tracing route to www.afrihost.co.za [169.1.1.221]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  Amos [192.168.1.1]
  2     *        *        *     Request timed out.
  3     3 ms     3 ms     3 ms  cpt-rx2.ip.adsl.co.za [169.1.5.82]
  4    81 ms    80 ms    76 ms  cpt-net1.ip.adsl.co.za [169.1.5.128]
  5    87 ms    86 ms    86 ms  169-1-21-196.ip.afrihost.co.za [169.1.21.196]
  6    51 ms    49 ms    31 ms  169-1-5-75.ip.afrihost.co.za [169.1.5.75]
  7    24 ms    21 ms    23 ms  169-1-5-77.ip.afrihost.co.za [169.1.5.77]
  8    67 ms    62 ms    62 ms  luzonex.net.afrihost.co.za [169.1.1.221]

Trace complete.

Code: 
tracert github-production-release-asset-2e65be.s3.amazonaws.com

Tracing route to s3-1-w.amazonaws.com [52.216.228.168]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  Amos [192.168.1.1]
  2     *        *        *     Request timed out.
  3     6 ms     5 ms     7 ms  cpt-rx2.ip.adsl.co.za [169.1.5.82]
  4    81 ms    72 ms    67 ms  cpt-net1.ip.adsl.co.za [169.1.5.128]
  5    81 ms    71 ms    68 ms  41.164.52.40
  6    11 ms    13 ms    16 ms  ix-ae-7-0.tcore2.klt-cape-town.as6453.net [41.206.165.25]
  7   176 ms   153 ms   154 ms  if-ae-2-2.tcore1.klt-cape-town.as6453.net [41.206.164.253]
  8   155 ms   154 ms   154 ms  if-ae-5-2.tcore2.pv9-lisbon.as6453.net [80.231.159.85]
  9   151 ms   154 ms   154 ms  if-ae-2-2.tcore1.pv9-lisbon.as6453.net [80.231.158.5]
 10   155 ms   153 ms   154 ms  if-ae-1-3.tcore1.sv8-highbridge.as6453.net [80.231.158.30]
 11   149 ms   150 ms   147 ms  if-ae-2-2.tcore2.sv8-highbridge.as6453.net [80.231.139.1]
 12   155 ms   156 ms   154 ms  if-ae-11-2.tcore1.l78-london.as6453.net [80.231.139.42]
 13   147 ms   150 ms   147 ms  if-ae-17-2.tcore1.ldn-london.as6453.net [80.231.130.130]
 14   160 ms   167 ms   180 ms  80.231.60.123
 15   161 ms   152 ms   155 ms  ae-13.r24.londen12.uk.bb.gin.ntt.net [129.250.4.25]
 16   224 ms   223 ms   226 ms  ae-5.r24.nycmny01.us.bb.gin.ntt.net [129.250.2.18]
 17   226 ms   227 ms   226 ms  ae-1.r08.nycmny01.us.bb.gin.ntt.net [129.250.5.62]
 18   220 ms   218 ms   222 ms  ae-1.a00.nycmny01.us.bb.gin.ntt.net [129.250.6.55]
 19   295 ms   309 ms   294 ms  ae-0.amazon.nycmny01.us.bb.gin.ntt.net [129.250.201.118]
 20   309 ms   325 ms   315 ms  52.93.4.77
 21   226 ms   226 ms   225 ms  52.93.4.6
 22     *        *        *     Request timed out.
 23   231 ms   230 ms   231 ms  54.240.229.149
 24     *        *        *     Request timed out.
 25   256 ms   249 ms   245 ms  54.239.111.152
 26   227 ms   226 ms   226 ms  54.239.108.199
 27   272 ms   251 ms   275 ms  52.93.24.34
 28   230 ms   233 ms   232 ms  205.251.244.95
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Trace complete.
Click to expand...

This definitely sounds like shaping on your Premium Uncapped account, especially with streaming services not being affected. On the Premium Uncapped accounts P2P and HTTP Downloads can be shaped during peak-times, and it looks like the Github files are being categorized as these downloads.
 
AfriGenie said:
This definitely sounds like shaping on your Premium Uncapped account, especially with streaming services not being affected. On the Premium Uncapped accounts P2P and HTTP Downloads can be shaped during peak-times, and it looks like the Github files are being categorized as these downloads.
Click to expand...

Even so, not being able to download a 582kb file seems a bit more aggressive than some shaping.
 
I've had the same problem for 3+ weeks now, Office365 and GitHub are the main issues. Also on Openserve Premium Uncapped.

[MENTION=323060]AfriGenie[/MENTION] I ask, yet again: if you are going to blame shaping, then give me an exact linespeed that my line will be shaped to. If you want to shape traffic that's fine, we expect it to be slow, not to fail every time - that's not shaping at all. If you shape traffic to the point that connections fail or timeout altogether, then you need to have a serious rethink about what you consider a usable service, because you are not providing one at the moment.
 
Code: 
wget -O /app/wait [url]https://github.com/ufoscout/docker-compose-wait/releases/download/2.3.0/wait[/url]

Connecting to github.com (192.30.253.112:443)
Connecting to github-production-release-asset-2e65be.s3.amazonaws.com (52.216.168.163:443)
wait                   5% |*                              | 34375   0:00:16 ETA
wait                  14% |****                           | 86599   0:00:11 ETA
wait                  14% |****                           | 86599   0:00:17 ETA
wait                  14% |****                           | 86599   0:00:23 ETA
wait                  14% |****                           | 86599   0:00:29 ETA
wait                  14% |****                           | 86599   0:00:35 ETA
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  17% |*****                          |   101k  0:00:09 ETA
wait                  17% |*****                          |   101k  0:00:14 ETA
wait                  20% |******                         |   118k  0:00:15 ETA
wait                  26% |********                       |   152k  0:00:14 ETA
wait                  26% |********                       |   152k  0:00:16 ETA
wait                  32% |*********                      |   186k  0:00:14 ETA
wait                  32% |*********                      |   186k  0:00:16 ETA
wait                  32% |*********                      |   186k  0:00:19 ETA
wait                  32% |*********                      |   186k  0:00:21 ETA
wait                  32% |*********                      |   186k  0:00:23 ETA
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -

I can't imagine even with shaping that this would be intentional.
 
beuges said:
I've had the same problem for 3+ weeks now, Office365 and GitHub are the main issues. Also on Openserve Premium Uncapped.

[MENTION=323060]AfriGenie[/MENTION] I ask, yet again: if you are going to blame shaping, then give me an exact linespeed that my line will be shaped to. If you want to shape traffic that's fine, we expect it to be slow, not to fail every time - that's not shaping at all. If you shape traffic to the point that connections fail or timeout altogether, then you need to have a serious rethink about what you consider a usable service, because you are not providing one at the moment.
Click to expand...

You are correct, the site or service shouldn't be timing out entirely and you shouldn't be experiencing issues accessing Office365 GitHub itself.

I've just sent you a test account, can you please switch to it and try it out to see how it compares.
 
Blackhand said:
Code: 
wget -O /app/wait [url]https://github.com/ufoscout/docker-compose-wait/releases/download/2.3.0/wait[/url]

Connecting to github.com (192.30.253.112:443)
Connecting to github-production-release-asset-2e65be.s3.amazonaws.com (52.216.168.163:443)
wait                   5% |*                              | 34375   0:00:16 ETA
wait                  14% |****                           | 86599   0:00:11 ETA
wait                  14% |****                           | 86599   0:00:17 ETA
wait                  14% |****                           | 86599   0:00:23 ETA
wait                  14% |****                           | 86599   0:00:29 ETA
wait                  14% |****                           | 86599   0:00:35 ETA
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  14% |****                           | 86599   - stalled -
wait                  17% |*****                          |   101k  0:00:09 ETA
wait                  17% |*****                          |   101k  0:00:14 ETA
wait                  20% |******                         |   118k  0:00:15 ETA
wait                  26% |********                       |   152k  0:00:14 ETA
wait                  26% |********                       |   152k  0:00:16 ETA
wait                  32% |*********                      |   186k  0:00:14 ETA
wait                  32% |*********                      |   186k  0:00:16 ETA
wait                  32% |*********                      |   186k  0:00:19 ETA
wait                  32% |*********                      |   186k  0:00:21 ETA
wait                  32% |*********                      |   186k  0:00:23 ETA
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -
wait                  32% |*********                      |   186k  - stalled -

I can't imagine even with shaping that this would be intentional.
Click to expand...

That doesn't seem right. :( Just to confirm, you are using the standard Afrihost DNS?
 
AfriGenie said:
You are correct, the site or service shouldn't be timing out entirely and you shouldn't be experiencing issues accessing Office365 GitHub itself.

I've just sent you a test account, can you please switch to it and try it out to see how it compares.
Click to expand...

I've switched accounts, I'll test that this evening and give you feedback. My issues tend to happen in the evenings as well, similar to Blackhand. The problem is that everyone I've spoken to at Afrihost keeps saying I "shouldn't be experiencing issues" but I, and others, quite obviously am. We're sending you information and proof, and you keep saying it shouldn't be happening, but doing absolutely nothing to figure out why it actually is happening. From the looks of it, your shaping rules are completely broken - you clearly haven't considered that some people might actually want to use the internet for things other than streaming Netflix in the evenings.
 
AfriGenie said:
That doesn't seem right. :( Just to confirm, you are using the standard Afrihost DNS?
Click to expand...

Sorry to hijack your thread, Blackhand.

[MENTION=323060]AfriGenie[/MENTION] seriously, what difference do you think DNS is going to make on a connection that is already established? DNS's job is to take hostname "github-production-release-asset-2e65be.s3.amazonaws.com" and resolve that to IP address "52.216.168.163". Once it's done that, it's job is done and it has nothing to do with the download going forward. From Blackhand's post, it's clear that DNS is not the issue. The issue is that once he's connected to GitHub, you don't do your job by transferring data from GitHub to his PC, because you have decided that anything that isn't streaming video should be shaped down to nothingness in the evenings.
 
I am happy to help testing from a non AH fibre account at the same time as you test from AH connection?
 
beuges said:
Sorry to hijack your thread, Blackhand.

[MENTION=323060]AfriGenie[/MENTION] seriously, what difference do you think DNS is going to make on a connection that is already established? DNS's job is to take hostname "github-production-release-asset-2e65be.s3.amazonaws.com" and resolve that to IP address "52.216.168.163". Once it's done that, it's job is done and it has nothing to do with the download going forward. From Blackhand's post, it's clear that DNS is not the issue. The issue is that once he's connected to GitHub, you don't do your job by transferring data from GitHub to his PC, because you have decided that anything that isn't streaming video should be shaped down to nothingness in the evenings.
Click to expand...

DNS will determine which server or CDN you are being routed to, and I need that information to determine if this is an issue with the shaping or a routing issue.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X