User:Babbage Linden/Office Hours/2009 04 29

From Second Life Wiki
Jump to navigation Jump to search

Transcript of Babbage Linden's office hours: 

 Topics
 * http-texture increase texture download speed at 100% rate: LINK


[3:22] Babbage Linden: hi everyone

[3:22] Laurent Bechir: greeting, Babbage

[3:22] Babbage Linden: sorry i'm late

[3:22] Nock Forager: Hi Babbage.

[3:22] WolfPup Lowenhar: mornin babage

[3:22] Kephra Nurmi: moin babbage

[3:22] Robertus Bobak: hello Babbage

[3:22] Thoys Pan: G'Day Babbage

[3:23] Babbage Linden: not a lot of script news from us this week

[3:23] Babbage Linden: we're currently working on http textures in brighton

[3:23] Babbage Linden: which is looking good

[3:23] Babbage Linden: should improve texture download by 100% on average

[3:23] Imaze Rhiano: yay

[3:23] koen3 Bing: nice

[3:24] WolfPup Lowenhar: that will mean that soon we will be able to show actual webpages in SL its sefl

[3:24] Laurent Bechir: nice , yes :)

[3:24] Babbage Linden: should halve the time for texture downloads on average

[3:24] Babbage Linden: and potentially open the door to hosting textures externally

[3:24] Babbage Linden: eventually

[3:25] Kephra Nurmi: this would require a new client for everyone?

[3:25] Babbage Linden: it also moves a lot of data off of our creaky udp message system

[3:25] Thoys Pan: thats good, will it still send out textures with discard level? , or must we wait till the complete texture is loaded before we see it?

[3:25] Kephra Nurmi: or would it also run with old clients?

[3:25] Babbage Linden: it will need a new client to take advantage of it

[3:25] Babbage Linden: so we'll need to support the old udp texture download for a long time

[3:26] Cristopher Lefavre: Babbage, will this imply that textures are loaded over TCP/80 instead of a high UDP port?

[3:26] Babbage Linden: until all supported viewers are downloading textures over http

[3:26] Babbage Linden: not sure about the ports cristopher

[3:26] WolfPup Lowenhar: your saying that we could eventualy have it so that we would be able to store texttures out of SL then simply have that texture available inworld ?

[3:26] Babbage Linden: currently we're using the caps system to send the textures in cleartext

[3:26] Babbage Linden: but that may change too

[3:27] Babbage Linden: as using caps means we have a url for every <viewer, texture> pair

[3:27] Babbage Linden: where ideally we only want 1 url per texture

[3:27] Laurent Bechir: sorry if I don't understand completly :) does it means that objects could load their textures from a personnal server ?

[3:27] Babbage Linden: actually, 1 url per <sim, texture> pair

[3:27] Babbage Linden: laurent, potentially, yes

[3:27] WolfPup Lowenhar: with textures comeing in in chat that might be whay some textures fial to load at all

[3:27] Babbage Linden: you would want to wait until all supported viewers to http texture download though

[3:28] Babbage Linden: otherwise people with older viewers wouldn't be able to see your texture

[3:28] Qie Niangao: does the http-texture data pass through SL's network (I hope) or directly from the http source to the client (which would mean lots of connections--and security concerns)?

[3:28] Babbage Linden: qie, the former

[3:28] Qie Niangao: thanks. :)

[3:28] Babbage Linden: laurent was asking about the latter

[3:28] Kephra Nurmi: so the current idea is: client request capabilities, and receives a caps url for the textures?

[3:28] Babbage Linden: (which will come later ;-)

[3:29] Babbage Linden: kephra, yes

[3:29] Kephra Nurmi: *ah* nice

[3:29] Babbage Linden: this improves the simulator performance too

[3:29] Kephra Nurmi: so non clients wont have the caps and can not just simply download the textur

[3:29] Babbage Linden: currently the sim has to read textures from disk

[3:29] Babbage Linden: then chop them up and send them via udp

