Rolling Restart to deploy 1.27.0

60%? Is that all? I would have put the figure a bit closer to 95%!

Anyone want to take bets on what new gets broken with this update?

THe 60% came from a user comment. There were really two problems, reduced throughput and incorrect error messages, so the failure rate was really high.

More on that here:
https://blogs.secondlife.com/community/technology/blog/2009/07/01/a-status-update-on-group-chat

Group chat servers are apart from the sims, maybe that's why it was skipped in the release notes on the wiki?

That really doesn't matter since the number didn't count the larger problem (the bogus errors that were knocking out chats). Slow would have been fine if the sessions worked.

Still no release notes?

I think we understand that group messages won't be in this update, (or even perhaps the next), but can we please see a clean set of release notes on 1.27.0?

Yes, I agree completely.

I agree with the others asking this as well, why are there no release notes for this server posted?

Was it released or did it escape?

Wow, are you really going to roll this on us without release notes?
((All I can find is the change info in the beta part of the wiki. ))
It would be really great if we knew what to expect.

If I am just looking in the wrong place, please excuse the attitude.

I don't know about LL, but in most places I've worked, release notes are approved for publication at the same time that a product is rolled out to manufacturing, in case someone has a final revision. Which in this case, would be Wednesday.
.

Good point. =)

I should lighten up also, as i believe this is Dante's first time in Prospero's shoes.

/me found the release notes :)
but hey, http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.27]Second Life Server/1.27 is missing.
Pleeeaaasse post the rel.notes
Ciao :)
Dil

Closest thing to release notes are at http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Beta_Server/1.27

I had thought that the Babbage Linden office hours had said that the 1.27 server was going to allow for increased memory available to scripts, along with a new memory allocation call. I'm not finding a mention of anything related in what seems to be the given 1.27 release notes. Also, it seems that several Linden's, whose transcripts I generally read since I can't make it to their office hours regularly, are not maintaining the transcripts, with may being over a month behind. One can only speculate as to the in tense activity they must be putting in elsewhere on their work.

~INCREASE~ memory available to scripts? Is that really such a good idea?

A lot of content creators are already highly inefficient with their code and only a very very small minority of them are even taking advantage of the benefits of bytecode sharing with Mono...

Most of the TP and and region crossing issues are related to the massive amounts of memory that need to be allocated when an agent enters a simulator (agent+attachment info+script bytecode+script memory* X number of scripts+synching with script state), whether it is on foot, or on a vehicle.

*pours one out for Prospero*
Just learned about his status...feel sad, since he was very informative and proactive when it came to providing release note information and answering questions during his Office Hours. Is Dante the new server team manager?

It's not as scary as it seems, at the same time that happens there will be a cap on the total script memory that can be used on a parcel or attached to an avatar. So, if you want any scripts to use more memory, you won't get to run as many.

I really really don't think this will be ready for 1.27. We're supposed to get the ability to see how much our existing scripts are using before we get to any changes in how it works.

oh nice, it's about time! is that just on the parcel level, or is that on the user level too, so that end users can self audit their avs and scripts they make? It pains me to see a bunch of avs running around with 2ms script time avs,\ and they are just standing around...yet there isn't really discreet/polite way of letting them know that they're lagging up the sim =P

If you have any links to where they said they would implement this, it would be great... havent had much time to attend town halls lately, but requested this on JIRA some time ago.

The transcripts are a few weeks behind, but a good source of information about those scripting changes is here:

http://wiki.secondlife.com/wiki/User:Babbage_Linden

It might make most sense to read from newest back.

The most recent transcript on Babbage Linden's page is May 4, 2009. In it, the proposed changes were to increase non-mono scripts to all taking up 128K, and allow mono scripts to request the amount of memory they would require through use of a new function call, with a maximum of 4M. The idea is that if single script can be made larger, then it might not need so many helper-scripts in the same prim, reducing the extra overhead that a separate script may require, the extra overhead for script-to-script communications, etc.

As a sim owner, I appreciate the problems of many complex builds with scripts in a sim. My pet peeve is in all the door scripts. I also have been hit with the ghost-script problems, which probably contribute to the memory consumption.

I'd like to be able to limit my LSO scripts to less than 8k, even as small as 1k. A small tight script, like a poseball script, could be crammed efficiently into a very small space... and at the same time they would be faster and more efficient to transfer across a sim boundary than mono scripts.

thatd be nice, yes. but the again, using a mono script instead would be the better choice imho, at least once some of the standing bugs are fixed (the rez-lag for mono scripts, for instance), since mono can allocate memory more dynamically.

Id really like to see mono being bugfixed completely and LSO being phased out as script option

I don't want to use Mono, because I don't want the rez/teleport/sim crossing lag.

Not me. LSO is much more efficient for low-lag wearables.

http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.27

At the time of this post, this Server release notes page is blank.. I was hoping they had just forgotten to post the link, but I manually checked, it's not even published.

Why/how are mono scripts less efficient to transfer across sims? Is it just the increased memory size, or ??

Also, if one has 3-4 instances of a single moderately-sized script on one's parcel, do you really save resources if you compile in mono, or do other costs of mono eat up the savings?

(I ask only because it is such a pain to compile in mono right now; who actually creates scripts inworld inside objects, anyway? *grumbles*)
.

The memory size is a factor for larger scripts, but there's a lot more overhead on top of that.

To transfer an LSO script between sims 16k of RAM is copied from one to another. This is efficient and fast, especially with zero-copy network stacks in modern Linux.

To transfer a Mono script, the sim has to stop the virtual machine, traverse the call tree and the data structures of the script, converting each code chunk and object into a serialized form, and reverse the operation on the other end. This also has to be done for rezzing and derezzing a running script, and is probably why they don't bother to save script state when derezzing or transferring a script that isn't set running in Mono.

This is a brilliant piece of work, but it's computationally time consuming... serializing or deserializing a modest script's data involves the same kind of effort as rezzing a few hundred prims.

I don't know where the trade-off is.

particularly in attachments, where changes are lost if you crash.

It's better than when I tested OpenSim. The only way to compile a script was to copy it from inventory to an object. It wasn't compiled on saving.