Talk:Wizardry and Steamworks/Randomness, Entropy and Statistics
"There is no obvious reason for a region to have a cyclic FPS"
I can think of one: a periodic services used to backup the simulator state. It should cause a dip. I worry about the quality and quantity of bits available from llGetRegionFPS, choosing the wrong max could skew results dramatically. -- Strife (talk|contribs) 12:02, 13 January 2012 (PST)
Not convinced it is that obvious: but would make a nice project for some volunteers to test this out!
That is true however, there are many other concurrent processes running in parallel with a backup process which may alter the FPS in un-predictable ways. Similarly, just the usage of the simulator by the avatars would induce fluctuations. Additionally, as I take it GPU operations are split off from CPU driven operations (after all, that would be the point for an auxiliary processor).
I am unsure whether:
- there is a back-up process running or its periodicity
- whether it would provoke a massive and cyclic (truly periodic) fluctuation on the lower mantissa of the reported FPS number.
- whether the cumulative: avatars and tasks on the simulator, backup process and additional processes that may run on simulator servers
- the database for a simulator is not centralised and backed-up or if the simulator itself performs the backing up.
would lead to some true cyclic induced error: careful here, we're talking about an well-defined T, not just some random fluctuations.
Either way, we find it pretty clear that even avatars, provided they have rez / scripting permissions over the land may inject some true T periodicity in the FPSrand method: in the later, coming up (, when we have more time) demonstration, we will use a lag-pulse generator to influence the entropy.
So far, llGetRegionTimeDilation and llGetRegionFPS are the "best we have" candidates for some source of true entropy given what Second Life exposes on the API. However, OpenSIM users, would giggle and jump up and down because they have that stats-function mentioned in the article that returns stuff such as: In/Out Packets, Network Lag and pretty much everything else from the View -> Show Statistics - which is pretty cool. :-) The mentioned OpenSIM API function could be used to harness additional entropy: sort of like selecting a little of each and decreasing the chances that an adversary (under some restrictions) could influence ALL the sources of entropy at will.
For Second Life though, some exhaustive search of the functionality that is exposed by Linden on the API relating to simulator statistics would be great. Perhaps there might be some other function out there that may offer a potential source of entropy... At least we know that stuff like llWind is out of the question...
EDIT: ah yeah, for got this: the TRNGs work correctly in ideal conditions, of course. The real-life TRNGs, some of them, gather data from wind. Of course, if you put a blow-dryer directly on the detector, it will not be worth much anymore... :-P Hence the need for several sources (like OpenSIM), or at least not some gimmick with a blow-dryer and a bad attitude. xD
Kira Komarov 12:42, 14 January 2012 (PST)