[3:29] Babbage Linden: in future it will just give the viewer a cap

[3:30] Babbage Linden: and the texture transport will be off loaded to an apache proxy on the sim host

[3:30] Babbage Linden: so it takes load off the sim too

[3:30] Kephra Nurmi just thinks about the textures from 3rd party servers

[3:31] Kephra Nurmi: would it be possible to run a capability server on own system, and to use this for other things than textures?

[3:31] Imaze Rhiano: isn't there plan to change texture baking too?

[3:31] Babbage Linden: texture baking is where most of the compexity comes with this

[3:32] Babbage Linden: i'm currently talking to phoenix about whether we want to change baked textures

[3:32] Babbage Linden: or support the current system with the http transport

[3:32] Thoys Pan: do textures also have some kind of checksum?

[3:33] Thoys Pan: so you could see if you really downloaded it right?

[3:33] Babbage Linden: well, TCP and HTTP take care of that

[3:33] WolfPup Lowenhar: i would think they would have to for them to load right as it is now

[3:33] Babbage Linden: and the UDP transport takes care of it too

[3:34] Babbage Linden: so, that's what we're up to at the moment

[3:35] Babbage Linden: anything you'd like to talk about?

[3:35] WolfPup Lowenhar: i was wonderin how the scrip memory project is going

[3:35] Imaze Rhiano: any data about script memory limits yet?

[3:35] Indeterminate Schism: Any more thoughts on the proposed memory-management tools?

[3:35] Babbage Linden: still waiting for the numbers from xan

[3:35] Babbage Linden: should be here this week

[3:35] Babbage Linden: i reminded him last week for them

[3:36] Babbage Linden: the plan is still to look at the numbers, work out what we can support for script limits

[3:36] Babbage Linden: then publish those proposed numbers

[3:36] Babbage Linden: then add tools for discovering where memory is being used

[3:37] Babbage Linden: and finally add the enforcement code after people have had time to tidy up

[3:37] Babbage Linden: enforcement is unlikely to happen before the end of the year

[3:37] WolfPup Lowenhar: it would be good to be able to see how much memory a script actualy uses

[3:37] Thoys Pan: also , babbage, would the http way make it free to upload/set textures?

[3:37] Qie Niangao: yeah, we could use those tools even if we didn't know the target values.

[3:38] Babbage Linden: yes, there are still discussions to have around the actual memory accounting

[3:38] Babbage Linden: we don't want to support 2 VMs indefinitely

[3:38] Babbage Linden: so need to make sure we don't accidentally incentivise using LSO scripts

[3:39] Babbage Linden: which is tricky as in some cases, LSO scripts can be the more memory efficient option

[3:39] Babbage Linden: (although not often)

[3:39] Babbage Linden: the problem gets worse when we go to 64 bit, which makes mono scripts use more memory, but not LSO scripts

[3:40] Babbage Linden: hopefully we can set the memory limits at levels where this is not an issue for 99% of people though

[3:40] Babbage Linden: and only really stops really abusive misuse of scripts

[3:40] Babbage Linden: for griefing

[3:40] Cristopher Lefavre: Any news on the htp server implementation, Babbage?

[3:40] Babbage Linden: we'll see

[3:40] Xaria Mistwallow: I have a 64bit PC

[3:40] WolfPup Lowenhar: < is on 32 bit systems

[3:40] Babbage Linden: 64 bit PCs don't affect scripts xaria

[3:40] Xaria Mistwallow: i do see drastical decrease in mono scripts, not sure why it doesnt effect me then

[3:41] Kephra Nurmi: *hm* does the simulator run in a 32bit chroot environment?

[3:41] Thoys Pan: with 64 bit, would floats be more precise?

[3:41] Babbage Linden: memory use for scripts is only affected by the simulator binary

[3:41] Babbage Linden: at the moment simulators are 32 bit

[3:42] Babbage Linden: running on 64 bit debian machines via emulation

