In this paper we compare the simulation results of two types of //1 the implemented threshold-based renovation mechanism. As usual renovation implies probabilistic dropping of customers from the queue upon service completions. In the systems of the first type there is the threshold value (indication the queue length) which controls the activation of the renovation mechanism. In the systems of the second type the threshold value not only triggers the renovation, but also specifies the area in the queue wherefrom the customers cannot be dropped. For both types of systems the main stationary characteristics are obtained. Numerical results are also provided, which illustrate the performance of the queues for diferent sets of simulation parametres. The simulation results comparison are presented in the section 4. renovation mechanism, active queue management, threshold policy, congestion control, GPSS simulation According to [1], the development of modern mechanisms active queue management (AQM) keeps attracting attention from the operation research community. The classic such mechanism is the RED [2, 3] mechanism.
CEUR
Consider the / /1/∞
results are presented in the section 4. The last section concludes the paper with the short queuing system, shown in the Fig. 1, with the implemented renovation [4, 5] mechanism and a threshold value 1, which determines the boundary in the queue, starting from which the dropping of customers begins.
Renovation mechanism: let be the number of requests in queue. If 0 ≤ ≤ 1, then after the end of the service, the request simply leaves the system. If > 1, then either with the probability (0 < < 1)
the request that has been served simply leaves the system, or with the probability = 1 − it resets the queue.
Consider now the / /1/∞
system, shown in the figure 2, where the threshold value 1 defines not only the boundary in queue, upon exceeding which by the current queue length the renovation mechanism is activated, but also specifies the area in the queue, wherefrom the customers cannot be dropped. (0 < < 1) = 1 − value 1.
Renovation mechanism: let be number of requests in the queue. If , then after the end of the service, the request simply leaves the system. If > 1, then either with the probability the request that has been served simply leaves the system, or with the probability at the moment of leaving the system, reset all requests located after the threshold
The results of the simulation models of both systems are presented in the tables, which are constructed as follows: the first line - the number of orders generated during the simulation; the second line is the number of requests served; the third line is the number of requests serviced without calling the renovation mechanism; the fourth line is the number of discarded requests; the fith line is the probability of servicing the request accepted into the system; the sixth line is the probability of dropping (due to the renovation mechanism) a request accepted into the system; the seventh line - the values of the average queue length; the eighth line is the maximum length of the queue; the ninth line is the average waiting time for service; the tenth line - how many times the renovatione mechanism was called without dropping orders; the last line - how many times the renovatione mechanism was called with dropping requests
The first three tables consider the behavior of various characteristics of two systems (sys.1 and sys.2) at low values of the drop probability for the following system load options: medium load ( = 0.5 ) — see table 1, high load ( = 1 ) — see table 2, and very high system load ( = 2 ) — see table 3.
At low values of the system load ( < 0.2 ) , the update mechanism is not activated in both systems, and therefore for these systems absolutely the same values of the main characteristics are obtained.
The first table has a low threshold value 1 = 10, otherwise the update mechanism is not enabled, for the second and the third tables the threshold value 1 is set 30. The simulation time is 100000 unit of time.
As can be seen from the simulation results, presented in the table 1, the time characteristic (average waiting time of a task in the queue) and queue size characteristics (average and maximum queue lengths) in the case of an average load ( = 0.5 ) for the systems of both types are approximately the same, and in the systems of the second type the probability of dropping a task is zero.
As can be seen from the simulation results, presented in the table 2, the time characteristic (average waiting time of a task in the queue) in the case of high load ( = 1 ) for the second type system is 10-20% more than for the first type system (similarly for average and maximum queue lengths). But the probability of dropping an accepted claim for a system of the first type is four times greater than the value of the saim characteristic for a system of the second type
Finally, for the case of ultra-high system load ( = 2 and more) the values of the probability of tasks dropping are approximately the same. The values of average waiting time, average and maximum queue length for the second type system are only 10% higher then for the first type system.
The following three tables show the dependence of the characteristics of both systems on the threshold value; three options for the system load are also considered: medium ( = 0.5 ) — see
In this paper we compared the simulation results for two types of a single-server queuing system / /1/∞ with an infinite capacity storage, with renovation mechanism and a threshold value.
Comparing the simulation results, we can draw the following conclusion: at low and superlarge loads, systems of both types behave approximately the same; at high loads, a system of the second type is preferable, since it is significantly less likely to drop an incoming request.
Our future goal is to compare the analytical expressions for some general time-probability characteristics (such as the distribution of the number of applications in the system ) with the obtained simulation results in the GPSS system. Also we plan to analyze the / /1/∞ queueing system with renovation mechanism and two threshold values (the first value controls the activation of the renovation mechanism, the second value specifies the area in the queue wherefrom theincoming tasks cannot be dropped).
This paper has been supported by the RUDN University Strategic Academic Leadership Program (Viana C. C. Hílquias and I.S. Zaryadov, mathematical model formulation and simulation model development). Also the publication has been funded by Russian Foundation for Basic Research (RFBR) according to the research project No. 19-07-00739 ( I.S. Zaryadov, mathematical model development and numerical analysis) [1] F. J.Baker, G. Fairhurst, IETF Recommendations Regarding Active Queue Management, Request for Comments RFC 7567, Internet Engineering Task Force (IETF), 2015. URL: https://datatracker.ietf.org/doc/html/rfc7567.
3 999419 999042 997899 998881 967376 967608 1519 161 0.9985 0.9998 0.0015 0.0002 0.496 0.499 18 18 0.1 0.1 30219 30970 303 302
7
ADVANCE ( E x p o n e n t i a l ( 1 , 0 , 6 ) ) TEST L CH$LIST1 , V$Q_1 , m e tk a2 RELEASE P r i b o r TRANSFER , m e t k a _ e n d me tk a2 TEST E FN$PROB , 0 , me tk a 3 me tk a3 RELEASE P r i b o r m e t k a _ e n d UNLINK L I S T 1 , metka1 , 1 TERMINATE 0
GENERATE ( E x p o n e n t i a l ( 1 , 0 , 1 / 1 0 ) ) LINK LIST1 FIFO metka1 metka1 SEIZE P r i b o r ADVANCE ( E x p o n e n t i a l ( 1 , 0 , 1 / 1 1 ) ) TEST L CH$LIST1 , V$Q_1 , metka2 RELEASE P r i b o r TRANSFER , metka_end metka2 TEST E FN$PROB , 0 , metka3 RELEASE P r i b o r UNLINK LIST1 , metka1 , 1 UNLINK LIST1 , metka4 , ( CH$LIST1 −V$Q_1 ) metka4 TERMINATE 0 metka3 RELEASE P r i b o r metka_end UNLINK LIST1 , metka1 , 1 TERMINATE 0 ; Working t i m e ( s e c o n d s ) ; Minus one minute ; S t a r t from t h e f i r s t minute