Jump to content

Rez Failures & CDN Issues during Peak SL times? 5:30pm SLT - 9pm ish? Nightly?

Samual Wetherby

By Samual Wetherby,
in Second Life Server

 Share
You are about to reply to a thread that has been inactive for 3263 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

  • Lindens
Monty Linden

Monty Linden

Posted
  • Lindens
Posted

Samual Wetherby wrote:

8pm SLT Tons of Fetching Errors and retry timeouts to CDN server.

Tracing route to cds.y8a2h6u5.hwcdn.net [205.185.216.42]

over a maximum of 30 hops:

 

Traceroute/tracert are useful tools but they have limitations.  They are useful for finding layer 2, 3, and 4 problems (low-level networking, routing issues, firewalls).  But not so good at layer 7 problems (weird or wrong HTTP protocol handling).  And when multiple companies are involved, everyone wants to toss the potato to someone else.  A better tool or diagnostic approach, one that is harder to repudiate, needs to be developed.

But that doesn't help you now.  For you, I have an experiment to try.  Something to see if you can get around the errors.  It involves changing two debug settings, clearing cache, and restarting the viewer.  I'm going to assume you know how to do these things and the information you need is the two settings:

  • Mesh2MaxConcurrentRequests (set to 3)
  • TextureFetchConcurrency (set to 3)

Start the viewer, go to your test region, allow everything to load then examine the log file for *any* texture or mesh failures (other than 404/NotFound).  If it is clean or substantially improved, you have a workaround and you have some additional information for your ISP that might get them interested.  (The detail being six versus 16 sustained, pipelined HTTP connections.)

 

Link to comment
Share on other sites
  • Replies 52
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Sean Heying

Sean Heying

Posted
Posted

Resepctfully Monty, and please understand I worked for 5 to 8 hours every single day testing curl with Aleric for at least 6 weeks before, during and after the CDN rollout.... I might not be at your or his levels, as I saw your clear skill in the Curl mailing lists... you both leave me for dead; but I'm not exactly a slouch.

There is a clear, worldwide issue where peak times for your ISP will see the CDN time out. It has been happening with me since you went live, with generic repository libcurl or even with a special system including Aleric's maillist patches to libcurl and my developer build.

It happens to me no matter which alpha or production client I use too. Windows or Linux. SL, FS or Singu. I even have a backup LTE modem to test with at these peak times. Two ISPs - Telstra and iiNet - both fail at the same time, albeit Telstra less noticably.

The problem is a time out. The time out causes various symptoms in all viewers. For Singu the timeout causes the "texture" to be blacklisted. The "texture" being blacklisted is usually a mesh geometry. When that "fault" happens the pipeline locks until the 60-120 seconds or so timeout is exceeded and the "texture" is skipped

 

It might be possible there is tuning needed of the CDN to take account for packet loss and delayed packets during peak ISP time - especially for rare textures. That it's a global issue with people from Australia, Europe and the USA all reporting it at peak ISP times suggests to layperson me that your timeout periods are a little too tight. Not the client's timeouts. The servers.

 

I know one thing Aleric and I did see in Bare Rose. ( a great texture only test bed ) the first loads took ages as the texture was sent to the CDN. The second loads were blinding fast as the CDN supplied it. I see similar things with mesh "textures". The first load of something times out. Relog and it pops immediately.

 

I feel sad seing you say "The problem is with your ISP (6 vs 16 pipelines)" that is you passing the potato to them. Your design should be investigated a little more deeply too (and I know this is simplistic) because before the CDN it worked and after the CDN it failed.

Yes, we go to fewer CDN clusters that can sustain more connections rather than using simulator capabilities with limiting on connections and bandwidth --- but the CDN should be robust enough and BIG enough to deal with that. Especially in my tiny little region. The number of Australians playing during our peak ISP times is miniscule compared to the number of Americans or Europeans playing during theirs. I don't have access to your metrics, but surely there are not even 5,000 of us.

 

