Second Life Forums Archive - Low lag communication

Gaius Goodliffe

Dreamsmith

Join date: 15 Jan 2006

Posts: 116

08-01-2006 22:14

From: Farallon Greyskin

All due to hundreds of event handlers that SHOULD NEVER BE CALLED and yet.. apparently are.

No, they definitely aren't called. However, it does take some time and resources for the system to traverse tables of handlers in memory when looking for ones that should be called, so even ones that aren't called do consume a bit of time merely by existing in the list.

From: someone

So no, nothing is free, everything costs and the minimum cost is rather large. ... Though yes for a 5 listen script group the constant sim lag will be far less than even the occasional sensor sweep which can take upt to 0.2ms to complete.

The first statement is dubious. "Large" is a relative term, it means nothing on its own -- large compared to what? I've run scanners before that listened to thousands of channels simultaneously without noticable lag, but then being merely human, I tend not to notice a 2ms loss in response times.

In any case, yes, the cost of a listen on an empty channel is miniscule compared to the cost of a sensor sweep.

Marcuw Schnook

Scripter

Join date: 24 Dec 2005

Posts: 246

08-02-2006 09:45

From: MaidHeather Trollop

And even then, there would still be a command to go out from the lightswitch to the lights. This will cause lag no matter how it's done, and the llListen option seems to be the least dangerous. As to why I don't filter it more is because it's designed to be used in public areas, as well as the fact that I'm going to be selling it and I want to make sure that no one else has any problems with using it.

