System Resources and Their Limitations Across Device Types

The resources a system has. Every computing device is a bundle of resources that can run out: primary memory (RAM, where running programs and their data live); secondary storage (disk or flash, persistent but slow); processor speed and number of cores; cache, the small fast memory that hides RAM latency; network bandwidth; screen resolution; graphics and sound processors, specialised chips that take work off the main processor; and, for anything not plugged into the wall, battery. The exam expects you to name these and, more importantly, to say what happens when each one runs out.

Different devices are short of different things. A mainframe or large server has huge memory, storage and processing, runs thousands of users at once, and has almost no screen because nobody sits at it; its constraint is heat, power and the cost of downtime. A desktop PC is balanced, with a large screen and mains power; its limits show as slowness when RAM fills. A tablet or phone has a capable processor but a small screen, limited RAM, limited storage, wireless bandwidth that varies with signal, and above all a battery, so every piece of software must economise on power and the operating system aggressively suspends background apps. A digital camera has little general processing and memory but a dedicated image processor and fast storage; it does one job. An IoT sensor may have a few kilobytes of memory, no screen, a slow radio, and a battery that must last years, so it wakes briefly, sends a number and sleeps. The same task — say, viewing a document — is implemented differently on each: the desktop loads the whole file into memory, the phone streams pages as needed, the sensor could not do it at all.

Bottlenecks. Performance is set by whichever resource runs out first. A server at 96% processor use with idle disks needs a faster processor; one at 30% processor with a saturated disk and a high page-fault rate needs more RAM, and a faster processor would change nothing. Diagnosing the bottleneck before spending money is the skill examiners test: they give measurements and ask which upgrade helps. The rule is that upgrading any resource other than the bottleneck produces no improvement, and after the bottleneck is removed a different resource becomes the new one.

Consequences for software. Software written without regard to limits fails in predictable ways: an app that keeps a large data set in memory crashes on a phone; a page that assumes broadband is unusable on a slow link; a program that polls a sensor constantly drains the battery. Good design measures the target device's limits and works within them — loading lazily, compressing, caching, batching network requests and letting the device sleep.