Welcome back Ladies and Gents,
Today I’m going to build upon the relatively basic concept we discussed in the last article (if you haven't read it, please do), I'm going to explain to concepts of dynamic port allocation and output instance grouping.
Output Instance Grouping
Now as you know the new code is based on a modular input->process->output approach, now though is approach opens a lot of options for both us and third party developers it is potentially more resource intensive than the old code implementation. I'll quickly try to explain why... In a modular design each instance of the base code and output (DHD, etc) has to monitor their various variables ready to act on any change, thus as the amount of Stargates, DHD's, etc increase more CPU cycles are used; now for a modern computer the cycle time for a few Stargates is negligible but there are certain situations where we'd be using more processing time than is truly needed, we call this the LCD scenario.
The LCD scenario:
The concept for this scenario is simple; we have a Stargate connected to a dialling computer with a few additional third party LCD screens relaying information to the player. Due to the modular design, each output (dialling computer and LCD's) are using CPU cycles to keep updated (with all the LCD's are running identical code just multiple instances); this is a inefficient use of CPU cycles as we could instead use one instance of code to update multiple LCD's (see below).
Inefficient:
(No. LCD's 4, No. Instances 4)
LCD1 > Instance1 > Output
LCD2 > Instance2 > Output
LCD3 > Instance3 > Output
LCD4 > Instance4 > Output
Efficient:
(No. LCD's 4, No. Instances 1)
LCD1,LCD2,LCD3,LCD4 > Instance1 > Output
With this scenario in mind we've created a process called Output Instance Grouping which simply groups together identical code instances and thus frees up CPU cycles, it’s on by default and will work for all third party additions.
Dynamic Port Allocation
The LCD scenario also highlighted another potential issue we call Instance Lag, this occurs when outputs of different types attempt to process a common queue; to understand this you firstly have to realize that once a queue instruction in process it is removed from said queue and different output types will have different processing times (see below).
One Output (how it’s meant to work):
Starting Queue(Instruction1,Instruction2,Instruction3)
1. Process top in Queue (Instruction1)
2. Remove from top of Queue (Instruction1)
Ending Queue(Instruction2,Instruction3)
Two Different Outputs (LCD scenario):
Starting Queue(Instruction1,Instruction2,Instruction3)
DHD1 (process time 1ms):
1. Process top in Queue (Instruction1)*
2. Remove from top of Queue (Instruction1)
Current Queue(Instruction2,Instruction3)
LCD1 (process time 1.5ms):
1. Process top in Queue (Instruction1)*
2. Remove from top of Queue (Instruction2)
Ending Queue(Instruction3)
*both processing start simultaneously
In order to compensate for the difference in processing times between various outputs we actually create a separate output variable (port) for each output instance (or grouping), these ports are dynamically created as DSF_SG_PORT[Random 5 digit number]; this way each output won't interfere with the processing cycle of another type (see below).
Two Different Outputs (LCD scenario with Dynamic Port Allocation):
Starting DHDQueue(Instruction1,Instruction2,Instruction3)
Starting LCDQueue(Instruction1,Instruction2,Instruction3)
DHD1 (process time 1ms):
1. Process top in DHDQueue (Instruction1)*
2. Remove from top of DHDQueue (Instruction1)
LCD1 (process time 1.5ms):
1. Process top in LCDQueue (Instruction1)*
2. Remove from top of LCDQueue (Instruction1)
Ending DHDQueue(Instruction2,Instruction3)
Ending LCDQueue(Instruction2,Instruction3)
*both processing start simultaneously
Well that’s the end of this article, I hope you can now understand of these concepts; if not feedback is always welcome.