The whole mess with the llDialog is because I can see issues with lights too close to each other. For instance, with the house that I'm testing this in, I have two lights and a switch in the bedroom, but 15 meters away there's 3 lights that I want to put into the kitchen. I can code them by hand to have each let listen for a different key phrase (and no, I'm not using something like on, off or something basic like that) but hand coding won't work well for something being sold. What I want is for whenever a light or switch is rezzed (or the script is reset), it will ask what cipher to use, and give the user a choice of five different ciphers. Bu doing this, the entire system will be enclosed in one script for each object, and there won't be any cross-talk between them.

I have the whole plan worked out in my head, except that I haven't gotten a way worked out to run the llDialog command in the on_rez or state_default settings. I can't find a valid value to put in the key argument.

Try a different approach here... use a configuration notecard used in switch, in lamps that should react...

# Notecard
channel = -329847
# some arbitrary negative number

IF people are allowed to modify this notecard, read up on LSL wiki how to read a notecard as well as change() event
That way you do not have to work with dialogs forcing people to change channel numbers.

As said, lay down a protcolo in paper how you want things to work and map this to the available options you have.

MaidHeather Trollop

Script Kitty

Join date: 26 Feb 2006

Posts: 11

08-02-2006 09:49

From: Marcuw Schnook

Try a different approach here... use a configuration notecard used in switch, in lamps that should react...

# Notecard
channel = -329847
# some arbitrary negative number

IF people are allowed to modify this notecard, read up on LSL wiki how to read a notecard as well as change() event
That way you do not have to work with dialogs forcing people to change channel numbers.

As said, lay down a protcolo in paper how you want things to work and map this to the available options you have.

Actually, as of about 12am SLT this morning, I had completed the scripts with the exception of one line (the script was not resetting on it's own, so I have to force that)

Again, thank you everyone for all the help with that

Farallon Greyskin

Cranky Seal

Join date: 22 Jan 2006

Posts: 491

08-02-2006 11:24

From: Gaius Goodliffe

No, they definitely aren't called. However, it does take some time and resources for the system to traverse tables of handlers in memory when looking for ones that should be called, so even ones that aren't called do consume a bit of time merely by existing in the list.

Well that is not true, or should not be true. I have written event based messaging systems and if you had 1000 scripts with nothing but a listen on channel 99 and there was no messages on channel 99 then the total script time for all 1000 scripts /should/ be 0. It was on my engine. Instead, in SL, that is nearly enough to start lagging a sim. The LSL scripting engine is probably not truly event based. ALL scripts seem to get polled for no reason.

From: Gaius Goodliffe

The first statement is dubious. "Large" is a relative term, it means nothing on its own -- large compared to what? I've run scanners before that listened to thousands of channels simultaneously without noticable lag, but then being merely human, I tend not to notice a 2ms loss in response times.

Unfortuantely, unless you are a sim owner, your tools to actually profile your scripting are almost non-existant. Everyone that I have pointed out actual numbers to live at my sim has been SHOCKED at how poor the performance really is on "dead" scripts and link listens. Many listens in a SINGLE script are no where near as bad as having the shear NUMBER of scripts that you find in sims or on AVs however. Putting a script with a listen or even just to send messahes in every switch or button IS laggy.

If there is a way of hacing all the light switches in your house linked, you can actually communicate from "switches" by merely intercelpting start_touch events in the root of the object and getting the link number of the actual prim that was touched. How do you know the link number? You have a script in each "button" prim that tells the root (via a link message) what it's link number is, then turns itself off "llSetScriptState(llGetScriptName(), FALSE);"

That way if you have 10 light switches in your house, you really only need one script running to process all the switch data. Yes... it's PITA to code and all the switches do have to be linked which may or may not be possible, but as an example, I have reduced the frame time of my vendor from 0.150ms per pass down to 0.020ms using this method. That's a retuction opf 0.430ms per frame! So instead of about 40 vendors to completely lag a sim (assuming zero other scripts running) it would take 300 of the new ones. That's a significant reduction in lag. Wish some of those 500 prim dragon creators would do that

Hewee Zetkin

Registered User

Join date: 20 Jul 2006

Posts: 2,702

08-02-2006 13:09

Since we don't know exactly how event propagation is actually implemented, and often there is no great solution, the best we can often do is simply go on our knowledge of how well the implementation could be implemented and hope that LL has done so or will enhance the algorithms in the future. Since we know chats could be filtered pretty darn efficiently based first on the channel number, that is probably the best thing to go with unless a very speicific filter can be used for another mechanism (such as using the built-in filtering of a sensor based on key/name).

Julia Banshee

Perplexed Pixie

Join date: 16 Jan 2006

Posts: 97

08-02-2006 21:57

From: Farallon Greyskin

Well that is not true, or should not be true. I have written event based messaging systems and if you had 1000 scripts with nothing but a listen on channel 99 and there was no messages on channel 99 then the total script time for all 1000 scripts /should/ be 0. It was on my engine. Instead, in SL, that is nearly enough to start lagging a sim. The LSL scripting engine is probably not truly event based. ALL scripts seem to get polled for no reason.

Yes, well, LSL is clearly event-based, but equally clearly, it's not an efficient implementation.

Low lag communication
Gaius Goodliffe Dreamsmith Join date: 15 Jan 2006 Posts: 116	08-01-2006 22:14 From: Farallon Greyskin All due to hundreds of event handlers that SHOULD NEVER BE CALLED and yet.. apparently are. No, they definitely aren't called. However, it does take some time and resources for the system to traverse tables of handlers in memory when looking for ones that should be called, so even ones that aren't called do consume a bit of time merely by existing in the list. From: someone So no, nothing is free, everything costs and the minimum cost is rather large. ... Though yes for a 5 listen script group the constant sim lag will be far less than even the occasional sensor sweep which can take upt to 0.2ms to complete. The first statement is dubious. "Large" is a relative term, it means nothing on its own -- large compared to what? I've run scanners before that listened to thousands of channels simultaneously without noticable lag, but then being merely human, I tend not to notice a 2ms loss in response times. In any case, yes, the cost of a listen on an empty channel is miniscule compared to the cost of a sensor sweep.
Marcuw Schnook Scripter Join date: 24 Dec 2005 Posts: 246	08-02-2006 09:45 From: MaidHeather Trollop And even then, there would still be a command to go out from the lightswitch to the lights. This will cause lag no matter how it's done, and the llListen option seems to be the least dangerous. As to why I don't filter it more is because it's designed to be used in public areas, as well as the fact that I'm going to be selling it and I want to make sure that no one else has any problems with using it. The whole mess with the llDialog is because I can see issues with lights too close to each other. For instance, with the house that I'm testing this in, I have two lights and a switch in the bedroom, but 15 meters away there's 3 lights that I want to put into the kitchen. I can code them by hand to have each let listen for a different key phrase (and no, I'm not using something like on, off or something basic like that) but hand coding won't work well for something being sold. What I want is for whenever a light or switch is rezzed (or the script is reset), it will ask what cipher to use, and give the user a choice of five different ciphers. Bu doing this, the entire system will be enclosed in one script for each object, and there won't be any cross-talk between them. I have the whole plan worked out in my head, except that I haven't gotten a way worked out to run the llDialog command in the on_rez or state_default settings. I can't find a valid value to put in the key argument. Try a different approach here... use a configuration notecard used in switch, in lamps that should react... # Notecard channel = -329847 # some arbitrary negative number IF people are allowed to modify this notecard, read up on LSL wiki how to read a notecard as well as change() event That way you do not have to work with dialogs forcing people to change channel numbers. As said, lay down a protcolo in paper how you want things to work and map this to the available options you have.
MaidHeather Trollop Script Kitty Join date: 26 Feb 2006 Posts: 11	08-02-2006 09:49 From: Marcuw Schnook Try a different approach here... use a configuration notecard used in switch, in lamps that should react... # Notecard channel = -329847 # some arbitrary negative number IF people are allowed to modify this notecard, read up on LSL wiki how to read a notecard as well as change() event That way you do not have to work with dialogs forcing people to change channel numbers. As said, lay down a protcolo in paper how you want things to work and map this to the available options you have. Actually, as of about 12am SLT this morning, I had completed the scripts with the exception of one line (the script was not resetting on it's own, so I have to force that) Again, thank you everyone for all the help with that
Farallon Greyskin Cranky Seal Join date: 22 Jan 2006 Posts: 491	08-02-2006 11:24 From: Gaius Goodliffe No, they definitely aren't called. However, it does take some time and resources for the system to traverse tables of handlers in memory when looking for ones that should be called, so even ones that aren't called do consume a bit of time merely by existing in the list. Well that is not true, or should not be true. I have written event based messaging systems and if you had 1000 scripts with nothing but a listen on channel 99 and there was no messages on channel 99 then the total script time for all 1000 scripts /should/ be 0. It was on my engine. Instead, in SL, that is nearly enough to start lagging a sim. The LSL scripting engine is probably not truly event based. ALL scripts seem to get polled for no reason. From: Gaius Goodliffe The first statement is dubious. "Large" is a relative term, it means nothing on its own -- large compared to what? I've run scanners before that listened to thousands of channels simultaneously without noticable lag, but then being merely human, I tend not to notice a 2ms loss in response times. Unfortuantely, unless you are a sim owner, your tools to actually profile your scripting are almost non-existant. Everyone that I have pointed out actual numbers to live at my sim has been SHOCKED at how poor the performance really is on "dead" scripts and link listens. Many listens in a SINGLE script are no where near as bad as having the shear NUMBER of scripts that you find in sims or on AVs however. Putting a script with a listen or even just to send messahes in every switch or button IS laggy. If there is a way of hacing all the light switches in your house linked, you can actually communicate from "switches" by merely intercelpting start_touch events in the root of the object and getting the link number of the actual prim that was touched. How do you know the link number? You have a script in each "button" prim that tells the root (via a link message) what it's link number is, then turns itself off "llSetScriptState(llGetScriptName(), FALSE);" That way if you have 10 light switches in your house, you really only need one script running to process all the switch data. Yes... it's PITA to code and all the switches do have to be linked which may or may not be possible, but as an example, I have reduced the frame time of my vendor from 0.150ms per pass down to 0.020ms using this method. That's a retuction opf 0.430ms per frame! So instead of about 40 vendors to completely lag a sim (assuming zero other scripts running) it would take 300 of the new ones. That's a significant reduction in lag. Wish some of those 500 prim dragon creators would do that
Hewee Zetkin Registered User Join date: 20 Jul 2006 Posts: 2,702	08-02-2006 13:09 Since we don't know exactly how event propagation is actually implemented, and often there is no great solution, the best we can often do is simply go on our knowledge of how well the implementation could be implemented and hope that LL has done so or will enhance the algorithms in the future. Since we know chats could be filtered pretty darn efficiently based first on the channel number, that is probably the best thing to go with unless a very speicific filter can be used for another mechanism (such as using the built-in filtering of a sensor based on key/name).
Julia Banshee Perplexed Pixie Join date: 16 Jan 2006 Posts: 97	08-02-2006 21:57 From: Farallon Greyskin Well that is not true, or should not be true. I have written event based messaging systems and if you had 1000 scripts with nothing but a listen on channel 99 and there was no messages on channel 99 then the total script time for all 1000 scripts /should/ be 0. It was on my engine. Instead, in SL, that is nearly enough to start lagging a sim. The LSL scripting engine is probably not truly event based. ALL scripts seem to get polled for no reason. Yes, well, LSL is clearly event-based, but equally clearly, it's not an efficient implementation.

Welcome to the Second Life Forums Archive

Low lag communication