HTTP Texture Festching: Why do I get told to turn it off?

[WolfBaginski Bearsfoot]

The HTTP method of sending data has been around for a long time, and should be, with open source and everything, be thoroughly understood, debugged, and reliable. It was introduced in SL for texture delivery, with the claim that it would avoid many of the problems with the methods previously used. These didn't have mechanisms to detect errors or dropped packets, leading to all sorts of texture problems.

Yet it now seems that the standard answer to texture problems is to turn off HTTP Texture Fetch.

I suppose that part of the reason it might work is that it sets the flag to Clear Cache before the next login  And I do remember that there seemed to be some problems in the early days. But it frequently gets blamed for slow texture delivery and low frame rates. The reasons for slow texture delivery might be general net congestion affecting the handshakes needed for each file sent, but I can't see an obvious connection to low frame rate.

Is the HTTP being unfairly blamed. because of memories of long-gone problems?

Or is there some incompetent programming deep inside the Viewer or Server code? I've also heard a few stories over the years, about the pitfalls of multiple threads and other programming esoterica, and i don't pretend to understand them. But it does occur to me that a choice made before HTTP was introduced could now be sub-optimal. Not incompetent programming in itself, but perhaps a failure to realise the effect of accumulated changes.

 

 

[161488303349]

HTTP uses more datablocks to send/acknowledge textures than UDP overall. Is not the frame rate that affected so much as time taken to complete transfer over network. So if you have a slow network connection like dsl or wifi then can improve the speed at which (the whole image) data is transferred if switch HTTP off.

But, UDP not have transfer checking as good as HTTP so can mean that sometimes the texture never completely arrive and will stay blurry or even grey.. 

[Void Singer]

actually the main reason for using http get wasn't error correct, but rather so that the web standard for image transfer could be used, enabling external hosts to the current system (and possibly to be opened up in the future for other uses)

 

there does seem to be a bit of bugginess in their code though as larger textures or large masses of them seem to get cut off before finishing, and sometimes before starting. what end that bug is on i'm not entirely sure, but it appears in both official and TPV clients to varying degrees.

[Nalates Urriah]

Some months ago Linden Lab started changing image/texture transfer from UDP to HTTP protocol. Initially it was much faster. As more and more V2 viewers have come on line it seems to be slowing down. I suspect some overloading of the LL Utility Servers.

I can speculate on what may be happening. A few weeks ago the topic came up in an office hour meeting and some comments were made by Lindens that there were some network problems in the internal network and routing. I suppose that internal network is what connects the servers together for internal communication. Whatever, they were looking for the problem. I think that was when I was having lots of problems with texture rez speed.

If I remember and if I understood correctly prior to the change to HTTP the UDP texture distribution was handled by the simulators. I think they were caching the images/textures. So, the sim server only had to make a request and then continue handing out the texture to everyone coming into the region.

With HTTP they were working to unload the simulators. Texture requests bypass the sim server and go directly to a utility server.

The utility servers and the inner network are probably not as well optimized for the new HTTP process as the older UDP process is/was. Given time it probably will be. It may be possible that as the UDP is replaced hardware is changed over to handle more HTTP requests. So, it may simply be a capacity problem at LL.

By turning off HTTP Get and dropping back to UDP you may be accessing a system with less demand on it. If so, that is why it works better. In the long run UDP will likely be discontinued.

Probably the best solution is to find a JIRA on the issue and click WATCH on it. If you can’t find one, file your own.

I expect things to improve. Several of the people working on mesh issues are now shifting over to server maintenance work. Those working on Serv-Maint say it will be mostly about fixes and performance.

[Ayesha Askham]

@Nalates

You talk about this topic as though it is a minor inconvenience.  To some folk it is a major roadblock in their enjoyment of SL.  It is not the load placed on the servers by v2 alone that is causing this, it is the fact that a certain popular v1 viewer, called Phoenix also uses HTTP get, and so do several others.

Now as I read your post, it seems to me that a serious underestimate of the load likely to be placed on the servers was made some time ago, and in the rush and push to get Mesh out onto the grid it was almost forgotten.

This is a prime example of technologists working to put new features into a system they simply don't use, or understand.

