177 lines
5.6 KiB
Markdown
177 lines
5.6 KiB
Markdown
## What is **Response Time** in the context of system performance?
|
|
|
|
---
|
|
|
|
⏱️ The duration from a **start event** (e.g., sending a request) to an **end event** (e.g., receiving the output).
|
|
%%%
|
|
How is **Throughput Capacity** defined?
|
|
|
|
---
|
|
|
|
🚀 The **maximum allowed frequency** of responses. Note that these may overlap in time, such as in web servers handling multiple clients.
|
|
%%%
|
|
|
|
## What does the **Utilization** of a resource measure?
|
|
|
|
---
|
|
|
|
📉 The **percentage of time** a resource remains in a "busy" state versus an "idle" state.
|
|
%%%
|
|
What is the difference between a **delay measure** and a **deadline** in embedded systems?
|
|
|
|
---
|
|
|
|
📐
|
|
|
|
- **Delay measure**: The actual measured time between stimulus and response.
|
|
- **Deadline**: The **maximum allowed delay** the system can tolerate.
|
|
%%%
|
|
When measuring by events, what does **"Wall Clock Time"** refer to?
|
|
|
|
---
|
|
|
|
⌚ The actual time elapsed as measured by a **system timer** or stopwatch, including execution, transfer latency, and waiting (queuing).
|
|
%%%
|
|
What are the standard components of an **Event Log** entry?
|
|
|
|
---
|
|
|
|
📝 `[time, entity, event code, ...additional data]`
|
|
%%%
|
|
How do you calculate **Throughput** using event counters?
|
|
|
|
---
|
|
|
|
🧮 By taking the **total count** of events and **dividing it by the duration** of the measurement period.
|
|
%%%
|
|
|
|
## What are the **two methods** for measuring the state of an entity (e.g., "Device Busy")?
|
|
|
|
---
|
|
|
|
1. **Event Logging**: Record when it "goes busy" and "goes idle," then sum the total time.
|
|
2. **Sampling**: Use a **timer-based daemon** to periodically check the state and count how often it is busy vs idle.
|
|
%%%
|
|
|
|
## What is a major limitation of **Processor-level** measurements?
|
|
|
|
---
|
|
|
|
🚫 There is **no application context**. While you can see cache misses or % busy time, you cannot identify which specific application function is responsible for the delay.
|
|
%%%
|
|
|
|
How does the OS distinguish between a **Process** and a **Thread**?
|
|
|
|
---
|
|
|
|
🧵
|
|
|
|
- **Thread**: A single thread of control/execution.
|
|
- **Process**: A collection of threads and an associated **address space**.
|
|
%%%
|
|
|
|
## How does the **OS Scheduler** view the population of threads?
|
|
|
|
---
|
|
|
|
🎟️ It sees them as **tokens** moving through various states (e.g., Ready, Running, Waiting, Dead) and managed within queues.
|
|
%%%
|
|
What is the difference between **System Threads** and **User Threads**?
|
|
|
|
---
|
|
|
|
👥
|
|
|
|
- **User Threads**: Run the actual application and middleware logic.
|
|
- **System Threads**: Run OS services and the scheduler itself (there may be hundreds of these).
|
|
%%%
|
|
In UNIX accounting, what two categories is **Process CPU time** divided into?
|
|
|
|
---
|
|
|
|
⏰
|
|
|
|
1. **System Time**: Time spent executing OS/kernel-level calls.
|
|
2. **User Time**: Time spent executing the application's own code.
|
|
%%%
|
|
What types of operations are measured at the **OS Service Level**?
|
|
|
|
---
|
|
|
|
💾 Disk I/O, memory usage, and network operations (packets sent/received).
|
|
%%%
|
|
What is the "granularity" of **Network measurements** compared to **Disk/Memory**?
|
|
|
|
---
|
|
|
|
🔍
|
|
|
|
- **Disk/Memory**: Can often be tracked with granularity down to the specific **thread**.
|
|
- **Network**: Usually measured for the **system as a whole**.
|
|
%%%
|
|
What "exotic" tool can be used to record specific event times by thread at the OS level?
|
|
|
|
---
|
|
|
|
🕵️ **OS Tracing Tools**.
|
|
%%%
|
|
|
|
## How does a **Sampling Profiler** determine where a program is spending its time?
|
|
|
|
---
|
|
|
|
📉 It **periodically samples the instruction counter** and uses a symbol table to map those instructions to specific methods or procedures. The percentage of total counts per method represents the percentage of time spent there.
|
|
%%%
|
|
What is the purpose of **Stack Sampling** in profiling?
|
|
|
|
---
|
|
|
|
🌳 It captures the **context of the call** by recording the sequence of calling methods (the call tree), allowing the profiler to break down time spent in higher-level methods into their constituent lower-level calls.
|
|
%%%
|
|
|
|
## What are the **three major steps** in the Measurement Technique process?
|
|
|
|
---
|
|
|
|
1. **Specify**: Decide exactly what you want to measure.
|
|
2. **Instrument/Gather**: Attach monitors and run a benchmark to collect data.
|
|
3. **Analyze/Transform**: Process the raw data into meaningful insights.
|
|
%%%
|
|
What is the primary objective when choosing a **Measurement Tool**?
|
|
|
|
---
|
|
|
|
🎯 To measure the behavior of the system **without perturbing it** (avoiding the "observer effect" where the tool itself slows down the system enough to change the results).
|
|
%%%
|
|
Compare the two main **Monitoring Modes**: Event Trace vs. Sampling.
|
|
|
|
---
|
|
|
|
🔄
|
|
|
|
- **Event Trace**: Collects info on specific **state changes** via probes; has low overhead (~5%) but shouldn't be used in sensitive areas like interrupt handlers.
|
|
- **Sampling**: **Polls the system state** periodically; accuracy is proportional to overhead (higher accuracy requires more frequent polling).
|
|
%%%
|
|
What are the pros and cons of **Hardware Monitors** (e.g., oscilloscopes or logic analyzers)?
|
|
|
|
---
|
|
|
|
🔌
|
|
|
|
- **(+)**: External to the system, so they **don't perturb** results; very portable.
|
|
- **(-)**: Hard to use and difficult to map a raw electrical event back to a specific software cause.
|
|
%%%
|
|
What is the difference between the two types of **Software Monitors**?
|
|
|
|
---
|
|
|
|
🖥️
|
|
|
|
1. **Accounting Systems** (e.g., `sar`): Used for billing/resource usage; may not collect enough specific data for debugging.
|
|
2. **Program Analyzers** (e.g., Valgrind, JProfiler): Provide deep code insights but can **significantly interfere** with system performance.
|
|
%%%
|
|
How does a **Hybrid Monitor** function?
|
|
|
|
---
|
|
|
|
🤝 It combines both worlds: **event signals** are embedded in the software, but they are processed by an **external hardware device** to minimize system perturbation.
|