Jump to content

Darien Caldwell

Resident
  • Posts

    1,200
  • Joined

  • Last visited

Posts posted by Darien Caldwell

  1. After today's restart on LeTigre (sim of Borgbeef), HTTP-IN performance has dropped dramatically. Two prims talking to each other via HTTP-IN now takes 16-32 seconds to send a message from one to the other. Note that the HTTPRequest() timeout is 30 seconds so this often results in false failure results.

    Previous to the rollout, such a message would be transferred in 1 second or less nominally. This really breaks HTTP-IN.


  2. Nika Talaj wrote:


    ObviousAltIsObvious wrote:

    ....

    thinknig more, are you using the linked prims set to different groups hack? maybe autoreturn still ages those linked prims in different groups, even if the root keeps them rezzed?

    Yes, I am!  Thanks for the info about the change, that appears to be the problem.  If I link two prims in this sim, the root set to group and the child not, wait 10 minutes, and unlink, the child disappears immediately.

    People have been using this trick for a long time.  It seems to me that it would not defeat the intent of this anti-griefing change for script-rezzed objects to inherit the autoreturn timeout of the object rather than the individual prim, what do you think?

    I wasn't aware that linked prims HAD individual autoreturn timers!  Can't think what use that serves.  But thank you.

    The best solution is to put your rezzer in the land's group. Since you know the owner, and the object is allowed to be there (I assume), there shouldn't be a problem doing that.

  3. This is a silly thread.

     

    A) you don't have to have land to enjoy SL.

    B) if you want land and are on a budget, get a premium membership. For 72 bucks a year you get 512m plot. If you need more, a Full sim on the mainland can be found for 100-300 bucks. (which is way cheaper than the 1200 bucks they used to go for).

    Land is actually cheaper than it's ever been in SL history.

  4. There's nothing more amusing than opening your daily digest to see two dueling threads:

    Server Side Baking Doesn't work: Period.

    Server Side Baking Works: Period.

     So I have to put a blanket statement in both.  :matte-motes-big-grin-wink:

     

    For most people it works. I'm sure for some, it doesn't. But guess what is more likely to solve the problem if it doesn't work for you:

    A) complaining about it in a forum.

    B) actively working to modify your software, network, or hardware to solve whatever issue  you have.

     

    The answer is B.  However, I know, A is a whole lot easier. :)

     

    (and I guess i have to put something unique or it won't let me post again.)

  5. There's nothing more amusing than opening your daily digest to see two dueling threads:

    Server Side Baking Doesn't work: Period.

    Server Side Baking Works: Period.

     So I have to put a blanket statement in both.  :matte-motes-big-grin-wink:

     

    For most people it works. I'm sure for some, it doesn't. But guess what is more likely to solve the problem if it doesn't work for you:

    A) complaining about it in a forum.

    B) actively working to modify your software, network, or hardware to solve whatever issue  you have.

     

    The answer is B.  However, I know, A is a whole lot easier. :)


  6. Cerise Sorbet wrote:

    For what it's worth, one of the biggest causes of group chat overload
    .
     

    I dont' know what makes you think bots are the biggest source of "group chat overload". Nothing could be farther from the truth. They may be the biggest source of fraud and annoyance. But compared to all the real users of group chat that actually put 99% of the load on the group system, they are a drop in the bucket.

  7. if you don't specify a physics shape for a mesh upload, a default convex 'shell' is used to approximate the shape. This shell is the smallest shape that can encompass the mesh. It's basically a sqished sphere. So for a 'floor' that is square, it would look like this:

     

    Physics.jpg

    Already you can see where this is leading to a problem. If you tile several of these together you would get this:

    physics2.jpg 

    So for anything you're going to be walking on, or anything you need to have an exact physics representation rather than an approximation, you really need to specify your own physics shape at upload.

     

  8. I'd suggest you try the viewer found here:

     

    http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers

     

    The one labeled "Second Life GPUUpdate Viewer version 3.6.11.283787"

     

     

    Support added for the following gpu families:

     

    • Newer NVIDIA GTX 700 series
    • AMD R7/R9
    • Intel Iris Pro

    IT's less likely the problem is windows 8, and more likely the viewer isn't supporting your GPU driver. So this 'beta' viewer is meant to correct that. Worth a shot.

     

     

     

  9. Too bad it turns out any alt can simply buy something with L$ and become PIOF.

    So now all they have to do is, give their throwaway alt 1 L$, buy a 1 L$ demo, and tada, they are PIOF and can open a store.

    This makes the new 'restriction' without any teeth whatsovever.

    20131111203348708.jpg

    Payment Info on File should mean just that: that they have a  Credit card, Paypal or other form of identifiable payment associated with the account. Making PIOF just mean they spent an L$ someone gave them makes it useless as a protection.

  10. Email is basically a relay service, the mail can jump from server to server until it reaches it's destination. LIkely some server along the line got backed up and held the messages.

    It's rare, usually emails reach their destination within 5 minutes, but it can happen, they get delayed for days because of some server along the line doing this.

  11. I use Emails to SL almost daily, and they have been working fine for me.

    I can say, years ago, I had problems, and ended up finding out it was due to my email program. SL can only accept Emails in plain text format. If you're sending emails in a HMTL format, they will be rejected. So be sure to check what format your email program/service is using.


  12. Bunderwahl Guisse wrote:

    I dont really think the only or best option is fixing the carriers.. that is just not likely to happen. What we know for the people with this problem is the following (these may vary a little from one to another):

     

    1. Sl performed well before sunshine.

    2. It may work again for brief periods

    3. All other aspects of SL still function, most importantly downloading of other textures

    4. Sunshine "broke" something for them and they do not receive the baked textures.

     

    What this seems to suggest is that it is not the texture or the connection causing the problems, it was a change in delivery introduced with sunshine. All sunshine does (correct me if I am wrong) is bake several textures and sends one, instead of sending all and having the users machine bake them. I would guess this helps performance by having the server send less information and people with older machines rez faster. What is different about the baked textures and "ordinary" textures that you can still get the latter? A texture is a texture right? Why can not the baked texture be sent like all the others?

    Well, that's not the only change that came about in this time period. There have also been a lot of work (by Monty, no conincidence) to streamline HTTP communications, like reducing the number of simultaneous connections, using proper HTTP headers, using Keep-Alive connections, etc, and that work is ongoing.

    While, it's probably good to make SL adhere to the strictest of HTTP standards, the reality probably is, most of the rest of the Internet doesn't always do so. So it's inevitable conflicts like this will arise. Personally, I have a feeling a balance will have to be struck between strict standardization and quirky compatibility.

    But it definitely sounds like in this case, wireless carriers are not playing nice.


  13. 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


  14. Qwalyphi Korpov wrote:


    Perrie Juran wrote:


    Qwalyphi Korpov wrote:

    With the problems of group chat continuing year after year it certainly is irritating.  I tried to review the LL efforts to fix things.  Some parts I just couldn't find.  Here's what I think has happened:

     

    Are you perhaps thinking of
    in your 2011/2012 comment?

    That was related to the group members list never loading.  It had side effects such as not being able to change group preferences (recieve notices, show in profile) and sometimes if I recall correctly made starting or participating in a group chat difficult.

    That problem has been fixed. 

    No that isn't what I was thinking I remembered.  That is a nice example of a problem that got fixed though.  I am remember a blog post... I think it must have been one of those - that gushed about how work had been completed on the group chat issues.  It claimed that the problems were almost never seen anymore.  Not that they had been completely eliminated.  Found it...

    Pasted below & here's a link:

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

     

    Group
    Chat
    Lag

     

    Here’s a little something about that right royal pain,
    Group
    Lag. You know how it is: you’re inworld, having a ball
    chatting
    with a
    group
    of friends, but the
    chat
    shows up with words missing or in the wrong order. It’s like a bad roommate, always hanging around and making a mess, interrupting your conversations and ruining your jokes! Some of your friends won’t even
    try
    talking while that loser’s around, knowing that their impeccable comic timing will come out looking like free-form poetry.

     

    Except, for some reason, we don’t see that dude around much these days.
    ?

     

    We’d say that we’ll miss the old
    Group
    Chat
    Lag, but that would be a total lie. Instead, as the saying
    used
    to go: “door Don’t let the hit you in the butt on the way out.”

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

    Whoever said that clearly never spends time inworld chatting. The out of order stuff still happens, all the time. So does everything else, including chat never appearing, chats closing due to failure to initialize, and every other issuse since I started in 2006.

    Every so often LL will do something, and it will improve, breifly. But over time it just goes right back to being as bad as it was.


  15. Amethyst Jetaime wrote:

    When something goes wrong they may not know what the problem is at first.  Personally I'd rather they fix it than worry about having to give explanations when they do find out.

    When something goes out in RL, the utility company doesn't call me up and explain the technicalities.

    LL is under no obligation to tell you squat other than what they have.

     

    Quoted for Truth. :)


  16. Ayesha Askham wrote:

    Dezy

    One thing that jumps out at me straight away about your settings is the bandwidth:  1600 is quite high.  If you are optical fibre hard-wired, the maximum recommended is 1500.  If copper wire 1000 and if wireless, regardless of what is downstream of the router, 500.

    Now that may not make much of a change but it will almost certainly reduce your packet-loss, which might reduce your perceived lag and building issues.

     

     

    I don't know who started that superstition about Bandwidth, but it's pure nonsense. You should set your Bandwidth as high as your connection will allow, with some buffer for other applications. If you have a 1,500 kps connection, then sure, setting it to 1,000 is probably ideal. But if you're like most with a 3,000 to 25,000 kbps connection, 1,500 is fine, and even 3,000 is recommended for the high end. Sadly LL used to allow as high as 10000 for bandwith (which was great for us ppl with 25,000 to 45,000 kpbs conenctions), but no loger allows that high.

    The generic formula is connection Speed X 0.66 = Bandwidth Setting.   And in case you  need to convert, 1 MBPS = 1000 kbps.  So if it's a 1.5 Mbps connection, that's 1500 kbps.

    In short, go as high as you possibly can, but don't choke your connection. You may have to play with the setting to find what is best for you.

×
×
  • Create New...