Jump to content
Sign in to follow this  
mudmanc4

So you want to stream up all the data?

Recommended Posts

Ya know what I should be doing , is setting it up 56k old school, like we had to go through. That would however result in server timeouts I'm certain.

 

Hell, the limiter is set at 500kbps now, where it's really not feasible to load much, but will stream youtube somehow.

Share this post


Link to post
Share on other sites

Is that 500kbps limit you set or ISP enforced? 

 

My ISP (LTE based) surprisingly prioritises most streaming traffic such as YouTube (and Netflix I think) during peak time.  My monthly limit is 750GB, however, that cap is strictly enforced.  Go over it and it is a eye popping €50 per GB, which I've heard people getting hit by.

 

To give an idea of traffic prioritisation, the following is a YouTube "Stats for Nerds" screen playing 4K, which should be impossible at the speed TestMy reports on the right:

 

5a612b23ba0a7_YouTubeonThree4G.png.d5611682ffd5f62e3dd9c45b8765648f.pngub82qgavx.ImPCcD9Nx.png

Share this post


Link to post
Share on other sites

Ah, was wondering. :D

 

I think there's just one ISP in Ireland that throttles to 1Mbps.  The rest either cut the connection (e.g. LTE and wireless ISPs) or charge for excessive usage. 

 

I checked the Windows Resource Monitor while playing a video forced in 4K mode:

5a620e821791b_YouTubeResourceMonitor.png.4e801c5be31209cb7699cb4f36a41a53.png

 

I see that YouTube now streams over two simultaneous connections, as those two 74.125.97.18 connections were going steady until I stopped the video. 

 

The following is a trace route to this IP:

5a620e770d6eb_YouTubevideotraceroute.png.f10afc4f21eb221bbc2efa633072af7b.png

 

According to the TCPIPUTILS website, the last 4 ISPs shown belong to Google.  172.30.199.50 is a non Internet routable IP, so is within the ISP.  This indeed means that either Google has servers within the ISP or has peering with Google that is given high traffic priority.

Share this post


Link to post
Share on other sites

Interesting.

 

drill 172.23.0.49
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 6202
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 
;; QUESTION SECTION:
;; 172.23.0.49.	IN	A

;; ANSWER SECTION:

;; AUTHORITY SECTION:
.	3395	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2018011900 1800 900 604800 86400

;; ADDITIONAL SECTION:

;; Query time: 73 msec
;; SERVER: 10.10.5.1
;; WHEN: Fri Jan 19 11:29:05 2018
;; MSG SIZE  rcvd: 104

 

As well as :

 

drill 172.30.199.50
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 30320
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 
;; QUESTION SECTION:
;; 172.30.199.50.	IN	A

;; ANSWER SECTION:

;; AUTHORITY SECTION:
.	3569	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2018011900 1800 900 604800 86400

;; ADDITIONAL SECTION:

;; Query time: 29 msec
;; SERVER: 10.10.5.1
;; WHEN: Fri Jan 19 11:32:44 2018
;; MSG SIZE  rcvd: 106

 

Share this post


Link to post
Share on other sites

:evil6:

drill -x 172.30.199.50
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 44882
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 
;; QUESTION SECTION:
;; 50.199.30.172.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:

;; AUTHORITY SECTION:
30.172.in-addr.arpa.	10800	IN	SOA	localhost. nobody.invalid. 1 3600 1200 604800 10800

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 10.10.5.1
;; WHEN: Fri Jan 19 11:34:31 2018
;; MSG SIZE  rcvd: 103

 

Share this post


Link to post
Share on other sites

I've since setup squid, not that this will help with streaming, but every little bit will, caching 500Gigs should do something over long term. Each user gets 750k .

 

I've yet to work out whether squid will do throttling if :80 / :443 are not explicitly blocked on the network, or if traffic shaper will continue to do it.

 

Here's a quick screen of streaming youtube @ 480p, (where 'thecave' is a local domain) also notice the same net as yours? I know what they are, but I don't know what other than SSL through google this will be accomplishing so...........

 

squid-750k.png

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Similar Content

    • By mudmanc4
      Suppose you needed to transfer 1TB of data (perhaps your home movie collection) from San Francisco to London. What would be the fastest route? Put the disk on British Airways flight 286 at SFO, or transfer it across the Internet using a 100 Mbps connection?
      Surprisingly, the answer is the former not the latter. If you had a perfect 100 Mbps Internet connection and could fill it completely with data the transfer would take 22 hours 13 minutes. British Airways make the flight in under 10 hours.
       
      But even with a 100 Mbps Internet connection you're unlikely to get 100 Mbps of transfer speed between San Francisco and London. The details of the TCP protocol used on the Internet and the speed of light collude to make the effective transfer speed much lower.
      To really understand the speed of an Internet connection, be it transferring 1TB of data or downloading a web page, there are two values that you need to know: the bandwidth and the latency.
       
      The bandwidth is how much data can be sent on the connection in a unit of time. In the example above the Internet connection has a bandwidth of 100 Mbps, the Boeing 747 has a bandwidth of 222 Mbps (the 1TB carried divided by the flight time).
      The latency is the 'flight time' of data across the connection. For a connection between London and San Francisco across the Internet the latency will be something like 150ms. That figure is governed and limited by the speed of light. For the 747 the latency is the literal flying time of 10 hours.
       
      One thing British Airways ensures while flying the 1TB of data is reliability. The data is very, very unlikely to not arrive in London. The Internet does not provide the same guarantee. As data is transferred across the Internet it gets delayed, lost, corrupted and misordered. So, the Internet's core protocol TCP provides mechanisms to ensure the reliable delivery of data despite the lossy network the data is passing through. It's these mechanisms that slow the transfer of data down and where the speed of light comes into play.
      (If airlines experienced aircraft loss at the rate the Internet sees packet loss there'd be 28 crashes per day in the US alone).
       
      To ensure reliability, TCP breaks data to be sent up into chunks (which are further broken down into packets) and sends chunks of data and then waits for an acknowledgement that the chunk was successfully received. It's while waiting for the acknowledgement that the speed of light comes into play.
       
      Imagine that a 65kB chunk of data has been sent across a link with a latency of 150ms. The 65kB take 150ms to reach their destination and the receiving machine sends an acknowledgement that takes a further 150ms to arrive. So 0.3s is taken up making sure that 65KB have arrived successfully; that number is called the Round Trip Time.
       
      Those acknowledgement delays significantly hamper connections across long distances (and also from mobile phones).
      The amount of data that TCP can send in a single chunk is controlled by the Receive Window of the receiver machine. For web surfers that means that the receiving machine controls how much can be sent without acknowledgement. And the combination of Receive Window and Round Trip Time limit the speed at which downloads can occur no matter what the bandwidth is.
      The maximum throughput of TCP is Receive Window divided by Round Trip Time.
       
      For example, on my machine the Receive Window is set at 524,288 bytes meaning that on a slow link from London to San Francisco the fastest download I can get is 524,288 bytes / 0.3s or 14 Mbps. Much less than the 100 Mbps I was hoping to get.
      So, my 1TB download would actually take more than 6 days! The speed of light really is a limiting factor in downloading.
      How do you fight the speed of light? Since you can't control the Receive Window the only thing you can do is move your web site closer to the people surfing it. And, of course, that's not practical for most web sites since you'd have to have copies of the web site all over the world.
       
      CloudFlare fights the speed of light for you by having data centers around the world. If your site is on CloudFlare then surfers will connect to the data center that's nearest to them.
       
       More @ Source by John Graham-Cumming
       
       
×
×
  • Create New...