Jump to content

Monty Linden

  • Posts

  • Joined

Everything posted by Monty Linden

  1. Hop in a sandbox. Rez a box. Build something. It might not be great but it will be yours. (Until we have an inventory accident.)
  2. Yup, never give up. Follow Lucia's example. Wasn't at the triage today so don't know about the why. I will say it's not for a lack of governance activity.
  3. WWIC, for better or worse, will always be present in SL.
  4. Filing a Jira under Bug as a New Feature is the way to get some attention. You might not like the disposition of the request but they are heard and discussed.
  5. Get that Jira filed. It's available 24/7!
  6. Yeah, Edison would have been much later than that or the Great Eastern. I'm going to have to track down that story some day. The MUSE archive looks like a candidate...
  7. This reminds me of a story I read when very young and probably recall incorrectly now. When one of the first sea cables was being laid, a problem came up with the electrical performance of the cable. (This may have been the cable laid by Brunel's Great Eastern.) So they asked Edison to come in and have a look at the problem. Being a tinkerer and no fan of Maxwell, he did what he knew and wired up a telegraph set: battery, key, spool, sounder. Oh, and the spool was one continuous run of 500 or 1000 miles of cable in a massive hold. Edison checked his work and closed the key and... nothing. Open, close, open, close... nothing happened. He finally just closed the key and waited. Several hours later, the sounder closed. The inductance of that coil was such that it took that long to build enough of a magnetic field to allow sufficient current to close the sounder.
  8. Using a *TCP* VPN could be a way of improving things where capacity is otherwise available. But it can all go wrong still: It (partially) moves the choke point from the cable to the VPN ingress as UDP packet loss is turned into TCP retransmits and backpressure. If that ingress prioritizes stupidly or has other shortcomings, the experience won't be good. You don't pay attention and use a UDP VPN protocol turning your TCP into UDP and making the entire experience worse. I'd really love to see experiments done and results shared here. I expect results to vary wildly based on location, local ISP, backbone carrier, VPN, and time.
  9. Cable ingress has traditionally been a choke point where traffic may be shed. I've frequently seen problems on cable hops. There are no alternatives but the new cables are getting faster and faster (bandwidth, not latency).
  10. @Klive Eun Send details to me. The story is almost always going to be the target service ignoring connections. There are variants (sea cables).
  11. I've confirmed that there are no automatic processes in place. Creating an account, copying an account, and setting the IP flag all require support activity. Any appearance of things working without manual intervention is strictly magical. Tír na nÓg
  12. DM or email (monty @) information to narrow the search: target URL, date, time (and timezone), region where requests were launched. Both for the normal script and test script cases. The usual answer is that dealing with 5xx is something to be expected but there are exceptional cases where we can show the endpoint is behaving badly or a sea cable is involved. But HTTP Out generates over 10K 5xx status returns a minute. It's very normal.
  13. Changes still coming but hopefully nobody will notice. With some details from @M Peccable to identify the traffic, I can look into some specific causes. No promises but I like to check up on things.
  14. There's some borkage. File a support ticket and ask to have your IP terms flag set on aditi. They should know what to do. (Hate that stupid nag step, personally.)
  15. That might be possible with a little paranoia. Trying to recover TextureTest2 right now. I'm afraid it may have joined the alumni... (Hmm, it's back.)
  16. Oh, hell, you found MeshTest2! Happy to see that is up!
  17. Note that there are no automatic triggers yet. If you need or want a re-sync, file a support case with details: https://status.secondlifegrid.net/incidents/q3mnxnpys7dt
  18. End-to-end encryption but you have to be willing to pay for it.
  19. Excellent outcome! Can you share the name of the anti-virus package?
  20. All on our radar but needing time and resources. Head-of-line problems really aren't a problem and you can read why starting at https://bitbucket.org/lindenlab/viewer/src/master/indra/llcorehttp/README.Linden#lines-593
  21. Okay, the bigger problem of Sad-in-the-UK. 128kbps is pretty much insane. If UDP over a sea cable to a throttled simulator on the west coast of the US is faster than an unthrottled, local (though possibly unpopulated) HTTP cache something is fundamentally wrong. HTTP from Svalbard would be faster. User changed network provider and problem persisted. Well, if we trust that one provider is not simply reselling services from the other, this tends to point to a local problem. ISP change usually changes the CDN Point-of-Presence and routing to same. Still the same CDN supplier but a good piece of the final hops tends to change. User can do experiments in the browser downloading textures by visiting URLs of the form: http://asset-cdn.glb.agni.lindenlab.com/?texture_id=<uuid> Replace '<uuid>' with suitable texture UUIDs (I don't have a list of large ones at the moment). These won't display in the browser but they will download. They should download faster than 128kbps. There are issues with Pipelining and certain equipment, software, and ISPs. Keep HTTP but disable pipelining along the lines that @Whirly Fizzle showed. Given what has been described so far, I'm still inclined to believe the problem is between user and the ISP. CDN is provided by Akamai and they are the benchmark. (I've also wanted to do experiements with https:// retrieval of assets to defeat all but the most motivated of traffic twiddlers. This would be a good test case for it.) That said, I have a story from a recent adventure. CDN issues were reported involving Ukrainian users, VPNs, Akamai, and some other stuff. One of the things that showed up was a certain Ukrainian residential ISP was providing DNS and other services, as expected. However, their DNS was hijacking requests for certain Akamai DNS names and returning IPs for their own hosts. For whatever reason, they had set up their own CDN in front of Akamai. The performance of this Potemkin Village of a CDN was on the order of what the user is experiencing. *Many* seconds for certain requests to even start or just fail. Never trust your ISP.
  22. Okay, missed the notifications here and stuff got busy. So some chatter... 1st. Yep, UDP RequestImage service is alive and well on simulators. Went looking for any attempt at scheduling a deprecation and couldn't find it. I'd be mad but someone is finding the fallback useful so I'll be quiet for now. Regardless, this is an *extremely* throttled data path and @Whirly Fizzle's numbers are what I'd expect. You don't want to use this. 2nd. Fallback is an asset-by-asset decision. The comments at the beginning of this code may be of interest: https://bitbucket.org/lindenlab/viewer/src/master/indra/newview/lltexturefetch.cpp 3rd. There are some indirect controls on UDP fallback but I'm not liking what I see in the above. My carefully extracted and maintained locking flags have not been maintained so I'm already distrustful of what I see. @Henri Beauchamp is not wrong.
  23. It should work. 'Authorization' is not on the blocked list. Check the error and your custom header list. As for 'Accept', I haven't checked this but if you don't specify it, we'll default a long list of acceptable types which may startle your server.
  • Create New...