[3:42] Babbage Linden: we'd like to move them to 64 bit

[3:42] Xaria Mistwallow: im on vista unfortunatly

[3:42] Babbage Linden: but that affects Mono memory usage

[3:42] WolfPup Lowenhar: when the simulators goto 64 bit that should me the perform better

[3:42] Imaze Rhiano: how about instead of memory limit - you would calculate abstract "performance value" for script - that would combined from different parameters - like script's memory usage, script's VM, what functions it calls, etc...

[3:42] WolfPup Lowenhar: mean*

[3:42] Babbage Linden: imaze, yes we could go down that route

[3:42] Babbage Linden worries that it would be more confusing though

[3:43] Babbage Linden thinks of the mystical dwell calculation and shudders

[3:43] Thoys Pan: ah, so it has to do with the os, and what if you use debian 32 systems for now?

[3:43] WolfPup Lowenhar: vist already dose that in a scale of 0 to 10

[3:43] WolfPup Lowenhar: vista*

[3:43] Babbage Linden: we have been using 64 bit debian machines for a long time

[3:43] Babbage Linden: but running 32 bit simulators on them

[3:43] Xaria Mistwallow: i know, i got probably the worst combination there is

[3:44] Babbage Linden: we'd like to make everything 64 bit

[3:44] Xaria Mistwallow: unfortunatly i found out AFTER i got this =(

[3:44] Thoys Pan: or you cant get above 3036 mb ram memorry when you have 32 bit right?

[3:45] WolfPup Lowenhar: actualy max on a 32bit system is 4GB physical but the top GB is used by the system

[3:45] Kephra Nurmi: applications cant get more then 2gb, and server cant have more than 3gb without bad tricks, on a 32bit system

[3:45] Xaria Mistwallow: Babbage: does that mean 64bit will become more stable aswell? I crash all the time now without any warning or knowing why, in the end it comes down to 64bit with SL doesnt work that well together

[3:45] Xaria Mistwallow: I do have to say that alot of games have this problem unfortunatly

[3:45] Qie Niangao: (RL calls. Thanks Babbage. Have fun all.)

[3:45] Kephra Nurmi: xaria your problem is client side ... because of 32bit/64bit opengl emulation

[3:45] Nock Forager: (me using Win7 64bit and works fine. Rarely carashed, Xaria).

[3:46] Babbage Linden: xaria, the simulator move to 64 bit won't affect the client stability

[3:46] Babbage Linden: the good news is that both the viewer and simulator stability have improved markedly recently

[3:46] Babbage Linden: the simulator crash rate went down ~50% after the last release

[3:46] Babbage Linden: which was great news

[3:46] Xaria Mistwallow: too bad, I just hope this could be fixed somehow, it gets really annoying when you crash all the times just becouse of that issue

[3:46] Thoys Pan: yes

[3:46] WolfPup Lowenhar: that is good

[3:47] Kephra Nurmi: well ... simulator patches could be bad for clients ... e.g. the saturday change on search cause me to crash reliable when ever i clicked (search)

[3:47] Thoys Pan: or theres a bug in the crash reporter since than lol

[3:47] WolfPup Lowenhar: < is helping test the new viewer right now

[3:47] Xaria Mistwallow: its not the sims im worried about, client with 64bit is :p

[3:47] Xaria Mistwallow: I did not have any problems on the OnRez viewer tho

[3:47] Babbage Linden: xaria, yes i understand, unfortunately i'm not the linden to ask about the viewer

[3:48] Babbage Linden: i think q has office hours and is very involved with the viewer work

[3:48] Xaria Mistwallow: 8am for him I noticed, yeah. ill go ask him about this same thing

[3:48] Babbage Linden: there's a bear for those that wanted one

[3:49] Babbage Linden: for sale for 0L$

[3:49] Xaria Mistwallow: ♥ Thank Youuuuuuuuuu!! ♥

[3:49] Xaria Mistwallow: :)

