Visual first
Follow requests, workers, queues, state changes, and timing through diagrams designed for learning.
Visualize. Experiment. Understand.
Interactive IT concepts,
organized in one place.
Choose a category and open a simulation to explore the core behavior step by step, then adjust the available settings to see how different conditions affect the system and compare the results in more detail.
Systems & OS
Visual models for understanding how workloads move through threads, queues, I/O, and system resources.
Overview
Learn the behavior, then test the variables
IT concepts often become difficult when they are explained only with definitions. A sentence can describe a thread waiting, a queue growing, or an event arriving, but it does not show how those events overlap over time. These simulations turn that invisible behavior into timelines, state changes, queues, and side-by-side comparisons.
Each page is designed to work in two stages. The first stage presents a small conceptual model that can be understood without changing any settings. The second stage exposes the workload controls so you can test how request count, timing, concurrency, and available resources affect the result.
Experiment second
Adjust the available settings and compare how the same workload behaves under different models.
Compare the same workload
Alternative execution models receive matching inputs, making it easier to isolate the behavior that actually changed.
Inspect the result
Use timelines, completion times, queue activity, and explanatory notes to connect the animation with measurable outcomes.
Learning model: The simulations simplify real systems so the important relationship remains visible. They are not substitutes for production benchmarks, profiling tools, or operating-system traces.
How to use
Choose a simulation and follow the model
1. Choose a category
Start with the systems or computer science area you want to explore. The short category description explains the scope before you open a tool.
2. Open a simulator
Select a card to move to the complete learning page. Begin with the default example instead of adjusting every control immediately.
3. Follow the visual model
Read the comparison from left to right and use the legend to identify active work, waiting, queued work, and completion handling.
4. Test one variable
Change one setting at a time. Keeping the other values fixed makes the cause of a different result much easier to recognize.
5. Review the timeline
Look for idle gaps, overlapping work, queue buildup, and the point where each model finishes rather than focusing on one number alone.
6. Repeat with a new workload
Try a contrasting preset or an extreme value, make a prediction, and then compare that prediction with the simulation result.
A useful way to experiment
Start from the defaults and write down what you expect to happen. For example, predict whether adding workers will reduce queue time, whether a longer operation will increase overlap, or whether a CPU-heavy workload will narrow the difference between two execution models. Run the simulation only after making the prediction. This turns the page from a demonstration into an active learning exercise.
Guide
Interactive IT simulation categories
Systems and operating-system simulations
Systems software coordinates work that competes for limited resources. Threads need CPU time, requests wait for devices, tasks enter queues, and completion events make more work runnable. A simulator can place these transitions on one shared time axis so the relationship between concurrency and elapsed time becomes visible.
The current Blocking vs Non-Blocking I/O page focuses on what happens to worker threads while I/O is pending. It compares the same requests under two execution models, shows when work starts and completes, and lets you vary both workload timing and worker counts.
How to read a simulation correctly
Begin with the legend and identify what each color represents. Next, follow a single request from arrival to completion. Only then compare multiple rows to see which operations overlap and which wait for a resource. This order prevents a busy timeline from looking like an unexplained monitoring dashboard.
Completion time is useful, but it is not the only result. Queue delay shows whether capacity is keeping up with arrivals. Worker utilization shows whether concurrency is helping or merely adding idle resources. Throughput describes completed work per unit of time, while response time describes the experience of an individual request.
What conceptual models leave out
Real applications include scheduler overhead, context switches, caches, interrupts, runtime behavior, kernel queues, device variability, network latency, backpressure, and implementation-specific costs. A learning simulation intentionally leaves many of these details out so one mechanism can be examined clearly.
Use the results to understand direction and relationships, not to predict the exact performance of a server or operating system. Production decisions should be supported by measurements from the real application, environment, and workload.
How this directory can grow
Future systems pages can cover CPU scheduling, process states, virtual memory, page replacement, cache behavior, file systems, deadlocks, synchronization, and storage queues. Networking simulations can visualize packet flow, congestion, routing, DNS, TCP state, and retry behavior.
Database, distributed-system, security, and algorithm categories can be added without changing the directory pattern. Each new page will appear as another card under its category, while this hub remains the starting point for the complete collection.
FAQ
IT simulations FAQ
Are these real system benchmarks?
No. The simulations are conceptual learning models intended to make technical behavior easier to understand. Exact production performance requires measurement in the real environment.
Do I need prior systems knowledge?
No. Each simulator starts with a small visual explanation before presenting detailed settings, terminology, timelines, and results.
Why do both models receive the same inputs?
Using the same workload makes the comparison fairer and helps isolate the effect of the execution model or resource setting being studied.
What should I change first?
Change one value at a time and compare the new result with the default. This makes cause and effect easier to identify.
Can I use the result for capacity planning?
Use it to build intuition, not as a capacity estimate. Real planning should use application metrics, profiling, load tests, and production-like infrastructure.
Will more simulations be added?
Yes. New pages and categories will be added to this directory as the IT simulation collection expands.