Julian Gonzalez

Overview

Welcome to the I/O Communication Gauntlet! You'll experience three distinct forms of I/O communication by physically simulating the challenges that operating systems face when moving data between devices.

3 Device Types:

Block Devices - Maximize throughput over a damaged transmission medium
Character Devices - Maximize responsiveness with a handcrafted serial connection
Network Devices - Maximize data integrity over an unreliable network

You'll feel the frustrations of damaged media, buffer management, packet loss, and the engineering trade-offs that make I/O so challenging!

Learning Objectives

By the end of this activity, you will be able to:

Understand the fundamental differences between block, character, and network devices
Experience the trade-offs between throughput, latency, and reliability
Feel the impact of transmission errors, buffering, and packet reordering
Connect physical intuition to software solutions like error correction, flow control, and reliable delivery

Materials Needed

Below are the materials needed for each activity, plus general supplies for running them all:

General Supplies:

Timer (20 minutes per stage)
Trash cans for failed attempts
Scoreboard for tracking progress
Bell for signaling stage transitions

Stage Overview

This activity has 3 stages (~20 minutes each). To accommodate larger classes, split into three groups and run stages concurrently, rotating between activities:

Group	Stage 1	Stage 2	Stage 3
Group 1	Block Devices	Character Devices	Network Devices
Group 2	Character Devices	Network Devices	Block Devices
Group 3	Network Devices	Block Devices	Character Devices

Set a timer for 20 minutes per stage. When the timer runs out, tally scores and rotate!

Scoring: Each group tracks their own score. At the end, compare performance across different I/O types. Did some activities naturally produce higher scores? Why might that be?

Be the first to set the record!

Complete this activity and add your class stats to the leaderboard.

Stage 1: "Hard Drive"

The Scenario

You're simulating block device communication over a damaged transmission medium—like reading/writing to a hard disk with bad sectors or a scratched optical disc.

Materials Needed

RC vehicle(s)
Origami instructions (your "data blocks")
Paper
Race track with obstacles
Start and finish line markers
Discard pile for damaged data

Setup

Create a race track with clear start and finish lines
Add obstacles to simulate "bad sectors" (books, cones, barriers)
Set up a construction zone at the start line
Place a collection area at the finish line
Designate a discard pile for damaged/lost data

How It Works

Your team is a disk controller! The RC vehicle is your read/write head, and origami represents data blocks.

Construct Data: Build origami figures at the start line (these are your "data blocks")
Load Data: Place completed origami on the RC vehicle
Transport: Drive the RC vehicle through the obstacle course to the finish line
Verify: The proctor checks if data arrived intact
Score: Intact data = points! Damaged/lost data = discard pile

Rules

You MUST:

Construct origami yourself (no pre-made data!)
Transport data via the RC vehicle only
Navigate through/around all obstacles
Accept the proctor's ruling on data integrity

You CANNOT:

Carry data by hand across the track
Remove or move obstacles
Interfere with other teams' vehicles

You CAN:

Have multiple people constructing data simultaneously
Strategize about vehicle loading and navigation
Restart a delivery attempt if data falls off before the finish
Talk, coordinate, and have fun!

Think About It: This simulates seek time (navigation), data integrity (keeping origami intact), and throughput (how much data reaches the destination). What happens when the "medium" (track) is more damaged?

Tweaks & Variations

Instructors can modify difficulty:

Multiple Vehicles: Add collision management (like multiple disk heads)
Complex Data: Different origami designs = different block sizes
Worse Conditions: More obstacles = more bad sectors
Time Pressure: Shorter deadlines = faster seek requirements

Stage 2: Digi-Bridge

The Scenario

You're simulating character device communication—like a serial port or UART that transmits data as a continuous stream of bytes through a physical channel.

Materials Needed

Tape (lots of it!)
Paper and cardboard
Balls of varying types (plastic ball-pit balls, golf balls, ping-pong balls)
Collection bins (these are your "buffers")
Materials for marking "No Man's Land" (tape, rope, cones)

