Jump to content

Odd network problem (pathfinding???)


Vulpinus
 Share

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

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

Recommended Posts

I've been experiencing this issue for  at least six months. No idea if anything changed to bring that about, but I've just discovered that it isn't caused by what I always assumed.

The issue

My internet bandwidth sometimes (often enough to cause problems) gets saturated by SL. I have ADSL and achieve 18Mbps downstream and 1Mbps up. I've just speedtested that and it is almost exact; it's a good connection. By saturated, I do mean completely max'ed out downstream and close to it upstream. I have a bandwidth monitor running. This can persist from anything from momentarily, up to a minute! When it happens, it seems that any control input or positional changes coming back are stalled while whatever is being sent/received.

When this happens, I can hardly move and (if sailing/trying to sink pirates, which is what has caused me to start investigating) I can be on the other side of the sim before the viewer catches up with that and I get control back. Most often that means I'm dumped off the boat. It's happened six times in the last 30 minutes. It is nothing to do with sim crossing; I wasn't, and it's not limited to sailing.

I can quite easily provoke the above, but it's more of a problem when it happens in a place that I'm sure it shouldn't. I spent half an hour this morning walking around the combat area in Blake, filling my cache. Despite that, I got the saturation when sailing over places I had already been.

When it happened before I assumed I had got too close to an island and suddenly got a load of texture data, but no. I was in the middle of a water sim with just a few mer homes beneath! The saturation lasted five to ten seconds, long enough to wreck my sailing. I did notice that on some occasions a new avatar or boat was on the radar, but other than that I was practically alone on the seas. I was practicing with my new boat while it was quiet.

My incorrect assumption

I previously assumed that the issue was the asset servers being really efficient (we can wish) and sending me all the new texture and object data so fast that I was overloaded. If so, then I thought it was a bit of a problem in the system to allow that to override control input and avatar movement etc. but still. I even thought of buying a faster internet pipe.

However... the above does not seem to be the case, now that I have spent an hour watching the statistic panel.

Instead, when I get saturated, the data rate for textures and objects actually drops, and is in any case well below my 18Mbps; barely half that at most, from what I saw. A few hundred kBps each, well short of my roughly 2MBps available.

What I did see rising a lot, in every saturation instance, was under the Pathfinding section.

I've attached a screenshot of the stats panel. It was actually taken when I went to the Cosmo shopping place, a good place to get hit by a ton of texture for testing these things. I was saturated, unable to move, and yet the texture and object data was minimal. It was typical of, if perhaps a touch worse than, the instances of this in the middle of the sea.

I also noticed that I have 1.5% lost UDP packets. My limit is set at 1500kbps. I have never, in all the time I've been here (longer than this account!), seen any dropped packets before.

Concluding thoughts

I have no idea if the pathfinding thing really is anything to do with what's happening. If the numbers there do relate to real network use, then it seems to be.

I need to get to the bottom of this. It's really killing my fun sinking pirates, which I've just got into. I've always put up with the issue before.

Is there anything else I can look at to shed light on this? Or any suggestions?

Points to note

My LAN uses a Cisco 1841 router and 3560G switches; I'm Cisco certified. It's far more capable than what most people probably use on SL and it isn't the problem. I also checked my router log and real-time stats while all of this was happening. It wasn't even getting warm. I have, of course, tried resetting everything, just so I could say I have.

Oh, and I know my draw distance is set quite high (shown below) but I usually have it around 160m.

Firestorm 4.7.7 (48706) Mar 5 2016 00:13:45 (Firestorm-Releasex64) with OpenSimulator support
Release Notes

You are at <redacted>
SLURL: <redacted>
(global coordinates <redacted>)
Second Life RC BlueSteel 16.06.03.316139
Release Notes

CPU: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (3392.3 MHz)
Memory: 16368 MB
OS Version: Microsoft Windows 7 SP1 64-bit (Build 7601)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 970/PCIe/SSE2

Windows Graphics Driver Version: 10.18.0013.6510
OpenGL Version: 4.5.0 NVIDIA 365.10

