[11:01] Selby.Evans @grid.kitely.com:8002: hi everyone
[11:01] Gavin.Hird @grid.xmir.org:8002: Hi Selby, Andrew
[11:01] Andrew Hellershanks: Hello, everyone.
[11:01] Gavin.Hird @grid.xmir.org:8002: I was thinking of osg assets issue
[11:02] Gavin.Hird @grid.xmir.org:8002: not region
[11:02] Ubit Umarov: hi andrew and selby.Evans
[11:02] Gavin.Hird @grid.xmir.org:8002: :-)
[11:02] Ubit Umarov: ahh well that will take time
[11:02] Ubit Umarov: estimated 1 month
[11:02] Gavin.Hird @grid.xmir.org:8002: so next year
[11:02] Ubit Umarov: till the operation end
[11:03] Gavin.Hird @grid.xmir.org:8002: Hi Jagga
[11:03] Andrew Hellershanks: Hello, Jagga.
[11:03] Jagga Meredith: hi
[11:03] Ubit Umarov: yeha not sure if holidays where taken in consideration on that time estimation
[11:03] Andrew Hellershanks: Time to do what?
[11:03] Gavin.Hird @grid.xmir.org:8002: I guess the computer is running as fast as any other day, holiday or not
[11:04] Ubit Umarov: well for those who do not understand, osgrid moved the assets services to other datacenter
[11:04] Ubit Umarov: for a few months now, the new services are running, getting missing assets from the old ones
[11:04] Gavin.Hird @grid.xmir.org:8002: and posted a message that assets not recently accessed would be gone from inventory for a month or so
[11:04] Ubit Umarov: now that was stopped
[11:05] Andrew Hellershanks: Oh. Copying the data will take quite a while..
[11:05] Ubit Umarov: the services will report missing ones, as missing
[11:05] Ubit Umarov: the rest of assets are being copied
[11:05] Ubit Umarov: and that will take a lot of time
[11:05] Andrew Hellershanks: Where is that posted on the osgrid website? I don't see it under "News".
[11:05] Ubit Umarov: bc its like 5TB of data
[11:06] Ubit Umarov: it is on the forum
[11:06] Ubit Umarov: gavin found it :)
[11:06] Gavin.Hird @grid.xmir.org:8002: https://forums.osgrid.org/viewtopic.php?f=8&t=6836
[11:07] Ubit Umarov: seems keeping the new services looking for "missing" ones on the old services did collide tthe copy process, adding a lot of lag
[11:07] Ubit Umarov: or os i was told :)
[11:07] Andrew Hellershanks: Oh. They buried it in the forum? I rarely read forums.
[11:07] Gavin.Hird @grid.xmir.org:8002: it probably means Christmas wreaths not accessed since last Christmas will have to be discounted this year.
[11:08] Andrew Hellershanks: Hello, Jamie
[11:08] Vincent.Sylvester @hg.zetaworlds.com:8002: It is quite a bit of work to tweak moving the data in assets even when file-based due to how moving large amounts of small files really isn't what most of the transfer systems tend to optimize for. With rsync I started experimenting with settings for buffers and cache as well as running multiple instances on parts of the entire dataset, because a single rsync even with the built-in multithreading does not behave well when moving 300000 files of just a few kb each. The assets data structure even in a nested setup is a nightmare never mind trying to do versioned backups in any reasonable form without really stretching the limits of what compression can do
[11:09] Ubit Umarov: ofc you ppl on HG should not notice the issue
[11:09] Jamie.Jordan @grid.kitely.com:8002: hi everybody couldn't get the viewer to load today
[11:09] Gavin.Hird @grid.xmir.org:8002: ok...
[11:10] Ubit Umarov: viewer worked ok for me here
[11:10] Gavin.Hird @grid.xmir.org:8002: speaking of viewer, I posted anew version a few days back
[11:10] Andrew Hellershanks: Jamie, np. You still managed to get here.
[11:10] Ubit Umarov: just sl is having some kind of issues
[11:10] Andrew Hellershanks: Gavin, anything new and exciting in it?
[11:10] Gavin.Hird @grid.xmir.org:8002: yes
[11:10] Selby.Evans @grid.kitely.com:8002: hi Jamie
[11:10] Ubit Umarov: better remember url gavin :)
[11:11] Gavin.Hird @grid.xmir.org:8002: you can set glowing items to be 100 % transparent and it will retain the glow
[11:11] Ubit Umarov: viewer download url i mean
[11:11] Gavin.Hird @grid.xmir.org:8002: excellent for making ghosts and stiuff
[11:11] Jamie.Jordan @grid.kitely.com:8002: Hi Selby
[11:11] Andrew Hellershanks: It wasn't remembering the glow setting before now?
[11:11] Gavin.Hird @grid.xmir.org:8002: https://www.dayturn.com/viewer/index.php?resources/
[11:11] Gavin.Hird @grid.xmir.org:8002: no
[11:11] Ubit Umarov: ohh like the light of the dark moon on the ocean?
[11:12] Ubit Umarov: they forgot to check glow on transp prims?
[11:12] Gavin.Hird @grid.xmir.org:8002: that is a different type of glow Ubit
[11:12] Ubit Umarov: but similar class of bugs :P
[11:12] Gavin.Hird @grid.xmir.org:8002: they did
[11:12] Andrew Hellershanks: IIRC, I don't use a glow more than about 30% as it wipes out any texture on the prim and all you see is white.
[11:12] Ubit Umarov: ( but moon should not be dark )
[11:13] Gavin.Hird @grid.xmir.org:8002: Minimum system requirement is now Windows 10, It was XP....
[11:13] Kayaker Magic: Hmm, I took advantage of the no-glow on transparency to make blinking lights!
[11:13] Andrew Hellershanks: Gavin, That is a big jump. That may exclude a number of users.
[11:13] Gavin.Hird @grid.xmir.org:8002: yes
[11:14] Ubit Umarov: jumped 7 and 8 :)
[11:14] Gavin.Hird @grid.xmir.org:8002: also bumped the macOS version up a notch
[11:14] Ubit Umarov: and vista!
[11:14] Gavin.Hird @grid.xmir.org:8002: Vista
[11:14] Gavin.Hird @grid.xmir.org:8002: :-)
[11:14] Ubit Umarov: opensim supports vista!
[11:14] Ubit Umarov: not XP :(
[11:14] Kayaker Magic: Hmm, I'd give Gavin a copy of my blinking lites, but that asset cannot be found in inventory :(
[11:15] Ubit Umarov: ( well vista can have .net 4.6, XP can't, just that )
[11:15] Gavin.Hird @grid.xmir.org:8002: There is a blinking lights script in the LSL library
[11:15] Gavin.Hird @grid.xmir.org:8002: I gace Ubit a copy, so maybe he has it in his lib?
[11:15] Gavin.Hird @grid.xmir.org:8002: gave*
[11:15] Ubit Umarov: the asset will be there in 2022 :)
[11:15] Andrew Hellershanks: Kayaker, the forum notice says you may have to wait a month.
[11:16] Ubit Umarov: script blinker?
[11:16] Gavin.Hird @grid.xmir.org:8002: yes
[11:16] Ubit Umarov: yeah i have the asset
[11:16] Gavin.Hird @grid.xmir.org:8002: it use glow
[11:16] Ubit Umarov: who needs it?
[11:16] Ubit Umarov: timer()
{
isOn = !isOn;
if( isOn ) llSetLinkPrimitiveParamsFast( LINK_THIS,[PRIM_GLOW,faceNo,glowAmount] );
else llSetLinkPrimitiveParamsFast( LINK_THIS,[PRIM_GLOW,faceNo,0.0] );
}
[11:16] Ubit Umarov: it does
[11:17] Andrew Hellershanks: Nice simple script.
[11:17] Gavin.Hird @grid.xmir.org:8002: viewer DL url:: https://www.dayturn.com/viewer/index.php?resources/
[11:17] Kayaker Magic: This is not a script blinker, it uses llSetTextureAnim to move color and TRANSpARENCY across mesh parts.
[11:18] Gavin.Hird @grid.xmir.org:8002: put it in a cube Ubit
[11:18] Ubit Umarov: blinkers can be a good region killer
[11:18] Kayaker Magic: So the viewer does all the work.
[11:18] Gavin.Hird @grid.xmir.org:8002: I am sure the region can sustain one blinker
[11:18] Andrew Hellershanks: Ubit, depends partly on the timer used.
[11:19] Ubit Umarov: set a light (or glow) is a full prim update sent to all viewers in view
[11:19] Ubit Umarov: seem regions totally down bc of that
[11:19] Ubit Umarov: full flood on lludp
[11:19] Ubit Umarov: the llSetTextureAnim is a nice way to avoid that
[11:19] Gavin.Hird @grid.xmir.org:8002: CPU for the region is 0.11% so I am sure one blinker script will not kill it
[11:19] Kayaker Magic: Yeah, I've seen people bring a region to it's knees with xmas lights! That is why I wrote this client-based blinker.
[11:20] Jagga Meredith: kewl
[11:21] Ubit Umarov: hope all xmas lights all use texture animation or similar
[11:22] Andrew Hellershanks: I've seen several that use short(ish) timers so the scripts show a high runtime number.
[11:22] Ubit Umarov: it is not just cpu
[11:22] Ubit Umarov: it is massive use of lludp
[11:22] Object: Script running
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002: It's not as bad as you think, had nearly 40 people on a region with about 30 lights each color and point light along with a few more color changers and so on, worked better than it would have 5 years ago that's for sure
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002: We have come quite a way since those days when too many prim updates would crash regions
[11:23] Gavin.Hird @grid.xmir.org:8002: here is the blink script
[11:23] Vincent.Sylvester @hg.zetaworlds.com:8002: These days you just get scene update queue failures which makes it look like scripts stopped
[11:24] Jagga Meredith: not copyable
[11:24] Vincent.Sylvester @hg.zetaworlds.com:8002: Get that from time to time when folks decide to place 800 line scripts in something just to align a door
[11:24] Andrew Hellershanks: The first indication that a script might be causing problems is high script runtime. Users can't see any stats about UDP traffic.
[11:24] Ubit Umarov: in fact they can
[11:24] Gavin.Hird @grid.xmir.org:8002: it looks slightly strange when set to 100% trans
[11:24] Ubit Umarov: just not the source
[11:25] Vincent.Sylvester @hg.zetaworlds.com:8002: I have quite a bit of lighting with normally heavy functions, with a few tricks you can get the region impact down a lot, one wrong move and cpu go bye bye though
[11:25] Ubit Umarov: but lludp is there on top of stats
[11:25] Ubit Umarov: ( what we can't see is http, except on singularity =
[11:26] Vincent.Sylvester @hg.zetaworlds.com:8002: I have not seen a single user consume more than 3mbit after region is loaded for them, unless you are doing DSL over a piece of wet string you're usually okay on the network front
[11:26] Kayaker Magic: Speaking of bad scripts, Discovery Grid found one of their users running a script that saved a notecard every second, and ran a bunch of copies of it.
[11:26] Ubit Umarov: singularity does have a nice http bandwidth usage thing
[11:26] Ubit Umarov: well now i see me using 50MB alone :p
[11:26] Ubit Umarov: on a region
[11:27] Andrew Hellershanks: If a script doesn't have a high runtime I wouldn't think about checking network traffic. Even if it did, I still wouldn't have thought about network traffic. I rarely pull up that statistics panel so I don't remember all of the stats it shows.
[11:27] Vincent.Sylvester @hg.zetaworlds.com:8002: If we get into a discussion on the deficiencies of the protocol we'll be here for days, so many redundant calls and things happening, in the end it magically still works even if it probably shouldn't
[11:28] Ubit Umarov: i did change the http throttling on assets
[11:28] Andrew Hellershanks: :)
[11:28] Gavin.Hird @grid.xmir.org:8002: now cube wtih script can be copied
[11:29] Ubit Umarov: replaced throttle by a diferent thing, just more concerned with fair usage
[11:29] Jagga Meredith: *stares at cube, mesmerized*
[11:29] Ubit Umarov: adn with type of data priority
[11:29] Ubit Umarov: in case you did not notice, avatars do rez a lot faster now :p
[11:29] Andrew Hellershanks: hm... makes me wonder if anyone has made a lava lamp?
[11:29] Ubit Umarov: if you and region do have bandwitdh
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002: Slow color fades are easy to do in Yengine now due to better handling of script delays
[11:30] Vincent.Sylvester @hg.zetaworlds.com:8002: Just need to find the right sweetspot for the function complexity and the thing writes itself
[11:31] Ubit Umarov: ( note that as nothing to do with some forks that just did removed throttles without any replacement code )
[11:31] Ubit Umarov: has
[11:31] Vincent.Sylvester @hg.zetaworlds.com:8002: Good measure of cpu clock seeing how quickly the light changes
[11:31] Ubit Umarov: ok, and what news do you have about opensim?
[11:31] Ubit Umarov: :)
[11:32] Andrew Hellershanks: Not a lot of change this week but some.
[11:33] Andrew Hellershanks: Some settings that were previously only available for XEngine are now available in YEngine.
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002: Mostly bugfixing which I love to see, some long standing issues even that finally get attention, just wish mantis was a bit more flexible in all that
[11:33] Vincent.Sylvester @hg.zetaworlds.com:8002: Can't really establish a "to be tested" or "can't fix right now" status
[11:33] Andrew Hellershanks: There were some changes related to CO2 but I don't know what is CO2.
[11:34] Ubit Umarov: jezzz
[11:34] Vincent.Sylvester @hg.zetaworlds.com:8002: Ask a cow Andrew, they make a lot of it I heard
[11:34] Jagga Meredith: some gas? (I know, "don't start")
[11:34] Andrew Hellershanks: Vincent, I thought that was methane.
[11:34] Andrew Hellershanks: :)
[11:34] Ubit Umarov: those are more methane Vicent :)
[11:35] Gavin.Hird @grid.xmir.org:8002: All of you are making a lot of CO2
[11:35] Gavin.Hird @grid.xmir.org:8002: every exhale has 40X the CO2 compared to your inhale
[11:35] Ubit Umarov: yes but our CO2 is balanced
[11:35] Ubit Umarov: plants did capture all of it in our life time
[11:36] Ubit Umarov: so our co is kinda "neutral"
[11:36] Gavin.Hird @grid.xmir.org:8002: CO2 is compltely irrelevant for any discussion. It is a trace gas of 0.04% of the atmosphere
[11:36] Ubit Umarov: but yeah on the commits is abotu saving a little of cpu work, so power, so co2 on most regions
[11:36] Ubit Umarov: :p
[11:37] Andrew Hellershanks: One bug fix this past week prevents some prims from changing type when setting them to flex using llSetPrimitiveParams. (mantis 7896 and 7910).
[11:37] Ubit Umarov: "try save some zeptogram of CO2"
[11:37] Ubit Umarov: not the optimistic on real impact on co2 :p
[11:37] Gavin.Hird @grid.xmir.org:8002: all power on my regions are generated from hydroelectric plants
[11:37] Andrew Hellershanks: Ubit, I read that and have no idea what it meant.
[11:37] Ubit Umarov: wlel you know now :p
[11:37] Vincent.Sylvester @hg.zetaworlds.com:8002: Memory has been less of an issue with OpenSim, but given you can only really use one or two cores per instance, think most I have seen is 330% cpu, saving small bits here and there helps
[11:38] Andrew Hellershanks looks up the definition of zeptogram
[11:38] Andrew Hellershanks: No such word found in the dictionary.
[11:38] Gavin.Hird @grid.xmir.org:8002: :-)
[11:38] Vincent.Sylvester @hg.zetaworlds.com:8002: Some of the changes I can imagine in certain situations when used a lot might make quite some more impact, but nothing you can really measure given the flux of cpu and threading
[11:38] Ubit Umarov: you have a bad dic lol
[11:39] Ubit Umarov: it is 10^-21 gram :p
[11:39] Gavin.Hird @grid.xmir.org:8002: yeah
[11:39] Gavin.Hird @grid.xmir.org:8002: 1 zeptogram = 0,001 attogram
[11:39] Jagga Meredith: *remembers high school math teacher saying "oh yeah, there's things like Tera- and pico- but you'll never use them"
[11:39] Gavin.Hird @grid.xmir.org:8002: or 1 000 yoctogram
[11:40] Andrew Hellershanks: I've never seen zepto before in terms of a unit of measure.
[11:40] Ubit Umarov: well mantis 7896 and 7910 where actually a bug we had since ever
[11:40] Ubit Umarov: hope fixed now
[11:40] Ubit Umarov: actually did commit that today
[11:40] Andrew Hellershanks: Jagga, I often use pico.
[11:40] Jagga Meredith: exactly
[11:40] Vincent.Sylvester @hg.zetaworlds.com:8002: I was looking at an issue earlier this week in regards to links of deleted items not being deleted when commanded as such, but it appears that only "sticks" around until you relog, which I am not sure why that might be, but I suppose that does make it a non-issue or at least self correcting
[11:41] Ubit Umarov: hard to same picogram of CO2 changing a few lines of code :p
[11:41] Ubit Umarov: hard to save...
[11:42] Jagga Meredith: is old
[11:43] Ubit Umarov: some lsl settings on [xengine] are needed on [yengine] as andrew said some settings that where present only on X are needed also o Y
[11:43] Ubit Umarov: currently LSLapi code looks for them on respective engine
[11:43] Ubit Umarov: so i did duplicate them
[11:44] Ubit Umarov: possible in future they should have own section
[11:45] Andrew Hellershanks: I think I finally get the CO2 reference in the comment. It was Ubits slightly cryptic way of saying that he made some optimizations in the code to save some clock cycles.
[11:45] Vincent.Sylvester @hg.zetaworlds.com:8002: I did finish up on fixing up the previously broken and disabled script engine tests for X and made them available as copies to Y as well. Ubit handed me a compliance testing script that appears to work almost completely in Y, with X misbehaving a bit more. I wrote a test for this script to run on both so that changes made to the script engines can now be tested for regressions
[11:45] Ubit Umarov: well not for gavin.Hird
[11:46] Ubit Umarov: but sure on servers in Poland for example
[11:47] Gavin.Hird @grid.xmir.org:8002: not saving CO2, but reducing the power bill
[11:47] Ubit Umarov: im considering underclock my machine :)
[11:47] Gavin.Hird @grid.xmir.org:8002: since Europe is in such a power squeeze, we sell all our power to it, so my price per kWh has gone up 11x the last month
[11:48] Vincent.Sylvester @hg.zetaworlds.com:8002: Working on the tests did find some issues with changed firing randomly when not commanded as such, though I am not entirely sure if that really is the case, scratching me head over that one still
[11:49] Andrew Hellershanks: Vincent, good to have a proper set of tests for the scripting engine. Do they test the timing accuracy some script functions?
[11:49] Andrew Hellershanks: Hello, Dennis.
[11:50] Gavin.Hird @grid.xmir.org:8002: Hi Dennis
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: I could write a test like that I guess
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: There exists a test for running a plain script, I copied a lot of that code and just stuffed the compliance test script in there to run
[11:50] Andrew Hellershanks: I have found timing issues with KFM and/or llTargetOmega.
[11:50] Vincent.Sylvester @hg.zetaworlds.com:8002: Technically can run any script and check the output
[11:51] Gavin.Hird @grid.xmir.org:8002: has not LL published a large number of script tests?
[11:51] Ubit Umarov: the one i shared with vincent is one of those gavin.Hird
[11:51] Vincent.Sylvester @hg.zetaworlds.com:8002: Timers are strange, but internally given the way they work you can make minor changes to the way you call the timer up which result in increased accuracy, but it will, not even in SL, be accurate over time
[11:52] Gavin.Hird @grid.xmir.org:8002: http://wiki.secondlife.com/wiki/LSL_Test_Harness
[11:52] Ubit Umarov: but usefull bc checks some evaluation order eve
[11:52] Gavin.Hird @grid.xmir.org:8002: ok
[11:52] Ubit Umarov: a case made VIncent brain smoke a bit :)
[11:52] Andrew Hellershanks: Vincent, the problem with that is that it isn't reliable. You copy the script to a different grid and you have to recalculate the adjustments.
[11:53] Andrew Hellershanks: In some cases the viewer may be (part of?) the cause of timing issues.
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002: Well you can almost always cut 0.3% off the time you want, so 10 becomes 9.7 then you make sure to 9.7f or the double whammy 9.777777f and you get about twice the accuracy over ten minutes than before
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002: On most but the most loaded of regions that tends to work quite well
[11:54] Vincent.Sylvester @hg.zetaworlds.com:8002: I used to calc the difference in timing and once past 1 second just reset the timer event
[11:55] Vincent.Sylvester @hg.zetaworlds.com:8002: Or use a smaller timer in the range of accuracy you want, say every 5 minutes for an hourly check
[11:55] Ubit Umarov: (jesus no :P )
[11:55] Dennis Ravnsholm: thanks
[11:56] Ubit Umarov: do not do that :p
[11:56] Andrew Hellershanks: I suspect that either the grid code or viewer code doesn't properly track the difference in time when some functions are called.
[11:56] Vincent.Sylvester @hg.zetaworlds.com:8002: I mean there is also the matter of the more you stuff into the timer event the slower that will be overall and it only restarts the count once the event has concluded not when it is fired
[11:56] Andrew Hellershanks: When I wrote a routine to determine pulses per second I took in to account that the time between calls might not be 1 second. I took the pulse count and divided by the actual passage of time since the previous call.
[11:57] Vincent.Sylvester @hg.zetaworlds.com:8002: Like if you want something to run twice a second don't stuff a one-liner in there doing ten things, put ten lines all doing one thing, reducing the amount of "subroutines" so to speak
[11:57] Andrew Hellershanks: Heading out, Kayaker?
[11:58] Vincent.Sylvester @hg.zetaworlds.com:8002: In the end you are just applying tricks and workarounds though, accurate timing is a billion dollar industry for the stock markets around the globe, little ole OpenSim won't give them a run for their money any day soon
[11:58] Kayaker Magic: Not me! Someone landed on my head though...
[11:58] Gavin.Hird @grid.xmir.org:8002: there are all kinds of stalls in the viewer depending on what else is happening, so I guess it cannot deliver accurate timing
[11:58] Andrew Hellershanks: oh, ok. It looked like you were standing.
[11:59] Kayaker Magic: Welcome Dennis!
[11:59] Kayaker Magic whispers: You are an hour late for the meeting!
[11:59] Andrew Hellershanks: Is there no way to know what the actual time was then compare that against what time it is now? It may not be one second. It might be 1.04 seconds. Timing can be accurate if you use the actual time between calls.
[12:01] Vincent.Sylvester @hg.zetaworlds.com:8002: You can get accurate times in larger measures, just below say 10 seconds you run out of digits before the comma
[12:01] Andrew Hellershanks: I haven't dug in to the portion of code that deals with time passage. I might do that if I can get free of some other work I need to be doing.
[12:02] Gavin.Hird @grid.xmir.org:8002: the viewer has timing code in llcommon/llfasttimer.cpp/h
[12:02] Gavin.Hird @grid.xmir.org:8002: because you also have llcommon/llframetimer.cpp/h
[12:02] Andrew Hellershanks: Gavin, ty. I'll have to look for the equivalent in OS.
[12:02] Vincent.Sylvester @hg.zetaworlds.com:8002: I suppose one could internally track if the event gets out of sync and reschedule it similar to testing whether the reported timer event happened at modulo zero of set time or not, but that adds complexity which means less overall speed
[12:03] Gavin.Hird @grid.xmir.org:8002: and llcommon/llheartbeat.cpp/h
[12:03] Vincent.Sylvester @hg.zetaworlds.com:8002: When you need to run things every minute you generally don't care much for a few seconds
[12:03] Andrew Hellershanks: Timing used to be a bit more accurate than it is now. It is something that I've noticed and affects something I was working on so I may have to dig in to it.
[12:04] Andrew Hellershanks: Vincent, no but when you are doing things based on time such as things being moved about via KFM it matters.
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002: Again that comes down to the lower the interval time the worse it gets
[12:05] Andrew Hellershanks: I just noticed we are at the top of the hour. Any one have a question they want to ask who may need to be leaving soon?
[12:05] Andrew Hellershanks: Vincent, not if it is done right.
[12:05] Vincent.Sylvester @hg.zetaworlds.com:8002: Also tweaking the code in the event itself to be less heavy so the event can conclude quickly
[12:05] Andrew Hellershanks: Code should not assume that it is being called once per second. It should check how much real time has elapsed between calls and act accordingly.
[12:05] Gavin.Hird @grid.xmir.org:8002: it probalby isn't, Andrew
[12:06] Andrew Hellershanks: Gavin, perhaps not. I'm just taking educated guesses as to the cause(s) of the issues I'm seeing.
[12:07] Gavin.Hird @grid.xmir.org:8002: sure
[12:07] Vincent.Sylvester @hg.zetaworlds.com:8002: The problem is changing it to be more accurate most likely means heavier code internally which then means timers are worse for region performance as they already are, which in turn means less usage and potentially folks going to while sleep which has a host of other issues
[12:08] Jagga Meredith: *is getting recursive headache*
[12:08] Vincent.Sylvester @hg.zetaworlds.com:8002: I mean I guess could always to a ossl variant that uses some atomic clocks or something heh
[12:08] Andrew Hellershanks: No, it doesn't have to be much heavier. It really is about how the code determines how much time has passed.
[12:08] Jagga Meredith: GPS time
[12:09] Kayaker Magic: Between the server, the internet and the viewer, I just always assume timers will NEVER be accurate and code accordingly.
[12:11] Andrew Hellershanks: For example, If you could get the number of clock ticks that have passed since the last time your code ran and you know how many clock ticks there are per second then you would know if it has been one second since the last time your code ran. If there are more, or less ticks, than the number for one second you can take that into account.
[12:12] Andrew Hellershanks: There might still be some slippage but overall that is a simple way to keep track of the passage of time.
[12:12] Jagga Meredith: you're assuming instantaneous delivery of "clock ticks"
[12:12] Gavin.Hird @grid.xmir.org:8002: and that clock ticks are a constant
[12:12] Vincent.Sylvester @hg.zetaworlds.com:8002: You know that sounds fine in writing but in code that's a different story
[12:13] Andrew Hellershanks: Clock ticks at the system level should be a constant or you have some serious problems.
[12:13] Gavin.Hird @grid.xmir.org:8002: yes for realtime clocks
[12:13] Gavin.Hird @grid.xmir.org:8002: but cpu clock is not constant
[12:13] Jagga Meredith: ...like other stuff happening at server level
[12:16] Andrew Hellershanks: You do need to use a reliable clock source. I've done it on embedded systems without any special hardware. .
[12:16] Ubit Umarov: i spoke about current kfm and timing issues on several meetings already so, not doing it now
[12:18] Andrew Hellershanks: Ubit, I know you said you had made some changes to the code. I just know that the timing isn't as accurate now as it used to be.
[12:20] Andrew Hellershanks: It is getting nearer half past the hour. Any other topics for today before we wrap up todays meeting?
[12:21] Andrew Hellershanks: If there is nothing further that will be it for this week.
[12:21] Andrew Hellershanks: Thank you all for coming. See you again next week.