Setup

Mark a "No Man's Land" zone (6-10 feet wide)
Set up the sending station on one side
Place collection bins (buffers) on the receiving side
Provide construction materials to the team
Scatter different ball types at the sending station

How It Works

Your team is building a serial connection! Construct a structure that can transport a continuous stream of data across No Man's Land.

Build: Use tape and paper to construct a channel across No Man's Land
Stabilize: Your structure may have supports within the zone, but you CANNOT be inside during transmission
Transmit: Roll balls through your structure from the sending side
Buffer: Balls should land in collection bins on the receiving side
Score: Count successfully buffered balls at the end!

Rules

You MUST:

Build a self-supporting structure (no holding it during transmission!)
Stay outside No Man's Land during data transfer
Use only provided materials
Direct balls into the buffer bins

You CANNOT:

Enter No Man's Land while transmitting
Use external supports (walls, furniture) outside your materials
Catch balls by hand on the receiving end
Throw balls—they must roll/slide through your channel

You CAN:

Rebuild or modify your structure between transmission attempts
Retrieve fallen balls for re-transmission after a transmission period ends
Have designated "senders" and "receivers"
Use different ball types strategically
Talk, coordinate, and have fun!

Think About It: This simulates bandwidth (channel width), buffering (collection bins), and flow control (can your receiver keep up?). What happens when you send too many balls too fast?

Tweaks & Variations

Instructors can modify difficulty:

Mixed Data Types: Different balls = different character types (some roll better!)
More Materials: Cardboard, classroom furniture = more engineering options
Buffer Limits: Smaller bins = buffer overflow risk
Longer Distance: Wider No Man's Land = more signal degradation

Stage 3: Out of Order

The Scenario

You're simulating network device communication—like Ethernet or Wi-Fi where packets travel unreliably and may arrive out of order or not at all.

Materials Needed

Small bags (these are your "packets")
Puzzle pieces (your actual data)
Cornhole boards and bags
Assembly area for puzzle reconstruction

Setup

Set up cornhole boards at opposite ends of the play area
Establish a throw line for senders
Prepare puzzle pieces and bags on the sending side
Create an assembly area on the receiving side
Have multiple puzzles available for bonus points

How It Works

Your team is implementing TCP/IP! Bags are packets, puzzle pieces are data, and cornhole represents the unreliable network.

Packetize: Load puzzle pieces into bags (deciding how much data per packet)
Transmit: Throw bags toward the cornhole board (this is your unreliable network!)
Receive: Successfully landed bags go to the receiving team
Reassemble: Receivers must reconstruct the puzzle from received packets
Score: Points for puzzle completion percentage and/or completed puzzles!

Rules

You MUST:

Throw from behind the designated line
Accept packet loss (missed throws = lost packets)
Reassemble puzzles only from successfully received packets

You CANNOT:

Walk packets across (no out-of-band delivery!)
Open bags before they land successfully
Interfere with other teams' transmissions

You CAN:

Retry failed throws with the same packet
Decide your own packet sizes (more pieces per bag = riskier)
Request "retransmission" of needed pieces (communication allowed!)
Have designated throwers, receivers, and assemblers
Talk, coordinate, and have fun!

Think About It: This simulates packet loss (missed throws), packet size trade-offs (more data = heavier = harder to throw), and reassembly (receiver must reconstruct order). Why might smaller packets be safer?

Tweaks & Variations

Instructors can modify difficulty:

Heavier Pieces: Wooden puzzle pieces = heavier packets = more drops
Multiple Puzzles: Jumbled sets = need for packet identification
Variable Distance: Longer throws = higher latency, more loss
Smaller Bags: Less capacity = more packets needed = more overhead

Overall Rules

These rules apply across ALL stages:

Prohibited:

Interfering with other groups' activities
Using materials designated for other groups
Contributing or soliciting advice across groups
Damaging materials needed for activity integrity