RestrainedLove API: RLV v2.8.0 / RLVa v1.4.10a
libcurl Version: libcurl/7.38.0 OpenSSL/1.0.1i zlib/1.2.8
J2C Decoder Version: KDU v7.7.1
Audio Driver Version: FMOD Ex 4.44.61
LLCEFLib/CEF Version: 1.5.3.FS6-(CEF-WIN-3.2526.1366.g8617e7c-32) (Chrome 47.0.2526.80)
Voice Server Version: Not Connected
Settings mode: Viewer 3
Viewer Skin: StarLight (Mono Teal)
Font Used: Deja Vu (96 dpi)
Font Size Adjustment: 0 pt
UI Scaling: 1
Draw distance: 688 m
Bandwidth: 1500 kbit/s
LOD factor: 4
Render quality: Ultra (7/7)
Advanced Lighting Model: Yes
Texture memory: 1024 MB (1)
VFS (cache) creation time (UTC): 2016-4-24T5:42:58
Built with MSVC version 1800
Packets Lost: 2,575/239,482 (1.1%)



ETA: Just to clarify... when my line gets saturated and the texture and object data rate drop, the connection is still saturated. Something in the system is taking that data, and there's a lot of it (3GB this morning really just to SL), but it doesn't seem to be texture/object data.

