Page 1 of 4 1234 Last
Results 1 to 25 of 88

  1. Post
    #1
    Hello

    I watch Starcraft 2 GSL on livestream or ustream a lot, and getting a terrible lag on those sites very recently(unable to watch live stream).
    It seems that the lagging occurs as number of viewers increases (Other streams with low number of viewers are not lagging).

    Any one here experiencing same thing???? I could watch those on GOMTV website to watch the stream directly, but I dont like using GOM Player streaming service since they are saying that the program can eat up my internet bandwidth for using on cloud networking or some crap. I dont want to waste my extra data.

    Any one experiencing same issue as me can you post a reply so I understand that this is same for all Telecom broadband users, not cos of my network problem??.

  2. Post
    #2
    I'm guessing it's this stream: http://www.ustream.tv/channel/starcraft-2-beta-liveplay
    Yeah I get lag issues too, either only the video freezes or both audio/video freeze.

    Popular streams with many viewers on ustream.tv seem be delivered using globally distributed CDNs, I see they have switched from using Akamai to Limelight Networks CDN in the last few months.

    If I change from Limelight's Sydney CDN servers (which Telecom connections get directed to as it is the closest to NZ) to their US servers the stream seems to be smooth with no glitches.

    So if you're really desperate to watch this, you could make ONE of these changes at your end:
    - One way to end up on Limelight's US CDN servers is to use another DNS resolver such as Google Public DNS 8.8.8.8 and 8.8.4.4
    - Another way could be to force the host ustream.fc.llnwd.net to resolve to a chosen IP address of a Limelight US CDN server.
    You could do this through your Windows HOSTS file, by adding an line/entry such as:
    68.142.77.78 ustream.fc.llnwd.net

    These streams seem to have pretty insane high bit rates... averaging over 200 KB/s.

  3. Post
    #3
    fwiw, i noticed something else slow to sydney limelight recently. static content though. i think limelight probably suck.

    mind you, if i look up akamai on 8.8.8.8 from nz it directs to some node in hong kong ...

    google dns really works a lot better in the US than NZ...

    but limelight's probably not part of their optimized cdn config..

    i'm not on telecom but i still got a slight lag at the very beginning of the video. not as annoying as the bloody advertisement for 15 seconds or something. it was just like sound was happenign then it wasn't and huh? then it kind of kicked off again .. and seemed smooth.

  4. Post
    #4
    Yeah Limelight had huge issues at the beginning of this year with their routes being hijacked by Optus, it caused their CDN to be down for 5 days O_o O_o (they didn't even use DNS to redirect around it ) mostly affecting ISPs in Australia and NZ who used transit providers who peered with Optus in Sydney. Were quite a few threads about Steam Store being down on here. Pretty shocking for such as big CDN provider.
    Telecom later began peering with Limelight in Sydney in July this year.
    A lot of content does come through the links though, Microsoft's Edge Content Network (beginning to replace Akamai for Windows Updates etc.) tag along Limelight's peering arrangements in this region.

    OpenDNS recently implemented this new extension to DNS to make sure Google Cache CDN requests get returned local resolutions:
    http://googlecode.blogspot.com/2010/...-protocol.html
    Doesn't really scale though... smaller CDN providers will probably miss out.

  5. Post
    #5
    na but cam4 is working great!

  6. Post
    #6
    tehyitz wrote:
    I'm guessing it's this stream: http://www.ustream.tv/channel/starcraft-2-beta-liveplay
    Yeah I get lag issues too, either only the video freezes or both audio/video freeze.

    Popular streams with many viewers on ustream.tv seem be delivered using globally distributed CDNs, I see they have switched from using Akamai to Limelight Networks CDN in the last few months.

    If I change from Limelight's Sydney CDN servers (which Telecom connections get directed to as it is the closest to NZ) to their US servers the stream seems to be smooth with no glitches.

    So if you're really desperate to watch this, you could make ONE of these changes at your end:
    - One way to end up on Limelight's US CDN servers is to use another DNS resolver such as Google Public DNS 8.8.8.8 and 8.8.4.4
    - Another way could be to force the host ustream.fc.llnwd.net to resolve to a chosen IP address of a Limelight US CDN server.
    You could do this through your Windows HOSTS file, by adding an line/entry such as:
    68.142.77.78 ustream.fc.llnwd.net

    These streams seem to have pretty insane high bit rates... averaging over 200 KB/s.
    WOW I tried first method and the stream is playing as smooth as heaven. Just curious But are there any disadvantages for changing dns to google's? If not.. I suggest all ppl to change dns to that one. Did not expect this huge boost in speed lol..Thanks again!!

  7. Post
    #7
    There are disadvantages. It will do the same thing for other CDNs which don't have that issue (Akamai, for instance)

  8. Post
    #8
    JustAGuy-AAA wrote:
    WOW I tried first method and the stream is playing as smooth as heaven. Just curious But is there any disadvantages for changing dns to google's? If not.. I suggest all ppl to change dns to that one. Did not expect this huge boost in speed lol..Thanks again!!
    it makes akamai come from hong kong and go slow.. www.latimes.com is an example of akamai hosted web site.

  9. Post
    #9
    hmmm.. google dns like system in nz could be kind of cool.. but prob not enough users to make it go fast enough.

  10. Post
    #10
    I'd probably recommend method #2 in this case...
    Add the line
    68.142.77.78 ustream.fc.llnwd.net
    to the end of the HOSTS file, instructions at: http://support.microsoft.com/kb/923947

    Google Public DNS is anycasted so:
    Snap > Reach --peer--> Google Japan = closest Akamai in Hong Kong.
    Telecom > Global-Gateway --peer--> Google US West = closest Akamai in US West

    Closest AS15169 (Google's content ASN) is in Sydney which is backhauled via Japan. Google Public DNS isn't hosted in Sydney.
    Orcon is the only ISP who peer there directly, while some IP transit providers such as VOCUS and Pacnet do too.

  11. Post
    #11
    tehyitz wrote:
    I'd probably recommend method #2 in this case...
    Add the line
    68.142.77.78 ustream.fc.llnwd.net
    to the end of the HOSTS file, instructions at: http://support.microsoft.com/kb/923947

    Google Public DNS is anycasted so:
    Snap > Reach --peer--> Google Japan = closest Akamai in Hong Kong.
    Telecom > Global-Gateway --peer--> Google US West = closest Akamai in US West

    Closest AS15169 (Google's content ASN) is in Sydney which is backhauled via Japan. Google Public DNS isn't hosted in Sydney.
    Orcon is the only ISP who peer there directly, while some IP transit providers such as VOCUS and Pacnet do too.
    how do you know so much!

    fwiw, i've given up on google's australian node. better performance on average from california. probably the cache misses
    hitting japan backhaul then?

  12. Post
    #12
    mercutio wrote:
    how do you know so much!
    Just been following some of the content delivery stuff and peering arrangements in this region... just a little over 2 years ago there weren't as many global CDNs such as Google and Google Cache nodes, Limelight CDN, Microsoft CDN, Edgecast Networks, Yahoo! etc... back then there was more Windows Media streaming than Flash, Windows Media is now pretty much renamed to Silverlight, and also the rise of "domestic CDNs" such as Internode CDN, Orcon Velocix and more CDNs through Telecom Wholesale peering and new NZ domestic transit providers such as FX Networks etc.. and those launching this year such as Webdrive and ICONZ CDN and stuff... CDNs designed for unmetered content (NOT Velocix/iSKY)... that's all I can think of right now at this time of morning
    mercutio wrote:
    fwiw, i've given up on google's australian node. better performance on average from california. probably the cache misses
    hitting japan backhaul then?
    Maybe ask nicely if Snap will add the KAREN routing table for your ADSL connection... might be able to reach AARNET tunnel broker instead of HE lol

    Apparently Google have something like 80 Gb/s between Sydney<>Japan ... quite a bit.

  13. Post
    #13
    tehyitz is a massive nerd.

  14. Post
    #14
    Agreed

  15. Post
    #15
    /thread dig

    Is limelight still shit? Since crunchyroll switched to limelight from akamai their streams have turned to shit for me, the host is crunchy.fcod.llnwd.net. Site seems to get stuck on static.lln.crunchyroll.com a lot too, sigh.

    Can I use the LA ip address you pasted above sir tehyitz?

  16. Post
    #16
    Practically every ISP in NZ has "local" akamai servers or peers/interconnects with someone who does, I can't think of any ISP with Limelight mirrors/nodes in the country.

  17. Post
    #17
    **** limelight then

  18. Post
    #18
    What the hell, 99% sure this is getting routed through the DIA filter peering/route (serious btw)...

    Code:
    Tracing route to crunchy.vo.llnwd.net [117.121.253.254]
    over a maximum of 30 hops:
    
      1     *        *        *     Request timed out.
      2    81 ms    43 ms    45 ms  219-89-60-1.dialup.xtra.co.nz [219.89.60.1]
      3     *        *        *     Request timed out.
      4   185 ms   107 ms   142 ms  124.150.165.62
      5     *        *        *     Request timed out.
      6     *      101 ms     *     as45577.mel01.vic.intervolve.com.au [114.111.139.2]
      7     *        *        *     Request timed out.
      8   100 ms     *      113 ms  ge-1-0-6.cor01.syd03.nsw.VOCUS.net.au [114.31.192.82]
      9   124 ms   105 ms     *     ge-0-3-2.bdr02.syd03.nsw.VOCUS.net.au [114.31.192.65]
     10     *        *      111 ms  p38622.syd.equinix.com [202.167.228.57]
     11     *        *      101 ms  cdn-117-121-253-254.syd.llnw.net [117.121.253.254]
    
    Trace complete.


    124.150.165.62 = Fastcom peer
    http://fastcom.net.nz/clients-depart...ernal-affairs/

    All that packetloss... the link doesn't look good...

    Vulcan??

  19. Post
    #19
    Telecom did announce they were going to start using the filter so no real surprise?

    http://www.telecom-media.co.nz/relea...=3&pagesize=10

    Maybe the shit fastcom link is what explains the poor performance now

  20. Post
    #20
    Anime classed as kiddie pron thesedays? Go nanny state!
    http://en.wikipedia.org/wiki/Crunchyroll

    Here's telstraclear (business) for comparison

    Tracing route to crunchy.vo.llnwd.net [68.142.79.70] over a maximum of 30 hops:

    3 1 ms 1 ms 1 ms ge-2-0-0-948.internet.ie1.telstraclear.net [218.101.61.57]
    4 1 ms 1 ms 1 ms ge-0-2-0-1.xcore1.acld.telstraclear.net [203.98.50.251]
    5 1 ms 1 ms 1 ms 203.167.233.10
    6 132 ms 150 ms 132 ms unknown.net.reach.com [202.84.142.114]
    7 132 ms 132 ms 132 ms i-1-1.tlot03.bi.reach.com [202.84.251.234]
    8 131 ms 129 ms 129 ms ge2-7.fr1.lax.llnw.net [206.223.123.123]
    9 160 ms 128 ms * cdn-68-142-79-70.lax.llnw.net [68.142.79.70]
    10 129 ms 128 ms 134 ms cdn-68-142-79-70.lax.llnw.net [68.142.79.70]

  21. Post
    #21
    Well it won't be Crunchyroll as the www.dce.net.nz message doesn't come up but it'll be another site hosted on the same IP address...in this case a CDN box (Limelight Networks).

    Unless Fastcom is somehow an actual upstream for Telecom Broadband... although I highly doubt it...

  22. Post
    #22
    Yeah www.crunchyroll.com doesn't load at all on Telecom, presumably because the CDN is blacklisted by the DIA.. but yeah no DCE message.

    Could the DCE message just not be showing because of some weird Telecom dns/caching proxy issue?

  23. Post
    #23
    Would've thought the DCE message would just be a HTTP redirect inserted into the response or something like that.

    Telecom's international web caching is further upstream, if you don't see that ae-4.10.akbr5.global-gateway.net.nz (or tkbr10.ggis.net.nz) hop the request won't pass through the cache farms.

  24. Post
    #24
    Stupid children are always being exploited by governments to get away with this crap.

  25. Post
    #25
    So clearly the system is flawed and/or run by ****ing idiots. They ban a limelight CDN IP address which impacts all limelight delivered content?

    I think the reason no message appears is because it's the video stream and it's delivered over some method that "stops" people saving the stream like you can with YouTube

    Either way I love having my Internet controlled by this filter...

    I notice it's only when you trace static.lln.crunchyroll.com where you get the 117.x.x.x IP that you go through fastcom, whereas if you flush the dns cache and trace crunchy.vo.llwnd.net you get a 64.x.x.x IP which goes through global gateway

    Can anyone on Maxnet trace static.lln.crunchyroll.com to see if it goes through that fastcom thing?