One ISP, sure. Two ISPs maybe. But tens, hundreds of ISPs over many countries? No, that sounds more like it's a config issue for the CDN itself - especially when you consider that AICurl is very different to LLCurl and FSCurl in many areas, not just in number of channels but the various timeouts. And in the case of my one of my test systems even with the mailing list bugfixes.

 

I wish you luck in this. The last few months have been unbearable for me to the point that I rarely play any more. SL has clearly deteriorated during peak ISP times. Where the old "get the texture from the sim" system never failed the CDN is failing even when I limit the concurrent connections to 6 or less. It blocks with a timeout.

Link to comment
Share on other sites
Samual Wetherby

Samual Wetherby

Posted
  • Author
Posted

Sean sounds like you have hit it on the nail.

I've been pointing at this issue for a while. Exhausted every possible local possibility, but it's very clear it's a CDN issue.  I get it, LL wants to call the whole CDN project a 100% success. I wish it was, but I'm in the same boat as you Sean, SL has become very frustrating and limited use. LL wants to point the finger at the IPS, but clearly something is wrong with CDN as my data requests go through Mediacom then AT&T (you don't get bigger infrustrature than that) and times out at the CDN server waiting for the requested data.

Link to comment
Share on other sites
  • Lindens
Monty Linden

Monty Linden

Posted
  • Lindens
Posted

Sean Heying wrote:

Resepctfully Monty,

No worries, I can take a bit of heat.  In no way is this intended to dismiss the problems people are seeing.  They are real and work is progressing behind the firewall on getting the experience up to expectations.  I'm just offering an expedient treat-the-symptom approach.  Something to alleviate some pain now and get sufferers closer to where they want to be.  It may also give some insight into where we might go with service monitoring or adaptive behavior in the client.

Link to comment
Share on other sites
Samual Wetherby

Samual Wetherby

Posted
  • Author
Posted

Made the adjustments.

When normally everrything just POPs during the day, once I made the adjustments, things seem to be sluggish rezzing or like Sean said, long periods waiting on an empty CDN server then everything jumps in place.

Will see how my textures rez as getting closer to my usual issue time.

I can see what Sean is saying and seems exactly the issue. Timing Retires, images and textures being locked out from the CDN.

Link to comment
Share on other sites
  • Lindens
Monty Linden

Monty Linden

Posted
  • Lindens
Posted

Thanks for running a test.  And log file is full of timeout errors (8 retries)?  Clearly not a successful workaround for you.  

There is another setting to try though it is mostly a factor when connecting via inexpensive, questionable tethering gear (I'm looking at you, android):

  • HttpPipelining (set to false)

Combined with the previous two, it may be a very slow load but I'm interested in error-free first.

 

 

Link to comment
Share on other sites
  • 2 weeks later...
Samual Wetherby

Samual Wetherby

Posted
  • Author
Posted

So sad.

No clue what Linden did yesterday & today but now having rez issues 24/7
Have done a clean re-install of FS 64bit.
Internet speeds are pretty steady at 96Mbs
Brand new Cisco DOCSIS 3.0 3010 Modem wiht 8/4 channels.
All 8 downstreams are bond and cooking right along according to Mediacom.
Mediacom has run test after test and only see an issue with Linden Labs CDN server data transfer.

 

SLIssues4-15-2015.jpg

Link to comment
Share on other sites
Samual Wetherby

Samual Wetherby

Posted
  • Author
Posted

Since Tuesday & Wednesdays server updates CDN changes, objects seem to rez faster, although not like during the daytime when they POP into place, but during the evening they do rez better.

Skin textures, attachments, alphas do not.
Logs show numerous failed fetching, blacklisted items, not found, etc during evenings.
All ping & tracert test show data, requests arrive very fast 30-40ms with no packet loss.

 

FAILED, status: Easy_28 reason: Timeout was reached
newview/lltexturefetch.cpp(1670) : 2015-04-20T03:29:14Z INFO: LLTextureFetchWorker::doWork: HTTP GET failed for: http://bake-texture.agni.lindenlab.com/texture/e9be5a8b-fda6-405c-8fcf-ece3595a0068/upper/8aae1b60-6013-92bb-171b-6015fc20a2f7 Status: Easy_28 Reason: 'Timeout was reached'
newview/lltexturefetch.cpp(1699) : 2015-04-20T03:29:14Z WARNING: LLTextureFetchWorker::doWork: 8aae1b60-6013-92bb-171b-6015fc20a2f7 abort: fail harder
newview/lltexturefetch.cpp(1670) : 2015-04-20T03:29:14Z INFO: LLTextureFetchWorker::doWork: HTTP GET failed for: http://bake-texture.agni.lindenlab.com/texture/694be514-4f31-4bdd-9ee0-9ca6627bcf8c/head/91d44a86-4f55-e2fc-8f72-6835d554f67e Status: Easy_28 Reason: 'Timeout was reached'
newview/lltexturefetch.cpp(1699) : 2015-04-20T03:29:14Z WARNING: LLTextureFetchWorker::doWork: 91d44a86-4f55-e2fc-8f72-6835d554f67e abort: fail harder
newview/lltexturefetch.cpp(1670) : 2015-04-20T03:29:14Z INFO: LLTextureFetchWorker::doWork: HTTP GET failed for: http://bake-texture.agni.lindenlab.com/texture/1d126638-9e53-4ca0-b6a1-61aa44c64fae/head/88b262db-4f1e-7ecc-49a9-4399d8422b4e Status: Easy_28 Reason: 'Timeout was reached'
newview/lltexturefetch.cpp(1699) : 2015-04-20T03:29:14Z WARNING: LLTextureFetchWorker::doWork: 88b262db-4f1e-7ecc-49a9-4399d8422b4e abort: fail harder
newview/lltexturefetch.cpp(1670) : 2015-04-20T03:29:14Z INFO: LLTextureFetchWorker::doWork: HTTP GET failed for: http://bake-texture.agni.lindenlab.com/texture/fbe026c3-8130-44ff-a9b0-1b471b16bfd6/lower/8a761801-a5ba-33df-98b6-08ebe2918a0c Status: Easy_28 Reason: 'Timeout was reached'
newview/lltexturefetch.cpp(1699) : 2015-04-20T03:29:14Z WARNING: LLTextureFetchWorker::doWork: 8a761801-a5ba-33df-98b6-08ebe2918a0c abort: fail harder
llcorehttp/_httppolicy.cpp(441) : 2015-04-20T03:29:14Z WARNING: LLCore::HttpPolicy::stageAfterCompletion: HTTP request 0000000085F17CB0 failed after 8 retries.  Reason:  Timeout was reached (Easy_28)
newview/lltexturefetch.cpp(2026) : 2015-04-20T03:29:14Z INFO: LLTextureFetchWorker::onCompleted: 92511393-b141-f6a9-aa5d-8f1f89debf05 state WAIT_HTTP_REQ
newview/llhttpretrypolicy.cpp(119) : 2015-04-20T03:29:14Z INFO: LLAdaptiveRetryPolicy::onFailureCommon: Non-server error 0, will not retry
newview/lltexturefetch.cpp(2041) : 2015-04-20T03:29:14Z INFO: LLTextureFetchWorker::onCompleted: 92511393-b141-f6a9-aa5d-8f1f89debf05 will not retry
newview/lltexturefetch.cpp(2061) : 2015-04-20T03:29:14Z WARNING: LLTextureFetchWorker::onCompleted: CURL GET FAILED, status: Easy_28 reason: Timeout was reached
newview/lltexturefetch.cpp(1670) : 2015-04-20T03:29:14Z INFO: LLTextureFetchWorker::doWork: HTTP GET failed for: http://bake-texture.agni.lindenlab.com/texture/18db22a6-ff40-478f-a127-6c53e85a96aa/head/92511393-b141-f6a9-aa5d-8f1f89debf05 Status: Easy_28 Reason: 'Timeout was reached'
newview/lltexturefetch.cpp(1699) : 2015-04-20T03:29:14Z WARNING: LLTextureFetchWorker::doWork: 92511393-b141-f6a9-aa5d-8f1f89debf05 abort: fail harder
llcorehttp/_httppolicy.cpp(441) : 2015-04-20T03:29:15Z WARNING: LLCore::HttpPolicy::stageAfterCompletion: HTTP request 00000000B77653D0 failed after 0 retries.  Reason:  Not Found (Http_404)
newview/lltexturefetch.cpp(2061) : 2015-04-20T03:29:15Z WARNING: LLTextureFetchWorker::onCompleted: CURL GET FAILED, status: Http_404 reason: Not Found
newview/lltexturefetch.cpp(1634) : 2015-04-20T03:29:15Z WARNING: LLTextureFetchWorker::doWork: Texture missing from server (404): http://asset-cdn.glb.agni.lindenlab.com/?texture_id=d8c37d28-518f-654b-5aa3-57197456ed12
newview/llviewertexture.cpp(2028) : 2015-04-20T03:29:15Z WARNING: LLViewerFetchedTexture::updateFetch: 8a761801-a5ba-33df-98b6-08ebe2918a0c Fetch failure, setting as missing, decode_priority 5501070.000000 mRawDiscardLevel 32767 current_discard -1 stats 0000001c
newview/llviewertexture.cpp(2248) : 2015-04-20T03:29:15Z WARNING: LLViewerFetchedTexture::setIsMissingAsset: http://bake-texture.agni.lindenlab.com/texture/fbe026c3-8130-44ff-a9b0-1b471b16bfd6/lower/8a761801-a5ba-33df-98b6-08ebe2918a0c: Marking image as missing
newview/llviewertexture.cpp(2028) : 2015-04-20T03:29:15Z WARNING: LLViewerFetchedTexture::updateFetch: 8aae1b60-6013-92bb-171b-6015fc20a2f7 Fetch failure, setting as missing, decode_priority 5501999.000000 mRawDiscardLevel 32767 current_discard -1 stats 0000001c
newview/llviewertexture.cpp(2248) : 2015-04-20T03:29:15Z WARNING: LLViewerFetchedTexture::setIsMissingAsset: http://bake-texture.agni.lindenlab.com/texture/e9be5a8b-fda6-405c-8fcf-ece3595a0068/upper/8aae1b60-6013-92bb-171b-6015fc20a2f7: Marking image as missing
newview/llviewertexture.cpp(2507) : 2015-04-20T03:29:15Z INFO: LLViewerFetchedTexture::doLoadedCallbacks: baked texture: 8a761801-a5ba-33df-98b6-08ebe2918a0cis missing.
newview/llviewertexture.cpp(2508) : 2015-04-20T03:29:15Z INFO: LLViewerFetchedTexture::doLoadedCallbacks: http://bake-texture.agni.lindenlab.com/texture/fbe026c3-8130-44ff-a9b0-1b471b16bfd6/lower/8a761801-a5ba-33df-98b6-08ebe2918a0c
newview/llviewertexture.cpp(2507) : 2015-04-20T03:29:15Z INFO: LLViewerFetchedTexture::doLoadedCallbacks: baked texture: 8aae1b60-6013-92bb-171b-6015fc20a2f7is missing.
newview/llviewertexture.cpp(2508) : 2015-04-20T03:29:15Z INFO: LLViewerFetchedTexture::doLoadedCallbacks: http://bake-texture.agni.lindenlab.com/texture/e9be5a8b-fda6-405c-8fcf-ece3595a0068/upper/8aae1b60-6013-92bb-171b-6015fc20a2f7
newview/llviewertexturelist.cpp(1598) : 2015-04-20T03:29:16Z WARNING: LLViewerTextureList::processImageNotInDatabase: not in db
newview/llviewertexture.cpp(2239) : 2015-04-20T03:29:16Z WARNING: LLViewerFetchedTexture::setIsMissingAsset: d8c37d28-518f-654b-5aa3-57197456ed12: Marking image as missing
newview/llviewertexture.cpp(2028) : 2015-04-20T03:29:16Z WARNING: LLViewerFetchedTexture::updateFetch: 91d44a86-4f55-e2fc-8f72-6835d554f67e Fetch failure, setting as missing, decode_priority 5501999.000000 mRawDiscardLevel 32767 current_discard -1 stats 0000001c
newview/llviewertexture.cpp(2248) : 2015-04-20T03:29:16Z WARNING: LLViewerFetchedTexture::setIsMissingAsset: http://bake-texture.agni.lindenlab.com/texture/694be514-4f31-4bdd-9ee0-9ca6627bcf8c/head/91d44a86-4f55-e2fc-8f72-6835d554f67e: Marking image as missing
newview/llviewertexture.cpp(2507) : 2015-04-20T03:29:16Z INFO: LLViewerFetchedTexture::doLoadedCallbacks: baked texture: 91d44a86-4f55-e2fc-8f72-6835d554f67eis missing.
newview/llviewertexture.cpp(2508) : 2015-04-20T03:29:16Z INFO: LLViewerFetchedTexture::doLoadedCallbacks: http://bake-texture.agni.lindenlab.com/texture/694be514-4f31-4bdd-9ee0-9ca6627bcf8c/head/91d44a86-4f55-e2fc-8f72-6835d554f67e
newview/llviewertexturelist.cpp(1598) : 2015-04-20T03:29:16Z WARNING: LLViewerTextureList::processImageNotInDatabase: not in db

 

 

4-19-2015 4:53 Ping & Tracert Test

C:\Users\Office>ping http://asset-cdn.glb.agni.lindenlab.com
Ping request could not find host http://asset-cdn.glb.agni.lindenlab.com. Please
 check the name and try again.

C:\Users\Office>ping asset-cdn.glb.agni.lindenlab.com

Pinging cds.y8a2h6u5.hwcdn.net [205.185.216.10] with 32 bytes of data:
Reply from 205.185.216.10: bytes=32 time=43ms TTL=53
Reply from 205.185.216.10: bytes=32 time=38ms TTL=53
Reply from 205.185.216.10: bytes=32 time=36ms TTL=53
Reply from 205.185.216.10: bytes=32 time=39ms TTL=53

Ping statistics for 205.185.216.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 36ms, Maximum = 43ms, Average = 39ms

C:\Users\Office>ping bake-texture.agni.lindenlab.com

Pinging cds.i6j9r8g5.hwcdn.net [205.185.216.10] with 32 bytes of data:
Reply from 205.185.216.10: bytes=32 time=37ms TTL=53
Reply from 205.185.216.10: bytes=32 time=41ms TTL=53
Reply from 205.185.216.10: bytes=32 time=33ms TTL=53
Reply from 205.185.216.10: bytes=32 time=36ms TTL=53

Ping statistics for 205.185.216.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 33ms, Maximum = 41ms, Average = 36ms

C:\Users\Office>tracert asset-cdn.agni.lindenlab.com

Tracing route to cds.y8a2h6u5.hwcdn.net [205.185.216.10]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    12 ms    13 ms     7 ms  10.188.80.1
  3    22 ms    11 ms    11 ms  172.30.78.177
  4    16 ms    13 ms    11 ms  172.30.32.69
  5    27 ms    27 ms    27 ms  cr1.nwrla.ip.att.net [12.123.153.38]
  6    28 ms    27 ms    27 ms  cr2.nwrla.ip.att.net [12.123.153.126]
  7    29 ms    27 ms    39 ms  cr2.attga.ip.att.net [12.122.18.1]
  8    27 ms    71 ms    26 ms  ggr3.attga.ip.att.net [12.122.140.149]
  9     *        *        *     Request timed out.
 10    34 ms    35 ms    36 ms  205.185.217.194
 11    35 ms    37 ms    36 ms  map2.hwcdn.net [205.185.216.10]

Trace complete.

C:\Users\Office>tracert bake-texture.agni.lindenlab.com

Tracing route to cds.i6j9r8g5.hwcdn.net [205.185.216.10]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     8 ms     7 ms     8 ms  10.188.80.1
  3    11 ms    14 ms    13 ms  172.30.78.177
  4    10 ms    12 ms    11 ms  172.30.32.69
  5    27 ms    25 ms    27 ms  cr1.nwrla.ip.att.net [12.123.153.38]
  6    29 ms    27 ms    30 ms  cr2.nwrla.ip.att.net [12.123.153.126]
  7    30 ms    27 ms    32 ms  cr2.attga.ip.att.net [12.122.18.1]
  8    44 ms    42 ms   102 ms  ggr3.attga.ip.att.net [12.122.141.145]
  9     *        *        *     Request timed out.
 10    37 ms    37 ms    38 ms  205.185.217.194
 11    32 ms    35 ms    33 ms  map2.hwcdn.net [205.185.216.10]

Trace complete.

Link to comment
Share on other sites
Sean Heying

Sean Heying

Posted
Posted

I concur it seems a little better. Might be in our minds though. Some mesh and rebaked skin after mesh is removed are the issue I still see - but at leasta lot of the world is rezzing. On the skin, on a bad night, I can be fully rezzed, someone removes a mesh TShirt and their skin blacklists due to timeout. I am positive I've seen those come from bake directly and not asset-cdn though.

 

 

To me those tracerts look good. Especially when you consider timeouts from Australia hit 3000ms+ and we still load.

The common thing we seem to be seeing is a timeout reached. I see it in V3, I see it in Firestorm, I see it in Alpha Singu and I see it in a few versions of Developer pre-alpha Singu... Thing is, adjusting any of the timeout values in debug or in code and recompiling makes little difference. 

A complex mesh with many vertexes (much larger file size) does seem to block the pipelines more. Looking at my advanced consoles show some mesh items are quite large in transfer size.

Picking Aleric's mind right now is ... difficult... curl gave him RSI. Although I am glad his changes for pipelining are moving slowly towards being merged into Singu. Those are a real speed boost over the non-pipelined code.

Packetloss maybe. I need to run an MTR over 5 minutes next time it happens here and look at how many packets are being lost. Maybe in peak times, when the packetloss is high, the design means that the curl's wait to long. Hit timeout and blacklist or retry (depending on what viewer)

Mind you, it could be between the asset server and regional CDN too. That is harder to debug considering we know so little about the back end architecture.

My investigations at least show my local CDN is in Japan. Pity as CA is actually faster to get to.

Link to comment
Share on other sites
Theresa Tennyson

Theresa Tennyson

Posted
Posted

Samual Wetherby wrote:

So sad.

No clue what Linden did yesterday & today but now having rez issues 24/7

Have done a clean re-install of FS 64bit.

Internet speeds are pretty steady at 96Mbs

Brand new Cisco DOCSIS 3.0 3010 Modem wiht 8/4 channels.

All 8 downstreams are bond and cooking right along according to Mediacom.

Mediacom has run test after test and only see an issue with Linden Labs CDN server data transfer.

Hmmm...

A single instance of Second Life running in its full default configuration will use more than eight connections at the same time - eight pipelined connections for mesh and textures, plus the UDP connection for location updates, etc. (the "old style" communication channel) and probably more for things like music, etc.

Link to comment
Share on other sites
  • Lindens
Monty Linden

Monty Linden

Posted
  • Lindens
Posted

DOCSIS channels are something below the IP layer.  They're analogous to choosing the type of Ethernet you want to use (10BaseT, 100BaseTX, 1000BaseT, etc.).  It's the multi-channel aspect of 3.X that makes near-GigE speeds possible between cable head and a customer's home.  Possible.

Concurrent TCP connections are a separate thing and should be more relevant to this problem.  Yes, the viewers (Linden and TPV) have been bad network citizens in this area.  SL has historically launched approximately 100 connections on login with a cold cache.  Some very, very bad advice in the community had people bumpting this up to over 500.  Current SL viewer is using 16 plus a number of utility connections, some persist, some do not.  I hope this number drops a bit more and one of the workarounds I suggested earlier dropped that 16 to eight.  It's effective in some cases (such as very low-end or buggy hardware), just not this one.

Work continues behind the scenes with positive results.  I wish I could say more and give a timeline but I can't.  There are other areas of experimentation possible in a search for an effective workaround.  All of the ones I mention below are fragile (subject to DNS changes, network changes, service provider not liking the interesting new traffic on his service, and users forgetting that they've played with things) and I don't recommend pursuing them.  But if you must and are confortable and familiar with these approaches, you might consider:

 

  1. DNS hacks.  Use a local HOSTS files to redirect CDN requests to a PoP in a different area.
  2. Proxy hacks.  The HTTP traffic in the viewer can be redirected to an HTTP proxy located in another country.
  3. VPN hacks.  VPN services are increasingly available with the goal of presenting a user as being in another country.  I've wanted to play with this myself for a number of reasons, just haven't had time.

 

Link to comment
Share on other sites
Samual Wetherby

Samual Wetherby

Posted
  • Author
Posted

Thanks Monty.

I've played with IP changes/hacks a few times recently per someone's advice.

It had mixed results as you are indeed throwing your connection to another IP address location and then accessing the CDN in that area. Results were some packet loss, longer timeouts and some retries to connect (websites and other various connections).

The plus was I seeemed to be accessing a better CDN server area and things were rezzing better, but the connection wasn't reliable for substained SL use and contant hammering for textures & data back and forth.

Think such hacks are best for those wishing to pirate download stuff or other malicious activities.

Link to comment
Share on other sites
Samual Wetherby

Samual Wetherby

Posted
  • Author
Posted

Another nite of issues.
Object textures seem to rez better but people don't and various items just disappear and don't return or time out by just turning around.


Some Log File Errors all back to back to back:

llcorehttp/_httppolicy.cpp(441) : 2015-04-21T03:58:23Z WARNING: LLCore::HttpPolicy::stageAfterCompletion: HTTP request 000000008B0E0B00 failed after 8 retries.  Reason:  Timeout was reached (Easy_28)
newview/lltexturefetch.cpp(2061) : 2015-04-21T03:58:23Z WARNING: LLTextureFetchWorker::onCompleted: CURL GET FAILED, status: Core_4 reason: Invalid Content-Range header encountered
newview/lltexturefetch.cpp(1670) : 2015-04-21T03:58:23Z INFO: LLTextureFetchWorker::doWork: HTTP GET failed for: http://asset-cdn.glb.agni.lindenlab.com/?texture_id=157bbb7a-5ede-cd24-0a48-04434f6fd5b5 Status: Core_4 Reason: 'Invalid Content-Range header encountered'
newview/lltexturefetch.cpp(1687) : 2015-04-21T03:58:23Z WARNING: LLTextureFetchWorker::doWork: 157bbb7a-5ede-cd24-0a48-04434f6fd5b5 mLoadedDiscard is -1, should be >=0
newview/lltexturefetch.cpp(1848) : 2015-04-21T03:58:23Z WARNING: LLTextureFetchWorker::doWork: Decode entered with invalid mLoadedDiscard. ID = 157bbb7a-5ede-cd24-0a48-04434f6fd5b5
newview/llviewerdisplay.cpp(234) : 2015-04-21T03:58:23Z INFO: display_stats: FPS: 44.50
llcorehttp/_httppolicy.cpp(441) : 2015-04-21T03:58:31Z WARNING: LLCore::HttpPolicy::stageAfterCompletion: HTTP request 000000008B0E1970 failed after 8 retries.  Reason:  Timeout was reached (Easy_28)
newview/lltexturefetch.cpp(2061) : 2015-04-21T03:58:31Z WARNING: LLTextureFetchWorker::onCompleted: CURL GET FAILED, status: Core_4 reason: Invalid Content-Range header encountered
newview/lltexturefetch.cpp(1670) : 2015-04-21T03:58:31Z INFO: LLTextureFetchWorker::doWork: HTTP GET failed for: http://asset-cdn.glb.agni.lindenlab.com/?texture_id=ae27b98d-3f67-f7b2-8f15-73474c17a1d5 Status: Core_4 Reason: 'Invalid Content-Range header encountered'


newview/llviewerdisplay.cpp(234) : 2015-04-21T03:58:33Z INFO: display_stats: FPS: 51.00

 

Good 3 hours of skin  texture and clothing failures... then 30minutes later, everything starts pop'n back in place. log shows no issues fetching or timeouts.

Without relogging since the rez issues started, I can now TP to any crowded sim and within seconds everyone and everything is rezzed. Even places I've never been before.

 

 

Link to comment
Share on other sites
Electra Spearsong

Electra Spearsong

Posted
Posted

Since last Wednesday's maintenance in Sl (April 15, 2015) my SL has deteriorated daily - worsening as the days go by. During the peak times between 6pm slt - 9pm stl I went ffrom three days of slow rezzing textures, and mesh not showing.

Tonight (April 20)  mesh never rezzed for me, it would take 5 minutes to rez just one avatar in the room, half of the people in the room I'd stand in are poofy clouds.  10 Minutes after I tp somewhere in Sl - the textures very slow come through for me. I've done everything - I have draw distance low, minimized everything I can - checked my router, modem ..checked with my internet provider and I have no clue what happened. It seems the issues are getting worse daily and I need to fix this!

 

Would love to know what exactly has been changed in Sl with the maintenance last week that it's creating things worse on my end to be in SL!

Link to comment
Share on other sites
Samual Wetherby

Samual Wetherby

Posted
  • Author
Posted

Tonight more of the same. except seems missing items when I turn around is back.

Various mesh items just vanish again.

More fetching and retry errors.

 

llcorehttp/_httppolicy.cpp(441) : 2015-04-22T02:42:10Z WARNING: LLCore::HttpPolicy::stageAfterCompletion: HTTP request 000000003038BC20 failed after 0 retries.  Reason:  Not Found (Http_404)
newview/lltexturefetch.cpp(2061) : 2015-04-22T02:42:10Z WARNING: LLTextureFetchWorker::onCompleted: CURL GET FAILED, status: Http_404 reason: Not Found
newview/lltexturefetch.cpp(1634) : 2015-04-22T02:42:10Z WARNING: LLTextureFetchWorker::doWork: Texture missing from server (404): http://asset-cdn.glb.agni.lindenlab.com/?texture_id=9870cb36-2559-16a7-213b-c1e1dc2e4488
newview/llviewermedia.cpp(423) : 2015-04-22T02:42:11Z INFO: LLViewerMedia::updateMediaImpl: called, current URL is "data&colon;text/html,XUNBQAofHEZO", previous URL is "", update_from_self is true
newview/llviewertexturelist.cpp(1598) : 2015-04-22T02:42:11Z WARNING: LLViewerTextureList::processImageNotInDatabase: not in db
newview/llviewertexture.cpp(2239) : 2015-04-22T02:42:11Z WARNING: LLViewerFetchedTexture::setIsMissingAsset: 9870cb36-2559-16a7-213b-c1e1dc2e4488: Marking image as missing

Link to comment
Share on other sites
Samual Wetherby

Samual Wetherby

Posted
  • Author
Posted

Day 75
Had Mediacom out yesterday again. Luckly taking pitty on me.
Everything at the house and area load test well above normal with no issues.
Yet nightly during peak internet, still having Second Life fail fetching and numerious retries only to time out.

Whole thing is very depressing.

Link to comment
Share on other sites
You are about to reply to a thread that has been inactive for 3263 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share
Go to topic listing
×
×
  • Create New...