# *SERVER HP HP LP LP*

*P P*

The FSPN model of a P2P live video streaming system accurately describes the behavior of the system, but suffers from state space explosion and therefore analytic/numeric solution is infeasible. Hence, we provide a solution to the presented model using *process-based discreteevent simulation* (DES) language. The simulations are performed using SimPy which is a DES package based on standard Python programming language. It is quite simple, but yet extremely powerful DES package that provides the modeler with simulation processes that can be used for active model components (such as customers, messages or vehicles), and resource facilities (resources, levels and stores) which are used for passive simulation components that form limited capacity congestion points like servers, counters, and tunnels. SimPy also provides monitor variables that help in gathering statistics, and the random variables are provided by the standard Python random module.

Now, although we deal with vast state space, we provide the solution by identifying four distinct cases of state types. These cases of state types are combination of states of the discrete part and the continuous part of the FSPN, and are presented in Table 2. Hence, the rates at which fluid builds up in the fluid place *PB*, in each of these four cases, can be described with linear differential equations that are given in Eq. (34).


**Table 2.** Cases of state types

#### 250 Petri Nets – Manufacturing and Computer Science

$$\frac{dZ\_B\left(t\right)}{dt} = \begin{cases} 0 & \text{case1,} \\ \nu\left(\left| -V\_R - \mathbf{C}\_R \right.\right) & \text{case2,} \\ \nu\left(\left| -V\_R - \mathbf{C}\_R \right.\right) & \text{case3,} \\ 0 & \text{case4.} \end{cases} \tag{34}$$

Fluid Stochastic Petri Nets:

From Fluid Atoms in ILP Processor Pipelines to Fluid Atoms in P2P Streaming Networks 251

Qlp = Level (name = 'Queuing Station', initialBuffered=0, monitored = True) Pb = Level (name = 'Peer Buffer', initialBuffered=Zbmax, monitored = True) Pplay = Level (name = 'Play rate', initialBuffered=Rvideo, monitored = True)

**Transition** *TA* **combined with** *TAHP*

**Transition** *TA* **combined with** *TALP*

**Transition**  *TDHP*

**Transition** *TDLP*

(b) Algorithm 2: Definition of FSPN places in SimPy

 yield peerHP = tokenHP () activate (peerHP, peerHP.join())

activate (peerLP, peerLP.join())

(c) Algorithm 3: Definition of transition *TA* combined with *TAHP* and *TALP* 

yield hold, self, expovariate (Mi \* Php.amount)

yield hold, self, expovariate (Mi \* Plp.amount)

(d) Algorithm 4: Definition of transitions *TDHP* and *TDLP* 

class HPdeparture (Process): def depart (self, end): def Condition():

while True:

while True:

**Table 3.** Definitions of FSPN model components in SimPy

return (Php.amount > 0)

yield get, self, Php, 1

return (Plp.amount > 0)

yield get, self, Plp, 1

yield waituntil, self, Condition

class LPdeparture (Process): def depart (self, end): def Condition():

yield waituntil, self, Condition

yield hold, self, expovariate (*pH \** Lamda)

yield hold, self, expovariate (*pL \** Lamda)

class HPgenerator (Process): def generate (self, end): while now() < end:

class LPgenerator (Process): def generate (self, end): while now() < end: peerLP = tokenLP ()

In the next few lines (Table 3a-d) we briefly present the definitions of some of the the FSPN model components in SimPy syntax. Algorithm 1 presents the definition of SimPy processes for the different types of tokens. All the FSPN places (as well as *rPLAY*) are defined as *resource facilities* of the type "Level" and are given in Algorithm 2. The formulation of a "Level" for representing the *rPLAY* was enforced by the requirement for monitoring and modifying the *rPLAY* at each instant of time. Algorithm 3 presents *TA* combined with *TAHP* and *TALP* where it is defined as two separate SimPy Proceses that independently generate two different types of token processes. Algorithm 4 represents the definition of transitions *TDHP* and *TDLP*.

#### **Definition of HP token**


#### (a) Algorithm 1: Definition of tokens in SimPy



250 Petri Nets – Manufacturing and Computer Science

*TDHP* and *TDLP*.

def join (self):

def join (self):

while True:

else:

**Definition of HP token** class tokenHP (Process):

yield put, self, Php, 1

class tokenLP (Process):

yield put, self, Plp, 1

 yield put, self, Qlp, 1 def GuardOFF():

 yield get, self, Qlp, 1 yield put, self, Plp, 1 yield passivate, self

**Definition of LP token with integrated Guard for** *TI*

if (Php.amount + Plp.amount) == 0:

yield waituntil, self, GuardOFF

*B R R*

 

  0 1, () 2, () 3, 0 4.

*case*

*case*

(34)

*R R*

In the next few lines (Table 3a-d) we briefly present the definitions of some of the the FSPN model components in SimPy syntax. Algorithm 1 presents the definition of SimPy processes for the different types of tokens. All the FSPN places (as well as *rPLAY*) are defined as *resource facilities* of the type "Level" and are given in Algorithm 2. The formulation of a "Level" for representing the *rPLAY* was enforced by the requirement for monitoring and modifying the *rPLAY* at each instant of time. Algorithm 3 presents *TA* combined with *TAHP* and *TALP* where it is defined as two separate SimPy Proceses that independently generate two different types of token processes. Algorithm 4 represents the definition of transitions