Permitted:

Asking instructors for clarification
Self-organizing into roles or sub-teams
Using technology for calculations or strategy
Getting LOUD and having FUN!

Discussion Questions

After completing all stages, gather everyone for discussion. Connect your physical experiences to real I/O challenges!

Block Device Reflection

Q1: What was the most frustrating part of the Block Device activity? Did you lose more data to construction failures or transportation failures? How does this relate to the difference between manufacturing defects vs bad sectors on a real disk?

Q2: Did you develop any strategies to improve throughput? Did you try sending multiple pieces at once, or focus on one reliable delivery at a time? How does this relate to disk scheduling algorithms that try to minimize seek time?

Q3: If your origami got damaged, you had to discard it and start over. Real disks use error-correcting codes (ECC) to recover from minor damage. What would the equivalent look like in this activity? How much "extra" origami would you need to send to tolerate some damage?

Q4: The obstacles on your track simulated bad sectors. Real operating systems maintain bad block lists and remap around damaged areas. Did your team develop any "maps" of the safest routes? Would that have helped?

Character Device Reflection

Q5: What was the hardest part of building your serial channel? Did balls ever pile up faster than they could be processed? This is the buffer overflow problem—how did you handle it (or fail to handle it)?

Q6: Different ball types (heavy, light, bouncy) behaved differently in your channel. Serial devices deal with varying data rates and flow control . Did you wish you could tell the sender to "slow down"? That's exactly what hardware flow control (RTS/CTS) does!

Q7: Your structure had to be self-supporting—you couldn't hold it during transmission. Real serial cables are passive too! But what if you could have active repeaters along the way? How would that change your design? This is how RS-485 networks work over long distances.

Q8: Did any balls fall out of your channel? This is similar to bit errors in serial communication. Real protocols use parity bits and checksums to detect this. What would a "checksum" look like for your ball stream?

Network Device Reflection

Q9: How did you decide how many puzzle pieces to put in each bag? More pieces = fewer throws needed, but heavier bags are harder to land. This is the packet size trade-off (MTU). What was your optimal size?

Q10: Did packets ever arrive in a different order than you sent them? Real networks deal with packet reordering constantly. How did your receivers know how to reassemble the puzzle? Would sequence numbers have helped?

Q11: When a bag missed, did you retry immediately or move on and try again later? This is the difference between stop-and-wait vs sliding window protocols. Which strategy worked better for your team?

Q12: The cornhole board is your unreliable network—some packets get through, some don't. Real networks use acknowledgments (ACKs) so senders know what arrived. Did your team develop any signaling? How did receivers communicate what they still needed?

Cross-Cutting Questions

Q13: Rank the three I/O types by how frustrating they felt. Now rank them by which one your team scored highest on. Are these rankings the same? What does this tell you about the relationship between complexity and performance ?

Q14: All three activities involved moving data from point A to point B, but they felt very different. In your own words, what's the fundamental difference between block, character, and network I/O? Use your physical experience to explain it.

Q15: Real operating systems often use DMA (Direct Memory Access) to handle I/O without CPU involvement. In each activity, what would "DMA" look like? What if you could set up a process and walk away?

Q16: If you could redesign any of these activities to make your team more efficient, what would you change? Now consider: is your improvement similar to any real I/O optimization technique (caching, prefetching, batching, pipelining)?

Final Thoughts

Q17: What surprised you most about this activity? Did any of the physical challenges map to OS concepts you'd heard about but didn't fully understand until now?

Q18: Operating systems spend enormous effort abstracting away I/O complexity so programmers can just call read() and write() . After this activity, do you have more appreciation for what happens underneath those simple system calls?

Key Takeaways

Block Devices (Hard Disks, SSDs, Optical Media):

✅ High throughput for large, sequential transfers
✅ Data persists after power loss
❌ Seek time is a major bottleneck
❌ Physical media can be damaged
🔧 OS Solution: Disk scheduling, bad block management, caching

