PDQ 7.0.0 oddity

15 views
Skip to first unread message

Stefan Möding

unread,
Jul 14, 2021, 10:41:47 AM7/14/21
to guerrilla-cap...@googlegroups.com
Hi!

After some time I needed PDQ again and started by updating to the 7.0
release. It looks like the report output for APPROX models does not
output to computed values any more (in 6.2 it looks good).

How to reproduce:
Take the "mm1n.R" file from the demo directory of the distribution. Also
available as:
https://github.com/DrQz/pdq-qnm-pkg/blob/master/interfaces/R/pdq/demo/mm1n.R

Solve the model once with "pdq::Solve(EXACT)" and once with
"pdq::Solve(APPROX)". When using the APPROX method, some of the
statistics are zero: e.g. Max throughput, Min response, Optimal load, In
service, Utilization.

Here is a diff between the EXACT and APPROX outputs:

--- approx.txt 2021-07-14 09:26:52.000000000 +0200
+++ exact.txt 2021-07-14 09:23:28.000000000 +0200
@@ -1,7 +1,7 @@

PRETTY DAMN QUICK REPORT
==========================================
- *** on Wed Jul 14 09:26:52 2021 ***
+ *** on Wed Jul 14 09:23:28 2021 ***
*** for M/M/1//N Model ***
*** PDQ Version 7.0.1 Build 120120 ***
==========================================
@@ -23,33 +23,33 @@

Workload Users R minimum Thinktime
-------- ----- --------- ---------
-compile 100.00 0.0000 300.00
+compile 100.00 0.6300 300.00


==========================================
******** PDQ Model OUTPUTS ********
==========================================

-Solution method: APPROX (Iterations: 9; Accuracy: 0.1000%)
+Solution method: EXACT

******** SYSTEM Performance ********

Metric Value Unit
------ ------- ----
Workload: "compile"
-Mean concurrency 0.2643 Users
+Mean concurrency 0.2641 Users
Mean throughput 0.3325 Users/Sec
-Response time 0.7950 Sec
-Round trip time 300.7950 Sec
-Stretch factor inf
+Response time 0.7943 Sec
+Round trip time 300.7943 Sec
+Stretch factor 1.2607

Bounds Analysis:
-Max throughput 0.0000 Users/Sec
-Min response 0.0000 Sec
-Max demand inf Sec
-Total demand 0.0000 Sec
+Max throughput 1.5873 Users/Sec
+Min response 0.6300 Sec
+Max demand 0.6300 Sec
+Total demand 0.6300 Sec
Think time 300.0000 Sec
-Optimal load 0.0000 Users
+Optimal load 476.1905 Users


******** RESOURCE Performance ********
@@ -58,11 +58,11 @@
------ -------- ---- ------- ----
Capacity CPU compile 1 Servers
Throughput CPU compile 0.3325 Users/Sec
-In service CPU compile 0.0000 Users
-Utilization CPU compile 0.0000 Percent
-Queue length CPU compile 0.2643 Users
-Waiting line CPU compile 0.2643 Users
-Waiting time CPU compile 0.1650 Sec
-Residence time CPU compile 0.7950 Sec
+In service CPU compile 0.2094 Users
+Utilization CPU compile 20.9445 Percent
+Queue length CPU compile 0.2641 Users
+Waiting line CPU compile 0.0546 Users
+Waiting time CPU compile 0.1643 Sec
+Residence time CPU compile 0.7943 Sec


It seems to be an issue with the Report() output. The utilization for
example is correctly shown when calling the GetUtilization() function.

There is also a bigger difference for the "Waiting line" statistic:
0.26 vs. 0.05

--
Stefan

DrQ

unread,
Jul 14, 2021, 10:50:14 AM7/14/21
to Guerrilla Capacity Planning
Hi Stefan,

 Yes, I discovered this bug myself while teaching the most recent GCAP class. Blush. 

It looks like it doesn't occur with the Solve(EXACT) method. 
That could provide a temp workaround (assuming N isn't too big).

I'll put a msg here once I get it fixed. 

Well spotted and thanks for reporting with a code sample.

--njg

Reply all
Reply to author
Forward
0 new messages