Since all digital computers and network systems can be considered as a collection of functional blocks and these blocks often contain buffers, their performance can be modeled as a collection of buffers or queues. Therefore, start developing your PDQ model by drawing a functional block diagram of the relevant architecture using elements like these:
The objective is to identify how much time is spent at each stage or block as it processes the workload of interest. Ultimately, each functional block becomes converted into a queue subsystem like those shown above. This includes the ability to distinguish sequential and parallel processing. In the language of PDQ, a queue is created using a call to either CreateNode or CreateMultiNode.
Here's how the above blocks would appear in PDQ in R as three separate models in the same R script:
Notice that each PDQ model is essentially just a list of queues. That's really all a PDQ model is: work name, queue name, service time, repeat. When all the queues (blocks) are listed, just Solve it.
# PDQ fun blocks
# Created by NJG on Mon Aug 30 2010
work <- "Requests"
arate <- 0.75
Ta <- 0.25
Tb <- 0.75
p <- 0.5
Init("Sequence Fun Blocks")
Init("Parallel Fun Blocks")
Init("Repetition Fun Blocks")
We can easily check the output of the "Sequence Fun Blocks" model. Since the combined service demand equals 1.0 second and the arrival rate is 0.75 per second, the residence time (R) had better be R = 1/(1 - (3/4)) = 4 seconds. And indeed, the RESOURCE Performance section of the PDQ Report reveals that to be correct.
The online PDQ manual contains more information about PDQ functions. Models of this type are developed as an iterative process. Do not expect to get everything correct and validated in a single pass. That never happens and if it does, you probably made a mistake in understanding either the PDQ model or the measurements used to parameterize the PDQ model. On the other hand, the good news is that you can start with almost any preliminary sketch of the functional blocks and converge to a more accurate PDQ model over time.
****** RESOURCE Performance *******
Metric Resource Work Value Unit
------ -------- ---- ----- ----
Throughput SeqBlock Requests 0.7500 Trans/Sec
Utilization SeqBlock Requests 75.0000 Percent
Queue length SeqBlock Requests 3.0000 Trans
Waiting line SeqBlock Requests 2.2500 Trans
Waiting time SeqBlock Requests 3.0000 Sec
Residence time SeqBlock Requests 4.0000 Sec
Other diagrammatic techniques e.g., UML diagrams, may also be useful but I don't understand that stuff so I've never tried it. If anyone does try that approach I'd be interested to hear about it.
See Chap. 6 "Pretty Damn Quick(PDQ)—A Slow Introduction" in my Perl::PDQ book for more ideas.