Jump to content
Sign in to follow this  
Guest

SSB via T-Mobile cellphone

Recommended Posts


weetulow wrote:

Drake ... Must be nice to be able to flaunt you nice big e-**bleep** data speeds, unfortunally in the real world most people don't get speeds anywhere near that ....... The whole point I am trying to make is ..and I quote " IT ALL WORKED FINE BEFORE THE IMPLEMENTATION OF PROJECT SUNSHINE " Tyvm and have a nice day sir ...

In the real world? Most people don't use their cell phones as a wireless signals for their laptops. You may actually have to break down and get internet in your house.

Share this post


Link to post
Share on other sites

I have cable internet in my house but I travel too so I am on my laptop a lot. I have no problems playing any other games on it.

 

troll

Share this post


Link to post
Share on other sites

well in "the real world"  not everyone has cables running past their house...  not everyone has DSL available...  and I tell you what.. I LIKE my real world....   but I also like my SL to work properly like it did before the whole SSA.  If it wasn't for us who live in the country and have farms, you "city folk' wouldn't have much to eat now would you?   no farms, no farm land..    *shrugs*  and BTW   the problem I am having is not logging on with my cell phone, but with my Cellular MODEM....   get your facts straight

 

Share this post


Link to post
Share on other sites


Elyse Sirnah wrote:

well in "the real world"  not everyone has cables running past their house...  not everyone has DSL available...  and I tell you what.. I LIKE my real world....   but I also like my SL to work properly like it did before the whole SSA.  If it wasn't for us who live in the country and have farms, you "city folk' wouldn't have much to eat now would you?   no farms, no farm land..    *shrugs*  and BTW   the problem I am having is not logging on with my cell phone, but with my Cellular MODEM....   get your facts straight

 

/me chuckles.. City folk..

I wouldn't know, I buy from local farms..

You still haven't posted a speedtest. SL is a huge bandwith hog.

It may be that with SSA being active you need a higher bandwidth from your provider, since there is now more coming from SLs servers. Before SSA all textures were stored on your harddrive. Now they have to be sent from the SL servers to your viewer.

Share this post


Link to post
Share on other sites


weetulow wrote:

I have cable internet in my house but I travel too so I am on my laptop a lot. I have no problems playing any other games on it.

 

troll

SecondLife is not a game. You need serious bandwidth to run it properly.

Straight from their System Requirments page..

"Second Life is not compatible with dial-up internet, satellite internet, and some wireless internet services."

They recommend cable or DSL.

Share this post


Link to post
Share on other sites

and I'm not going to post my speed test, Monty doesn't seem to think that is the issue... so it shouldn't be for you either.. really is none of your business... and those "farmers"  at your "farmers market" ask them how many of them have cable running past their hosue or DSL?   see.. without them, you woudln't be eating....

Share this post


Link to post
Share on other sites


Elyse Sirnah wrote:

and I'm not going to post my speed test, Monty doesn't seem to think that is the issue... so it shouldn't be for you either.. really is none of your business... and those "farmers"  at your "farmers market" ask them how many of them have cable running past their hosue or DSL?   see.. without them, you woudln't be eating....

Those farmers have DSL. And I go to their farms. You have no idea who I am, what I have growing in my own backyard, or where I get my food. How you devolved this into a "I'm a farmer without me you would die" thread I have no idea.

Aside from that.. Monty may know a lot, but information is never a bad thing. If you bothered to read what i posted instead of turning it into a food pissing contest, you would understand that you need more bandwidth now to run SL.

ETA.. Monty asked for your bandwidth info... you just never posted it. What your provider tells you  you will get and what you actually get are two different things.. Hence asking for a speedtest.

Share this post


Link to post
Share on other sites

I don't mind seeing the speedtest results here, they are additional information.  As for SSA, it doesn't really increase transfer demands, under some scenarios, it reduces them.  And the difference, plus or minus, will be negligible compared to an uncached region load.

Jira reports have been useful.  They're showing a consistent symptom (partial file transfer) indicating something is breaking tcp connections.  This can be caused by a number of things:  timeout, bad server, bad network infrastructure, bad router, traffic shaping policies.  Which are at fault isn't known yet.

 

Share this post


Link to post
Share on other sites

I will defer to Monty about the amount of bandwidth needed now verse before...  and about what the issue is...  but just for "**bleep**s an giggles"   I did do a speed test on ONE of my 3g connections that DOES work and is way lower then my one that is no longer working now that SSA has taken effect. 

http://www.speedtest.net/result/2971322866.png

 

as far as knowing you.... you are correct I don't...   *snickers*  is such a shame too because I have a feeling we would be best friends, as I can only imagine what you grow in your back yard.   Secondly I did not say I was a farmer, but I own farm land...  yes, there is a difference.  And pissing vegetables?   I have a feeling that'd hurt, and don't plan on doing it any time soon :)

 

 