[3:49] Xaria Mistwallow: or take copy :)

[3:49] WolfPup Lowenhar: ♥ Thank Youuuuuuuuuu!! ♥

[3:49] Babbage Linden: any more questions or topics?

[3:49] Xaria Mistwallow: not so far i know of :p

[3:49] Kephra Nurmi has progress on his 'using mediawiki as a cloud database for secondlife' project ;)

[3:49] Cristopher Lefavre: The http server project?

[3:50] Xaria Mistwallow: I do not know much about scripting etc. I do try to learn tho

[3:50] Nock Forager: Watched your video on lang.net. The nubmers are very interested.

[3:50] Babbage Linden: glad you checked it out nock

[3:51] Nock Forager: So many scripts running in the Grid!

[3:51] Babbage Linden: i wrote up the conference from an sl perspective here: http://jimpurbrick.com/2009/04/27/langnet-3-years/

[3:51] Babbage Linden: yes, it's amazing: 1000 scripts per logged in avatar

[3:51] koen3 Bing: woow

[3:52] Imaze Rhiano: many 255 prim hairs with scripts :P

[3:52] WolfPup Lowenhar: dang

[3:52] Xaria Mistwallow: lol, i hardly have any. atleast not that i can mod =)

[3:52] Babbage Linden wonders how many will be cleaned up with script limits

[3:52] Nock Forager: Resize script should be removed after size fixed. ;-)

[3:52] Babbage Linden: part of the reason for so many scripts is that there's no limit

[3:53] Babbage Linden: i imagine some percentage are not needed

[3:53] Babbage Linden: and just haven't been cleaned up

[3:53] Babbage Linden imagines the big SL spring clean

[3:53] WolfPup Lowenhar: i wonder if megas actualy have hidden scripts in them

[3:53] Xaria Mistwallow: <<<hihi>>>

[3:54] Kephra Nurmi: megas are nearly normal prims, from scripting point of view

[3:54] Indeterminate Schism: Having a llSetLinkPrimitiveParams() where we could target a range of prims would be good, so we didn't need scripts in all the child-prims when the changes need to be synchronised. I think you've discussed that though

[3:54] Babbage Linden: yes, it would often be handy for scripts to be able to operate on lots of prims

[3:55] Babbage Linden: to avoid lots of scripts everywhere

[3:55] WolfPup Lowenhar: true but then you could also end up with one prim in a linkset that use a massive amount of memory

[3:56] Babbage Linden: if scripts can request large amounts of memory that's not a problem wolfpup :-D

[3:56] Imaze Rhiano: Doesn't MONO have now CIL verifier? Wouldn't that make possible C#?

[3:57] Babbage Linden: it has a bytecode verifier

[3:57] Babbage Linden: i'm not sure their metadata verifier is complete

[3:57] Kephra Nurmi: *oups* is this server special ... just got an 'can not upload script' message while editing a script in inventory

[3:57] WolfPup Lowenhar: true but someone might find a way to use that for greifing as well by making a script that kept making linked prims and having all of them setting with divverent prams

[3:57] Babbage Linden: which also needs to be done before we can use it

[3:58] Indeterminate Schism: Well you *can* do that now Wolf, you just can't change 'only these' efficiently

[3:58] Babbage Linden: ok, i need to head off

[3:59] Babbage Linden: thanks for coming everyone

[3:59] Indeterminate Schism: Thank you Babbage

[3:59] Laurent Bechir: thank you Babbage and bye

[3:59] Babbage Linden: hopefully see you all next week

[3:59] Imaze Rhiano: thank you

[3:59] WolfPup Lowenhar: you tc babage and thanks for having these office hours

[3:59] koen3 Bing: :)

[3:59] Cristopher Lefavre: Thanks, bye!
Retrieved from "https://wiki.secondlife.com/w/index.php?title=User:Babbage_Linden/Office_Hours/2009_04_29&oldid=347453"