return (((Rserver + (Plp.amount + 1)\*Rlp + Php.amount\*Rhp)/((Plp.amount +

(a) Algorithm 1: Definition of tokens in SimPy

Pcs = Level (name = 'Control Server', initialBuffered=0, monitored = True) Php = Level (name = 'Discrete Place Php', initialBuffered=0, monitored = True) Plp = Level (name = 'Discrete Place Plp', initialBuffered=0, monitored = True)

1) + Php.amount)) >= Rvideo + Rcontrol)

*dZ t V C case dt V C case*

#### (b) Algorithm 2: Definition of FSPN places in SimPy


(c) Algorithm 3: Definition of transition *TA* combined with *TAHP* and *TALP* 


(d) Algorithm 4: Definition of transitions *TDHP* and *TDLP* 

**Table 3.** Definitions of FSPN model components in SimPy

Fluid Stochastic Petri Nets:

From Fluid Atoms in ILP Processor Pipelines to Fluid Atoms in P2P Streaming Networks 253

For simulating the fluid part of the FSPN, time discretization is applied where a SimPy "Stream Processs" checks the system state in small time intervals and consequently makes changes to the level of fluid in the fluid place *PB* and *rPLAY* according to Eq. (34). For gathering the results we use the frequency theory of probability where the probability for Universal Streaming is computed as the amount of time the system spends in Universal

The simulation scenario is as follows: *rSERVER* = (*rVIDEO* + *rCONTROL)\*3*, upload bandwidth of HP is *rHP* = 700kbps, upload bandwidth of LP is *rLP* = 100kbps, and sojourn time *T* = 45 minutes. For gathering the performance results we vary the *rVIDEO* and we plot the *PUS* against the quotient of *rVIDEO/rAVERAGE,* where *rAVERAGE* for this case is 400kbps*.* For calculating the *PUS* of a single scenario we calculate the average of 150 simulations for the small system, and an average of 75 simulations for the medium and large system, while each single simulation simulates 10 hours of system activity. Initial conditions are: *ZB0* = *ZBMAX*, where *ZB0* is the

Comparison of performance of small and medium systems with and without AC is presented in Figure 12, from which an obvious conclusion is inferred that AC almost does not have any direct influence on the performance, but considering the incremented initial delay, incorporation of AC would only have a negative effect on the quality of offered services. Regarding the performance of the system in respect to system scaling, presented in Figure 13, it is obvious that scaling causes increase in performance, but only to a certain point after which performance steeply decreases. Fortunately, the performance decrease is in the region of under capacity which is usually avoided, so it can be concluded that larger systems perform better than smaller ones. Finally, Figure 14 shows that optimal buffer size is about 30 seconds of stored material, and larger buffers only slightly improve performance, but introduce quite large play out delay which leads to diminished quality of user

In the first part of this chapter, we have introduced an implementation-independent analytical modeling approach to evaluate the performance impact of branch and value prediction in modern ILP processors, by varying several parameters of both the microarchitecture and the operational environment, like branch and value prediction accuracy, machine width, instruction window size and operational profile. The proposed analytical model is based on recently introduced Fluid Stochastic Petri Nets (FSPNs). We have also

Streaming mode against the total simulation time.

**3.4. Performance evaluation results and analysis** 

In this section we make a brief evaluation of three system sizes:

1. Small system with an average of 100 concurrent participating peers 2. Medium system with an average of 500 concurrent participating peers 3. Large system with an average of 5000 concurrent participating peers

amount of fluid in *PB* in time *t*0 = 0 and all discrete places are empty.

experience.

**4. Conclusion** 

**Figure 12.** Performance of small and medium systems with and without AC

**Figure 13.** Performance in respect to system scaling

**Figure 14.** Buffer analysis of medium system without admission control

For simulating the fluid part of the FSPN, time discretization is applied where a SimPy "Stream Processs" checks the system state in small time intervals and consequently makes changes to the level of fluid in the fluid place *PB* and *rPLAY* according to Eq. (34). For gathering the results we use the frequency theory of probability where the probability for Universal Streaming is computed as the amount of time the system spends in Universal Streaming mode against the total simulation time.

## **3.4. Performance evaluation results and analysis**

In this section we make a brief evaluation of three system sizes:


The simulation scenario is as follows: *rSERVER* = (*rVIDEO* + *rCONTROL)\*3*, upload bandwidth of HP is *rHP* = 700kbps, upload bandwidth of LP is *rLP* = 100kbps, and sojourn time *T* = 45 minutes. For gathering the performance results we vary the *rVIDEO* and we plot the *PUS* against the quotient of *rVIDEO/rAVERAGE,* where *rAVERAGE* for this case is 400kbps*.* For calculating the *PUS* of a single scenario we calculate the average of 150 simulations for the small system, and an average of 75 simulations for the medium and large system, while each single simulation simulates 10 hours of system activity. Initial conditions are: *ZB0* = *ZBMAX*, where *ZB0* is the amount of fluid in *PB* in time *t*0 = 0 and all discrete places are empty.

Comparison of performance of small and medium systems with and without AC is presented in Figure 12, from which an obvious conclusion is inferred that AC almost does not have any direct influence on the performance, but considering the incremented initial delay, incorporation of AC would only have a negative effect on the quality of offered services. Regarding the performance of the system in respect to system scaling, presented in Figure 13, it is obvious that scaling causes increase in performance, but only to a certain point after which performance steeply decreases. Fortunately, the performance decrease is in the region of under capacity which is usually avoided, so it can be concluded that larger systems perform better than smaller ones. Finally, Figure 14 shows that optimal buffer size is about 30 seconds of stored material, and larger buffers only slightly improve performance, but introduce quite large play out delay which leads to diminished quality of user experience.