So, once Mesh is out they will (maybe) get round to fixing a broken feature?  Gee, wow! Thankyou.

So a feature in broken....never mind look at this new "shiny"...do they never learn?

[WolfBaginski Bearsfoot]

I'll agree that there have been previous occasions when new stuff has fallen over after Phoenix has picked up the code. Display Names come to mind as an instance.

They ought to know how many people are using the different Viewers, so why do they get taken by surprise? 

[Rhys Goode]

I had been experiencing issues using FireStorm, and they got substantially better with HTTP textures off. 

But I recently discoverd that my WiFi connection has sporadic issues with high packet loss, especially after TP when there is a lot of info being downloaded.  Using an ethernet cable, I see hardly any packet loss, and today I turned HTTP textures back on.  It works fine now.  I think that the protocol is inherently more sensative the packet loss than UDP.

[WolfBaginski Bearsfoot]

I keep coming across various reports, in JIRAs and elsewhere, of HTTP connections with Linden servers returning strange error messages, possibly killing all further communication between Viewer and the particular server.

I've also found references to the overheads of using HTTP to obtain an item. Each request is a new connection, and has to negotiate a new session.

This could be messing up a lot of different things. And the latest Viewers are doing more than ever before with HTTP. Sp, for the same end result, there are far more data packets being exchanged and the computers at both ends are doing more exchanges of data. Here I am in the UK, with a ping time of typically 240ms, and that seems to be more than a second of extra waiting for each HTTP request. The data I want takes maybe 10ms to transmit, the extra waiting from HTTP handshaking is around 1000ms, and the limits on parallel HTTP connections will leave a lot of dead time.

I've had two, maybe three, slow deaths today which could be down to HTTP errors blocking the connections to servers (things such as a crash-on-TP failure, and neighbouring Sims vanished seem to be symptoms of this). I've been accused of not responding to IMs. And some people seem to think these errors aren't happening.

That last isn't surprising, and I can't blame the Lindens for being reluctant to talk about this pattern of errors. But we can see the JIRA system, and there are long-standing bugs associated with these errors which seem not to be solved and not being worked on. Things like no fix, nobody assigned to work on it, and the last triage review being two years ago.

It's a few months before my Premium payment next comes due, Will SL start working better (Mesh isn't good or bad in this context)? I suppose it might.

And maybe the horse will sing. 

[Ayesha Askham]

@ Wolf

I will try to be careful how I word this, since I seem to have got badly up Void's nose elsewhere in this Forum. 

Being in the UK as well, I don't see pings as high as yours unless there's an issue, more typically 120-200ms.  However, just lately I have had a large nuber of TP errors, mainly simply resulting in failed transfers, but some resulting in log-outs.  In some cases SL clearly "loses" me, since I am at home on relog, more often than not with a reversion in state of scripted items.

Texture transfer is certainly slow, rebakes are even slower and occasionally I even have some chat lag.  No packet loss however...odd.

Now in time-honoured fashion I have reset router and modem, checked connection speed etc, all to no avail, even rebooted my PC.  None of these remedies make the slightest difference.  The issue comes and goes as it pleases, or so it seems.  Some time-served SL inmates seem to be convinced that LL is at the bottom of this, or rather their servers are, the others, most often seen in these pages, think otherwise, so I must fall back on my own experience.

I am left largely none the wiser by all this, but on the whole, Wolf, I have to say that your experience is not by any means unique, but it is irritatingly, if understandably, unaddressed.

[Domitan Redenblack]

There are hundreds of bugs in SL now, that are totally ignored by LL et al, in favour of new stuff with bugs.

Texture loading suddenly seems much much less reliable in the last week or so...

Why? Is this human nature, or bad bad bad management at Woob Woob Labs?

imho: LL are the Three Stooges of coporate management...
Woob woob woob woob °͜°

 

[Domitan Redenblack]

There are hundreds of bugs in SL now, that are totally ignored by LL et al, in favour of new stuff with bugs.

Texture loading suddenly seems much much less reliable in the last week or so...

Why? Is this human nature, or bad bad bad management at Woob Woob Labs?

imho: LL are the Three Stooges of coporate management...
Woob woob woob woob °͜°