Share this post


Link to post
Share on other sites

Thanks for the jira updates, folks.

Of the people reporting, would you be comfortable running either:

  • Wireshark to capture packets (which can reveal personal information) or
  • Capture a special SecondLife.log using 'Advanced > Show Debug Settings' to add more HTTP information

Don't need these yet, just want to know who's willing and able...

 

 

Share this post


Link to post
Share on other sites

Excellent!  Just another reminder:  wireshark can capture and reveal personal information.  If you're not comfortable with this, it's best not to do a capture.  Securely transfering the captured data is always a problem and you'll have to decide what your effort-vs-security sweetspot will be.  You can transfer via email (to monty/at/lindenlab.com) or dropbox or email to a non-gmail target I can provide or something else of your choice.

To the tasks.  I want two things from this:

  1. SecondLife.log file from a gray avatar session
  2. Packet capture file from the same session

The steps:

  • Clear SecondLife cache
  • Quit all unnecessary network programs (netflix/music streaming, etc.) making your network as quiet as possible. 
  • Start Wireshark.
  • =  From the interface list, select the active connection interface.
  • =  Start Capture (click Start icon)
  • Start SecondLife
  • =  Login.  Simple, unpopulated regions are probably best for data size but use what works.
  • =  Once gray avatar appears, wait another 30-45 seconds.
  • =  Quit SecondLife
  • Back in Wireshark:
  • =  Stop Capture
  • =  Select 'File > Save As...' and save capture to a file using default file type.
  • Send the SecondLife.log file and the saved packet capture to me by whatever means you prefer.

 

Share this post


Link to post
Share on other sites

@weetulow captured some packets which duplicated @Sarah's report.  Capture shows a baked image coming back to the viewer with 'Content-Range' and 'Content-Length' headers in disagreement.  If we were doing this consistently from the bake service, *every* viewer would be failing.  This reeks of a buggy or misconfigured HTTP cache sitting between your viewers and our servers.


So, first question of the reporters here:  are any of you running a local HTTP cache (Squid, etc.)?  With tethering, yes, it's unlikely you added one.  We'll have to consider that your devices might insert one regardless.

 

It may be the carriers doing this.  Getting some action there may be interesting.

 

Share this post


Link to post
Share on other sites

I am not running a local HTTP cache.  I'm fairly sure the carriers are doing some sort of in-between work, because if you exceed your allotted tethering amounts, website viewing winds up being sent to their upsell page.

Share this post


Link to post
Share on other sites

I'm beginning to suspect the devices as well.  It would make sense to put a cache in there to avoid excess HTTP activity which then gets charged against a monthly quota.  ("You billed me for all 42 downloads of my favorite lolcat?")  But it's looking like a very poor quality cache...

Share this post


Link to post
Share on other sites

Verizon USB wireless, EXPD EV720 -  NDIS mode... Regular broadband mode... both grey avis. Networked on 2 computer desktops, unlimited data.  I did speedtest and have 500 kbs download speed.  Lebanon, TN, got all green bars as well. the SL worked fine before the ssa upgrades. 

Share this post


Link to post
Share on other sites


Monty Linden wrote:

@weetulow captured some packets which duplicated @Sarah's report.  Capture shows a baked image coming back to the viewer with 'Content-Range' and 'Content-Length' headers in disagreement.  If we were doing this consistently from the bake service, *every* viewer would be failing.  This reeks of a buggy or misconfigured HTTP cache sitting between your viewers and our servers.

 

So, first question of the reporters here:  are any of you running a local HTTP cache (Squid, etc.)?  With tethering, yes, it's unlikely you added one.  We'll have to consider that your devices might insert one regardless.

 

It may be the carriers doing this.  Getting some action there may be interesting.

 

Carriers for wireless services do a lot of strange, and sometimes improper things to traffic on their networks. It brings to mind the case when Nokia was found to be Decrypting HTTPS traffic to HTTP in order to 'improve service'.

http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the-middle-attacks-103799

Share this post


Link to post
Share on other sites

[*snort*  I accidentally put this in a Jira where practically no one can read it...]

Those who are experiencing this problem and who are comfortable with 'curl' might try an experiment.  Here's a GET operation against www.example.com that captures all the response headers and puts them in headers.txt:

$ curl -H 'Range: bytes=0-33554431' -D headers.txt -o body.txt http://www.example.com/
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1270  100  1270    0     0  56100      0 --:--:-- --:--:-- --:--:--  112k
$ more headers.txt
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Cache-Control: max-age=604800
Content-Range: bytes 0-1269/1270
Content-Type: text/html
Date: Fri, 20 Sep 2013 21:15:04 GMT
Etag: "3012602696"
Expires: Fri, 27 Sep 2013 21:15:04 GMT
Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
Server: ECS (cpm/F858)
X-Cache: HIT
Content-Length: 1270