When I'm saturated everything in-wolrd is basically stalled. Even HUDs are almost completely unresponsive. At least, it seems that way. When the saturation event is over, I think things suddenly catch up and often go totally haywire if I was sailing. Dumped off the boat, boat upside down or flying, can't move properly as if still seated but can't stand... total nuts. Other times, I just suddenly time-warp across the sim and can carry on. It's like the worst ever sim crossing, without crossing sims (at least not while I'm in control).

Link to comment
Share on other sites

I'll try staring at the rest of this, but just for the sake of your sanity: Pathfinding has nothing to do with what you're experiencing. The label you see there is actually a section heading, and if you click on it you'll get the statistics relevant to Pathfinding. The numbers you see are just overall network traffic data. [ETA: "overall" traffic for the whole sim, not just your viewer.]

Link to comment
Share on other sites

So those particular statisitcs are from an extremely heavily-loaded sim. Anybody on it would experience script lag (HUDs working slowly if at all, etc) and network delay. I gather you have trouble on other, less busy sims, too, but it will be difficult to diagnose what may be causing that more general condition from data overwhelmed by local sim load.

Link to comment
Share on other sites

Yeah, fair point. I'll go back to the Blake sim tomorrow, when it's quiet again, and grab another screen shot when it happens.

All of what I said though was about the quiet water region I was in. Only me and one other avatar most of the time. I just wondered what the stats panel would show if I went to Cosmo where I knew there was a lot of texture data to load that I hadn't already cached, and that's when I thought of a screenshot.

ETA: Oh yes, I see what you mean about the Pathfinding being another heading. I thought it was the heading for the data below it in the screenshot. D'oh!

 

Link to comment
Share on other sites

I went out to a few more watery places that were failry quiet, and got the same thing a few times. Here are some screen shots of three instances, all in different sims, all with my bandwidth monitor bit inserted. Some were near sim boundaries but the last one was smack in the middle of an empty water sim (I might still have been picking up data from outside the sim of course)

Again, all show very little network usage and yet my bandwidth is pegged at max and everything is unresponsive. All of these were survivable though; after the event I was able to continue despite some jumping around on screen.

Is there something that the stats panel doesn't show, network-wise? Am I looking at an excerpt of what it's actually doing? In other words... where on Earth is that 18Mbps going?



Link to comment
Share on other sites

check your logs and have a nosey

i have done some pretty extensive mainland travel trying to win this cup thingy and I know what you meaning

sometimes the viewer cant resolve assets in the view/camera interests list, so it keeps requesting them. Can be 1000s of requests for the same few things flooding your network (and also writing to the logs when turn all on)

you mention that your draw distance is 160m. When so it puts the bordering sims into range of the draw distance, the assets on which affect the updating of the interest list. The pain comes when the asset downloads every time requested. The viewer cant resolve it (the asset(s) is corrupted in some way) Request again. Another download and a infinite cycle of doom

the size of each download is relative small but is relentless and quickly adds up to megabytes in just a few minutes

it happens on some other continent water edge sims as well as the Blake

+

i end up put it down to some of the very early made sculpt tree products (when people were first learn how to make sculpts) that are typical of water/beach edge sims. I was never able to work out exactly which assets they were tho

so just end up moving past the sims I got affected the most, on the farest away side so that they would not be in my draw distance, and/or interests list, or if so then at least as minimal impact as I could manage

Link to comment
Share on other sites

Hmm... interesting, thanks.

The issue has happened every time I've been in Fanci's Deep, over the last four days, except today. Today I had my log tailed so I could spot what was logged when the issue happened. Perfect sailing for an hour now. It knows it's being watched. Grrr.

The thing is the sims are used very regularly for battles etc. If the issue was something that effected everyone the way it does me, there would be a lot of fuss about it. There isn't, so it's clearly just me. Again. It happened twice in a twenty minute battle on Tuesday - everyone else was fine.

I'll keep watching the log - it'll happen again.

Do I need logging set to debug level to catch what you saw, or will info do?

Link to comment
Share on other sites

Well, I got that to happen again easily. Started at Half Hitch and sailed (then just flew) due East. Nothing in front of me except more, almost empty, water sims. First and third time, the saturation happened after I had crossed into Binnacle heading East (but well after the crossing - nothing to do with that). The middle time it happened as soon as I tried to move from my TP point on Half Hitch (the jetty). I tried to fly up to start off, and just froze for ten seconds. Then suddenly appeared high up in the air near the sim edge.

The saturation happened on three consecutive relogs (I killed the viewer to freeze and copy the log near the point of interest).

On subsequent tries, the issue did not happen, and I could not provoke it again by sailing around for fifteen minutes. Even approaching heavily populated islands with lots of builds and textures didn't raise my bandwidth use much. It seems the saturation really is something odd going on.

I had debug level logging for this, but I've not seen anything obvious yet that is consistent across them all. Not that I know what I'm looking for in 3MB of text.

Link to comment
Share on other sites

i had a look at Half Hitch with Debug setting enabled for logging

only thing that jumped out was:

2016-06-23T11:35:02Z WARNING:#CoreHttp LLCore::HttpPolicy::stageAfterCompletion: HTTP request 2DACA8E0 failed after 8 retries. Reason: Timeout was reached (Easy_28)

2016-06-23T11:35:02Z WARNING: LLCoreHttpUtil::HttpCoroHandler :: onCompleted:

 --------------------------------------------------------------------------

Error[Easy_28] cannot access url 'https : // sim9231 . agni . lindenlab . com : 12043/cap/8f410657-ff9e-e7a2-9fa9-2a8c22cf978d' because Timeout was reached

--------------------------------------------------------------------------

2016-06-23T11:35:02Z INFO:#LLEventPollImpl LLEventPolling :: Details::LLEventPollImpl::eventPollCoro: All is very quiet on target server. It may have gone idle?

 

+

it might be that this is a cause for you. Dunno exactly what the cost of this might be at your end. Check your logs and see if you getting the same

+

eta: spc

 

Link to comment
Share on other sites

Thanks. I don't see those in my three logs though. There is a handful of 404 errors, but that's not going to be sending me data.

I do have a lot of these, as in hundreds by the looks of it in one log especially:

llmath/llvolume.cpp(2417) : 2016-06-23T06:56:57Z DEBUG:#MeshStreaming LLVolume::unpackVolumeFaces: Failed to unzip LLSD blob for LoD, will probably fetch from sim again.
llcommon/llsdserialize.cpp(2203) : 2016-06-23T06:56:57Z DEBUG: unzip_llsd: Unzip error: !Z_STREAM_END

llmath/llvolume.cpp(2417) : 2016-06-23T06:57:00Z DEBUG:#MeshStreaming LLVolume::unpackVolumeFaces: Failed to unzip LLSD blob for LoD, will probably fetch from sim again.
llcommon/llsdserialize.cpp(2168) : 2016-06-23T06:57:00Z DEBUG: unzip_llsd: Unzip error: -3

It's hard to tell where the problem starts in the logs. Tailing it doesn't help because it all flashes past far too quickly to read. All I've been going on is finding my 'quit' notification and going backwards. Also, I guess that the saturation problem could cause a lot of other potential errors, like timeouts, to show. So, what I'm looking at might just be a symptom, or not even relevant at all.

I've just been back again, and tried with an alt, but had no problems at all this time. I did notice that even when I suddenly see a new, built-up area, and my bandwidth use goes up as the data is pulled, it doesn't quite look flat-topped like when I have the saturation issue. Instead it still shows a little movement around the top and I still have some degree of control. When the saturation happens, there's no control at all until it's over and there isn't necessarily any obvious source of new data.

Link to comment
Share on other sites

The plot thickens...

I've just been doing target practice in Fanci's Deep again. Things seemed to be going smoothly so I logged in my alt to shoot at on another PC (and even a different public IP address, but sharing the same ISP subnet service).

Things were fine for twenty minutes or so, sailing around all four regions and shooting, then the saturation issue suddenly hit again. My alt was static, just a target for me, moored near the middle of all four regions. I had entered the same region (ETA: welll inside by the time the issue hit, nothing to do with the crossing) and just fired a volley, and a moment later I realised I had lost control. The bandwidth monitor on both PC's was pegged - about 9Mbps each, sharing the 18Mbps. Odd that the static alt even got hit by this. My boat was just careering across the region without a care in the world. Exactly the same as before.

I grabbed a copy of the log at that point, before even quitting FS, and I've uploaded it in case anyone cares to have a look. I took an excerpt of it from the point I entered the region before the incident. The log ends when I copied it; it's only about 80 lines. Perhaps ten to fifteen seconds delay from the onset of the issue to actually getting the copy of the log. Hard to say exactly because I had to faff a bit to get the copy.

I cannot see anything in there that looks odd. I did notice what looks like an avatar arriving somewhere at possibly around the time the issue started.

Link to comment
Share on other sites


Vulpinus wrote:

 

I do have a lot of these, as in hundreds by the looks of it in one log especially:

llmath/llvolume.cpp(2417) : 2016-06-23T06:56:57Z DEBUG:#MeshStreaming LLVolume::unpackVolumeFaces: Failed to unzip LLSD blob for LoD, will probably fetch from sim again.

llcommon/llsdserialize.cpp(2203) : 2016-06-23T06:56:57Z DEBUG: unzip_llsd: Unzip error: !Z_STREAM_END

llmath/llvolume.cpp(2417) : 2016-06-23T06:57:00Z DEBUG:#MeshStreaming LLVolume::unpackVolumeFaces: Failed to unzip LLSD blob for LoD, will probably fetch from sim again.

llcommon/llsdserialize.cpp(2168) : 2016-06-23T06:57:00Z DEBUG: unzip_llsd: Unzip error: -3


Did you mean to enable Debug level logging?  This can slow the viewer down quite considerably.

I'm not 100% sure but to me those log lines seem to indicate a corrupted mesh download.

On a hunch, if you disable HttpPipelining (set the debug setting HttpPipelining to FALSE), does the problem go away?

If this does not help, set HttpPipelining back to TRUE again.

If disabling Pipelining helps, which firewall & antivirus software are you using?

If it normal for your ping sim reading to be over 600 ms?  (as shown in your stats).

Link to comment
Share on other sites

Hi Whirly, just a few quick answers before I head for bed:

Yes to debugging level - I wasn't sure how much the lower level gave. It didn;t make anything worse about the issue I was seeing.

There were lots (hundred or more) of those lines in the log.

I'll try what you suggest tomorrow and see what happens. I had the issue again this evening in Fanci's deep during a battle, but only once. I ended up two sims away in a few seconds.

I do not use an anitvirus; none is installed. I only do out-of-band full scans occasionally if I feel the need, from a safe disk. My personal firewall is Windows 10 Firewall Control (I'm on Windows 7 - ignore the name). It's really good and I've used it for over a year. I might try disabling it temporarily though for some testing, just in case. Other than that my Cisco router is programmes with a stateful firewall and basic filtering. Nothing that would interfere here.

I doubt that 600ms is typical - I've never noticed it that high. I bet that was due to the saturation issue. I'll keep an eye on it though.

Right - bed time :)

 

 

Link to comment
Share on other sites

that looks promising

when stuff happens way out in the middle of nowhere then I pretty much always start to wonder if what I am on or wearing or doing in terms of rezzing stuff, is lagging myself. Like there is maybe something now broken in terms of my own assets   

Link to comment
Share on other sites

A bit of testing this morning. I went naked (apart from an alpha layer :D ). Firstly, the event seems hard to catch today. Typical. It knows it's being watched. Still...

Fanci's Deep: One brief (few seconds saturation) event after being there about 30 minutes. Might have been linked to an avatar arriving.

Then I turned off HTTP Pipelining (Am I correct pipeliining re-uses http connections, instead of keep closing and opening new ones?)

Took a while, but I eventually had another couple of events. I got logs of all of the events in the middle/end of them. Not really sure if these are the same event, they seemed to happen around region crossings, but I think that's just coincidence because they seemed the same.

The last one, I was practically in the middle of nowehere. I got logs in the middle and a few seconds after it finished, and a screenshot.

The screenshot shows the same as before: almost no activity in the stat's network panel, but saturated internet. Also note the sim ping! My sim ping until this was around 170ms - that seems a typical value for me.

I also got the log off my other PC from when the event happened to both alts simultaneously yesterday. Can't see anything likely in it, but it wasn't set to debugging level. Thinking about it, neither are today's - I forget I had to turn it on every restart.

-----

If anyone would like top see all these logs, I think the best thing is to upload them to a folder on my web server. I don't want to put the URL here, but please ask and I'll PM you the details. I won't just PM it to people without them asking - I don't want to assume.

 

The screenshot:



Link to comment
Share on other sites

Just thought to mention that those 'MeshStreaming / Unzip" errors don't seem to occur significantly in other logs - probably a red herring.

I do see this a lot in the logs:

llcorehttp/_httppolicy.cpp(441) : 2016-06-23T14:27:07Z WARNING:#CoreHttp LLCore::HttpPolicy::stageAfterCompletion: HTTP request 00000000745241A0 failed after 0 retries. Reason: Not Found (Http_404)
newview/lltexturefetch.cpp(2064) : 2016-06-23T14:27:07Z WARNING:#Texture LLTextureFetchWorker::onCompleted: CURL GET FAILED, status: Http_404 reason: Not Found
newview/lltexturefetch.cpp(1637) : 2016-06-23T14:27:07Z WARNING:#Texture LLTextureFetchWorker::doWork: Texture missing from server (404): http://asset-cdn.glb.agni.lindenlab.com/?texture_id=ba1f763d-7133-28a1-acda-abd4ffede083
llcorehttp/_httppolicy.cpp(441) : 2016-06-23T14:27:08Z WARNING:#CoreHttp LLCore::HttpPolicy::stageAfterCompletion: HTTP request 00000000745233E0 failed after 0 retries. Reason: Not Found (Http_404)
newview/lltexturefetch.cpp(2064) : 2016-06-23T14:27:08Z WARNING:#Texture LLTextureFetchWorker::onCompleted: CURL GET FAILED, status: Http_404 reason: Not Found
newview/lltexturefetch.cpp(1637) : 2016-06-23T14:27:08Z WARNING:#Texture LLTextureFetchWorker::doWork: Texture missing from server (404): http://asset-cdn.glb.agni.lindenlab.com/?texture_id=c0021169-1c14-8547-4132-d0508387afc7

But again it might not mean anythig related to the problem. Whatever that is, it causes a sudden and sometimes sustained flood of incoming (and outgoing, probably mostly syn and ack type of stuff) data without it showing on the stats panel.

Link to comment
Share on other sites


Vulpinus wrote:

 

I do have a lot of these, as in hundreds by the looks of it in one log especially:

llmath/llvolume.cpp(2417) : 2016-06-23T06:56:57Z DEBUG:#MeshStreaming LLVolume::unpackVolumeFaces: Failed to unzip LLSD blob for LoD, will probably fetch from sim again.

llcommon/llsdserialize.cpp(2203) : 2016-06-23T06:56:57Z DEBUG: unzip_llsd: Unzip error: !Z_STREAM_END

llmath/llvolume.cpp(2417) : 2016-06-23T06:57:00Z DEBUG:#MeshStreaming LLVolume::unpackVolumeFaces: Failed to unzip LLSD blob for LoD, will probably fetch from sim again.

llcommon/llsdserialize.cpp(2168) : 2016-06-23T06:57:00Z DEBUG: unzip_llsd: Unzip error: -3


I just checked my own debug level logs & I have lots of these too, so unless I have a problem I don't know about, I'd say its normal logging at debug level.

Link to comment
Share on other sites


Vulpinus wrote:

 

I do see this a lot in the logs:

llcorehttp/_httppolicy.cpp(441) : 2016-06-23T14:27:07Z WARNING:#CoreHttp LLCore::HttpPolicy::stageAfterCompletion: HTTP request 00000000745241A0 failed after 0 retries. Reason: Not Found (Http_404)

newview/lltexturefetch.cpp(2064) : 2016-06-23T14:27:07Z WARNING:#Texture LLTextureFetchWorker::onCompleted: CURL GET FAILED, status: Http_404 reason: Not Found

newview/lltexturefetch.cpp(1637) : 2016-06-23T14:27:07Z WARNING:#Texture LLTextureFetchWorker::doWork: Texture missing from server (404):

llcorehttp/_httppolicy.cpp(441) : 2016-06-23T14:27:08Z WARNING:#CoreHttp LLCore::HttpPolicy::stageAfterCompletion: HTTP request 00000000745233E0 failed after 0 retries. Reason: Not Found (Http_404)

newview/lltexturefetch.cpp(2064) : 2016-06-23T14:27:08Z WARNING:#Texture LLTextureFetchWorker::onCompleted: CURL GET FAILED, status: Http_404 reason: Not Found

newview/lltexturefetch.cpp(1637) : 2016-06-23T14:27:08Z WARNING:#Texture LLTextureFetchWorker::doWork: Texture missing from server (404):

But again it might not mean anythig related to the problem. Whatever that is, it causes a sudden and sometimes sustained flood of incoming (and outgoing, probably mostly syn and ack type of stuff) data without it showing on the stats panel.

Those log warnings are normal there.  Those textures are missing from the server.

If you click on the links it will tell you "texture not found".  If the texture did exist on the server, that link would download the texture to your computer.

For example, this one works: asset-cdn.glb.agni.lindenlab.com/?texture_id=21f32d0b-87c3-be62-f3c9-b9fe38427ae6

Link to comment
Share on other sites


Vulpinus wrote:

I went
naked
(apart from an alpha layer
:D
)

jejejeje (:  wearing our most see thru outfit can be quite appealing sometimes (:

+

i think might be time to run something like Wireshark and try to discover the source/destination of the saturation packets

testing with and without SL running

 

Link to comment
Share on other sites

Hmm. I've been trying to avoid having to put wireshark onto it, that's too much like being at work. It has been in the back of my mind though.

I'll wait until I'm in the mood for some packet sifting, and I've had a little more sleep and less rum :D

 

Link to comment
Share on other sites

I've just grabbed a capture while a good, solid saturation event happened. Only took a minute for it to hit this time.

It seems the CDN server I get connected to is on my own ISP's network! Wireshark revealed most of my traffic for SL is directed to my own ISP's IP range. A DNS lookup confirms that the CDN server's url goes there. That should be a good thing for me!

A good third of all the packets I captured had LL servers' IP addresses, and marked as 'GVSP' protocol. What is LL using that for? I don't think that's anything to do with my problem though from the distribution and size of the packets. They tended to occur in bursts, then none for a while, then another burst.

A tiny fraction of the packets were small UDP packets.

That leaves almost entirely TCP packets between the CDN server and me. A quick count for just one second during the saturation gives numbers that fit, a bit over 2MB per second. Mostly full (1514 bytes) incoming packets and outgoing ACKs.

The vast majority of http headers showed most of the requests and data were for mesh objects, with hardly any for texture (in fact, none in that second I counted over). For example:

GET /?mesh_id=0dbb6642-c6cd-58ae-7f68-b993b17426a0 HTTP/1.1 GET /?mesh_id=1f4bdb20-b7e4-acca-e319-df8a79c4db31 HTTP/1.1

Given that I have been around that area (Fanci's Deep) a lot recently, all the textures should be cached.

I could not see anything in the capture that indicated anything unusual, just loads of data. Over the entire time of the saturation, the capture looked like this. I'm going to go though it in a bit more depth but on the face of things it looks simply like the CDN is suddenly sending me big bursts of data for mesh.

I'm still suspicious about why this can happen in the middle of nowhere, yet doesn't necessarily happen when tp'ing somewhere completely new with loads of new mesh to look at. Sometimes it does happen, in busy places, but not always.

That saturation clearly (on my system at least) causes control input and viewer updates to practically cease, I guess as the different data streams contend for access to the overloaded internet connection. Even trying to quit the viewer takes a lot longer than normal. IF this is the answer to it all, then it's something that needs addressing to prioritise traffic differently.

And why oh why is none of this shown on the statistics panel??? It shows almost no incoming data when this happens.

Link to comment
Share on other sites

It's just occured to me that there's a mesh concurrency setting in the debug settings. I might try turning that down and see what happens.

Maybe it's because I'm so closely connected to the CDN server... and a dozen other random thoughts ;)

Link to comment
Share on other sites

There are 2 debug settings for mesh concurrency.

Mesh2MaxConcurrentRequests is the one you want to change.

MeshMaxConcurrentRequests is no longer used.

I'm not 100% sure, but I think MeshMaxConcurrentRequests will only work if MeshUseGetMesh1 is set to TRUE. I really don't think you want to mess with either MeshUseGetMesh1 or MeshMaxConcurrentRequests though.  I'm not sure if the back end support for MeshUseGetMesh1 is even working now.

You can also lower the maximum number of HTTP connections used for texture fetches with TextureFetchConcurrency.

Lower this to 4 or even 2 (Default is 0, which actually is 8, I don't know why default shows as 0 in debug -  maybe 0 is "unlimited" & the default of 8 is set elsewhere).

 

Link to comment
Share on other sites

Are you still having the problem you talked about here too? https://community.secondlife.com/t5/Second-Life-Viewer/TP-ing-and-texture-thrashing-in-Firestorm/m-p/3023219#M27191

I'm curious if the 2 problem could be related.

The texture thrashing itself isn't odd - though in the locations you gave me to test, I really don't think you should have been seeing texture thrashing with texture memory set at 1024 on Firestorm.

The odd part of that problem is that the thrashing is fixed by a double click teleport.

Link to comment
Share on other sites

Thanks Whirly, yeah I figured out which concurrency setting it was; the new one for pipelined http. I set it 1, and still got the saturation issue on another trip to Fanci's deep; a good 6-8 seconds of it when I moved a few metres from the tp point I use every time, 12MB of data.

Of course if the server can send data that fast for one http request then one or a hundred makes no difference.

All the textures there should certainly be cached so I doubt it was textures causing the saturation, and my previous wireshark capture showed hardly any texture get requests compared to mesh. I will try setting the texture load concurrency tomorrow and see what happens. I wasn't running Wireshark this time but I will tomorrow.

Something has just now occured to me... Fanci's deep is full of older sculpted things underwater (AleyMart stuff). I just wonder if that's why I seem to get hit so badly by the saturation when there. Would sculpts be retrieved with an http get 'mesh'? (I don't know if prims are treated differently to uploaded mesh.)

That said, I do get it a little in other places too; even going back home.

...

Yes, I still get the texture thrashing, although not as frequently recently, possibly due to a change in my pattern of movement. I had wondered if they were related somehow, too. ETA: Having said that, I have not had the two things happen at the same time.

I agree about the thrashing being odd in those locations with my usual view distance; that's partly why I eventually mentioned it. I've been to far, far worse places and not had it.

I think it is any teleport that stops the thrashing, rather than specifically a double-click tp. Certainly I still do the same trick and it still works. I'm guessing that the tp event causes some change in the texturing process, like restarts it or something.

 

 

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2795 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

×
×
  • Create New...