Cool VL Viewer forum

Would it be possible to make HTTP requests obey the MAX bandwidth setting in prefs/networking? The problem is with LL pushing hTTP more and more, if two people are on SL with the same connection. Or a connection is anything less than a very large and reliable one, teleporting into a new area, can flood/max out a connection (massive packet loss) causing rezing to fail among other issues.

If the MAX bandwidth setting also worked for HTTP requests, it would fix this problem. I can only turn on HTTP fetching on occasionally due to this issue.

And I now see that you mentioned a few things to try here viewtopic.php?f=6&t=1087&p=5020&hilit=bandwidth+setting#p5020 but for some reason I never got the notification of a reply even though I was following the post. My router is far from be being maxed out. I have checked/watched that (it is a decent router running DD-WRT which shows in it status circus, memory capacity etc). It is the bandwidth. It maxes out and everything fails when it happens as a result. And when I say connection maxes out, I am looking in the routers bandwidth/connection status, not the viewers meters.

I have tried Max HTTP requests at 8, to no avail. I will try lowering that further with debug. MTU is set properly.

Still it would be wonderful if the MAX Bandwidth setting could work for all connections in the viewer instead of just UDP.

There is no way to limit the HTTP bandwidth in the viewer given it uses Curl and threaded fetches. Perhaps later, when the llcorehttp library will be used for all HTTP fetches everywhere in the viewer.

Anyway, HTTP is a TCP protocol and cannot loose packets (at worst, it will time out waiting for packets). If you are loosing many UDP packets when the bandwidth usage on your link is high, then it's a clear sign that your network is crippled, and the viewer can't do anything for this (fix your network: check the MTU, check your router configuration, replace any lousy/buggy router, etc...).

Actually that is not quite true. Packets can be lost, if TCP or UDP. TCP are re transmitted, where UDP is "streaming" and is just skipped. So either can have "packet loss" but TCP should be retransmitted so should be "lossless" in the end. Of course I am sure you know this. Again it is not my packet "loss" that is the problem, it is the connection being maxed. The packet loss points to a problem, which when I went digging found the problem to be a maxed connection. Turning off HTTP helped/fixed the situation. That is a fact. And since hTTP/TCP on causes the connection to be maxed, the problem can be fixed with a max bandwidth throttle.

I figured that the MAX bandwidth setting didn't apply to HTTP (TCP) connections due to the libraries used on LL's end or you might have implemented something by now. But searching the forums I didn't find anyone requesting this before, so figured I would ask.

But again it is not my connection, my settings are fine, and everything works great unless I either turn the max bandwidth up too high OR I use HTTP (TCP). Sure I suppose upping the bandwidth for the connection itself would work, but at the moment SL is the only program I have such issues with, and secondly that would be expensive lol.

Anyway at the moment I am just glad there is a work-around for my situation. And I hope that in the near future a more permanent fix can be done.

By the way the only reason I said HTTP as everything in the viewer says HTTP with regard to TCP connections. Otherwise I would have called them TCP. But I wished to avoid confusion.

Yes, I perfectly know this. But unlike what you imply, you cannot know when a TCP packet is lost, because it's all dealt with at the TCP stack level and the application doesn't know whether some packets got lost and re-transmitted or not for any given TCP connection (such as an HTTP one). The "packet loss" reported in the viewer exclusively deals with UDP packets, just like the bandwidth limiting setting. At the application level, the only sign of (irrecoverable) packet losses in a TCP connection is a timeout (when re-transmitted packets don't go through or not fast enough).

I replied to the problem as you posed it yourself. Citing you " teleporting into a new area, can flood/max out a connection (massive packet loss) causing rezing to fail among other issues."

No, the problem is with the network buffer queue on your router/MODEM and the absence of proper QoS. Without any QoS to prioritize packets, high bandwidth connections are filling the queues (which are made up very large buffers to maximize the maximum bandwidth) and the next outgoing UDP packet (that would require a high priority to be emitted before the queued data pertaining to the high bandwidth connection) is then queued and must wait for the queued data before it to go out before it can be emitted in its turn. With nowadays routers/MODEMs, buffers are so large that it can take several seconds for them to empty out, causing apparent "packets loss" (actually timeouts waiting for the reply to a packet that might still be stuck in the router/MODEM queue), followed with "out of order" packets warnings in the log (when the reply to the packet that finally left the queue arrives while that packet was already flagged as lost by the viewer).

The true solution to your problem is not to limit your HTTP traffic, but rather to configure the QoS on your system (do a search on the Internet for how to do this: there are plenty of good tutorials for each OS).

Actually it is not my network as I said before. This week it has improved greatly. Things are rezing well even with HTTP on (granted I don't have the fetches on past 3 or 4 but otherwise no issues. This implys something was changed at LL's end as I have done NOTHING since my last post (except usual cache clears).

So again the issue was not my configuration, modem, or router. They weren't reset, rebooted, reconfigured or any of that since my last post. My assumption is LL made changes on their backbone. Of course I could be mistaken, but either way the change was not one I had made. Another indicator it was not anything I did...the bandwidth doesn't max out like it use to after a teleport (and I am talking about the monitors in the network router not viewer). The bandwidth remains at it is lower levels as it was back months ago (January or so I started noticing a problem).

And by the way while I agree I cannot know with 100% certainty if packet loss was TCP or not (and I wasn't implying that it was). I was simply saying the effects of failing to rez with HTTP on which happened when my connection was maxed (cause-effect of watching bandwidth after a teleport). Which may not be packet loss per say and should eventually catch up but it usually failed to so. Which again indicated there was a "loss" of data at some point. Or a failure of a server to even send it in the first place. And if the packets were "suck" in my modem/routers memory this would likely show in the buffer, which it didn't. Either way the point is moot as it is fixed and not by anything I did/changed.

Don't forget that there are n routers and network links between your home network and LL's server, any number of which might be down, misconfigured, overloaded etc. Even if your network is perfectly set up, or its status has not changed, It is not a safe assumption that a change in overall network performance is the result of LL's actions.

Another suggestion: Perhaps a separate bandwidth control for textures/http? I happened to notice another viewer had this (I was helping someone with Singularity). Since merging the two is not possible, could a separate bandwidth control be implemented fairly easily?