You might do that twice capturing the headers into separate files.  Then see if the files differ or if a 'Content-Length' header shows up in disagreement with 'Content-Range'.

Share this post


Link to post
Share on other sites

I don't think it is the devices... I downloaded wireshark and was going to capture for you and realized I had baked avi.. had to double check to make sure I hadn't accidently connected with one of my working devices...  nope, was my mifi2200 that I had been gray with for weeks....   was baked every time I logged in for over 24 hours.  I had to rest my cellular conenctoin.. gray again.. took a chance and reset it again and baked again..and for a very long period of time..   took it with me to work on Friday night..   again baked avi... had to reboot due to a crash and gray avi... reset my cellular connection 4 or 5 times.. and finally baked avi again.  I"m not sure why it is working.. I don't like to have to relog that many times .. my friends start tossing me superglue and ankle weights!!   lol 

I'm sure you may recall I had reconnected several times way back in the beginning of this and was gray, I had tried using it wirelssly, through a router, teathered to my laptop, I had reset it several tiems before.  I have NO idea why it is working now, but I do love being able to see!!!!   Next time I end up all gray again I can run a wireshark capture for you. 

AND.. Just now.. very perplexingly my connection that ALWAYS has me baked.. just logged me in as all gray, nothing to fix it... ugh!!  so I did a dis/re connect.. and poof  all baked again...  

Share this post


Link to post
Share on other sites


Elyse Sirnah wrote:

I don't think it is the devices...

Possibly.  I'll be happy if it isn't grid services (of which I'm increasingly certain).  But it could be either or both of the devices and the carriers.  'Content-Range' handling gives a lot of naive caches problems.  (Bingle for:  "http cache content-range problem")

There's enough technical information in this thread that it might be referenced with the various carriers' support tiers to quickly escalate to engineers and get them looking at this problem from the middle....

 And following up...  anyone do the 'curl' test by any chance?

 

Share this post


Link to post
Share on other sites

Had another brief glimpse of sunshine, before the dark clouds once again moved in. This was the second time I could "see" again. I am not sure but I think it stopped working when I clicked on someone and tried to refresh their textures, which I think happenend last time as well. Now did I refresh the textures because things stopped working, or did refreshing the textures break things? That I can not say, what it does show is that sl can work, and it is not an issue with peoples computers. I would love to see an option to just turn off SSA, or force textures to be sent -that is the problem in my opinion, the server does not send the textures (for whatever reason) it is not we can get them, can not view them, or speed (4G is faster then DSL)
 they are simply not sent. Once things go "bad" the server gives up it seems and no matter what happen it goes to gray again.

 

The problem is probably more widestread then thought as well, being intermittant some may experience it far less. A friend in SE Asia says she has the same problem (do not know how she connects), she simply relogs until it goes away (3 or 4 times on average). As to seeing yourself in edit character mode something interesting is while in that mode if you add or change a tattoo layer you will continue to see yourself (everyone else stays gray). I created a tatt just for that, nothing in it, just a blank tattoo layer and it works (well on one character the head will revert to gray but the body and clothing on it remain visible)

Share this post


Link to post
Share on other sites

For what it is worth, I bit the bullet and compiled my own viewer with a hack to work around this problem.  I suspect the server is sending the correct headers, but our data providers are modifying it in the middle somewhere.  

For those with the know-how, edit:

 _httppolicy.cpp

At line 353, add

// If partial content, try to use it anyway, because Content-Length header can't be trusted.
if (! op->mStatus)
{
if (op->mStatus.toString() == "Transferred a partial file") {
op->mStatus=HttpStatus();
}
}

Share this post


Link to post
Share on other sites


Sarah Passerine wrote:

For what it is worth, I bit the bullet and compiled my own viewer with a hack to work around this problem.  I suspect the server is sending the correct headers, but our data providers are modifying it in the middle somewhere.  

For those with the know-how, edit:

 _httppolicy.cpp

At line 353, add

// If partial content, try to use it anyway, because Content-Length header can't be trusted.

if (! op->mStatus)

{

if (op->mStatus.toString() == "Transferred a partial file") {

op->mStatus=HttpStatus();

}

}

Interesting experiment.  I'd suggest this change to make it more resilient to changes:

 

    // If partial content, try to use it anyway, because Content-Length header can't be trusted.    if (! op->mStatus)    {        if (op->mStatus == HttpStatus(EXT_CURL_EASY, CURLE_PARTIAL_FILE))        {            op->mStatus=HttpStatus(200);        }    }
There is a maintenance fix coming that will make PARTIAL_FILE a retried error. But that doesn't help this situation. The challenge is that some people have the reverse problem: they *do* get short data and by retrying on this error, the error will clear and they will get the correct, complete texture The only single solution is to fix the carriers. sigh

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...