Character Devices (Serial Ports, Keyboards, Sensors):

✅ Simple, continuous byte stream
✅ Low latency for small amounts of data
❌ No inherent structure—must parse manually
❌ Buffer overflow if receiver can't keep up
🔧 OS Solution: Buffering, flow control, line disciplines

Network Devices (Ethernet, Wi-Fi, Internet):

✅ Can communicate over any distance
✅ Supports many-to-many communication
❌ Unreliable—packets can be lost, duplicated, or reordered
❌ Requires complex protocols for reliability
🔧 OS Solution: Protocol stacks (TCP/IP), checksums, retransmission

The Universal Challenge:

All I/O involves balancing throughput, latency, and reliability. You can optimize for one or two, but rarely all three. The operating system's job is to hide this complexity and present simple abstractions to applications!

Grading

Completion-based - Engage with all three stages, participate in discussion, and reflect on the connections to OS concepts. Full participation = full points!

Alternate Assignment (For Absences)

Couldn't make it to class? Complete this alternate assignment for credit.

Watch These Videos

Watch these videos about I/O devices and their interfaces:

How do Hard Drives Work? - Covers block device mechanics
Serial Communication Explained - Covers character devices and UART
How Does the Internet Work? - Covers network packet switching

Answer These Questions

Submit a PDF with your answers to Brightspace:

Q1: Based on the hard drive video, explain why sequential reads are much faster than random reads on a traditional spinning disk. How does the physical mechanism of the device create this limitation?

Q2: The serial communication video discusses baud rate and bit timing . If two devices have mismatched baud rates, what happens to the data? Relate this to the "different ball types" scenario in the Character Device activity.

Q3: The internet video explains packet switching and routing . Why do packets from the same source sometimes arrive out of order? What layer of the network stack is responsible for fixing this?

Q4: Compare and contrast how the three I/O device types handle data loss . What mechanisms exist at the hardware and OS level to detect and recover from lost or corrupted data?

Q5: Imagine you're designing an embedded system for a car. Which I/O type would you use for: (a) reading GPS coordinates, (b) storing maps, (c) communicating with other vehicles? Justify each choice.

Q6: The class activity simulated physical challenges with each I/O type. For each device type, describe one challenge that exists in the digital/electronic domain that we couldn't easily simulate physically.

Submission: Upload your PDF to the relevant Brightspace assignment.

Loading content...

Course Planner

Spring Break!

AC 2: Saved by The Schedule

HW 3: Hot Pie-tato

AC 3: Ring Around the I/Osie

Learning Objectives

Overview

Learning Objectives

Materials Needed

Stage Overview

Stage 1: "Hard Drive"

The Scenario

Materials Needed

Setup

How It Works

Rules

Tweaks & Variations

Stage 2: Digi-Bridge

The Scenario

Materials Needed

Setup

How It Works

Rules

Tweaks & Variations

Stage 3: Out of Order

The Scenario

Materials Needed

Setup

How It Works

Rules

Tweaks & Variations

Overall Rules

Discussion Questions

Block Device Reflection

Character Device Reflection

Network Device Reflection

Cross-Cutting Questions

Final Thoughts

Key Takeaways

Grading

Alternate Assignment (For Absences)

Watch These Videos

Answer These Questions

All Activitys

Overview

Learning Objectives

Materials Needed

Stage Overview

Stage 1: "Hard Drive"

The Scenario

Materials Needed

Setup

How It Works

Rules

Tweaks & Variations

Stage 2: Digi-Bridge

The Scenario

Materials Needed

Setup

How It Works

Rules

Tweaks & Variations

Stage 3: Out of Order

The Scenario

Materials Needed

Setup

How It Works

Rules

Tweaks & Variations

Overall Rules

Discussion Questions

Block Device Reflection

Character Device Reflection

Network Device Reflection

Cross-Cutting Questions

Final Thoughts

Key Takeaways

Grading

Alternate Assignment (For Absences)

Watch These Videos