Exercises — I - O management — polling, interrupt-driven, DMA

KYA: Woh status register read karta hai. KYU: Status = "device condition" (busy / ready / error). Data register mein bytes hote hain; command register mein "START READ" jaise orders hote hain. Sirf status register "ready?" ka jawab deta hai. Kya kuch badalta hai? Nahi — status read karna ek pure query hai; yeh device ko koi command nahi deta. (Contrast: command register mein likhna actually action cause karta hai.)

• (a) → DMA (block-at-a-time, completion pe ek interrupt).
• (b) → Polling (status register pe busy-wait).
• (c) → Interrupt-driven (device ek interrupt line raise karta hai). YE KYU SWAP NAHI HAIN: distinguishing question yeh hai ki kaun status dekhta hai aur kaun bytes move karta hai. Polling: CPU dekhta bhi hai + move bhi karta hai. Interrupt: device signal karta hai, CPU move karta hai. DMA: controller dekhta bhi hai + move bhi karta hai.

Polling < Interrupt-driven < DMA. KYU: Polling CPU ko wait bhi karwata hai aur copy bhi → sabse zyada CPU work. Interrupts waiting hata dete hain lekin per-byte copy rakhte hain. DMA dono — waiting aur copying — hata deta hai → sabse kam CPU work. Har step "CPU se aur zyada kaam remove karta hai."

KYA: Wasted polls $\approx \frac{T_{dev}}{t_{poll}}$. YE FORMULA KYU: CPU poll loop back-to-back run karta hai; $T_{dev}$ time mein woh $T_{dev}/t_{poll}$ iterations fit karta hai, aur aakhri wale se pehle har ek ne "not ready" paya → wasted. Plug in (same units mein convert karo): $T_{dev}=8\text{ms}=8\times 10^6\text{ns}$, $t_{poll}=100\text{ns}$. $\frac{8\times 10^6}{100}=80,000\text{ wasted polls.}$ Ek ready event ke liye yeh 80,000 iterations pure waste hain.

KYA: overhead $=N\cdot t_{int}$. KYU: interrupt-driven I/O har data unit pe ek baar $t_{int}$ pay karta hai, aur $N$ units hain. $512\times 40=20,480\text{ units.}$ Note karo yeh $N$ ke saath linearly badhta hai — yahi woh weakness hai jo DMA fix karta hai.

KYA: DMA exactly 1 interrupt raise karta hai (completion pe, jab count = 0 ho jaye). KYU: DMA controller har byte autonomously handle karta hai; CPU ko sirf "block done" bataya jaata hai. Overhead $=1\times t_{int}=1\times 40=40$ units (plus ek choti si fixed setup). L2·Q2 ke 20,480 units se compare karo: DMA ne interrupt overhead $512$ ke factor se cut kar diya.

KYA: crossover wahan hai jahan wait na karne se CPU time ki bachat interrupt overhead se zyada ho jaaye: $T_{dev}>t_{int}$. KYU: agar device almost instantly ready ho ($T_{dev}$ tiny), toh wait ek interrupt ki fixed cost se sasta hai → poll karo. Jaise hi $T_{dev}$, $t_{int}$ se exceed kare, freed CPU time overhead se zyada ho jaata hai → interrupt. Crossover: $T_{dev}=t_{int}=2\mu s$. Toh $T_{dev}>2\mu s$ ke liye → interrupt-driven wins; $T_{dev}<2\mu s$ (almost-ready device) ke liye → polling wins. Figure mein blue (polling) aur orange (interrupt) lines ka crossing dekho.

KYA: interrupts per second $=R=10^6$. ISRs mein time per second $=R\cdot t_{int}$. $10^6\times 2\times 10^{-6}\text{s}=2.0\text{ seconds of work per }1\text{ second.}$ YE POINT KYU HAI: CPU ko sirf interrupts service karne ke liye 200% of its time chahiye hoga — physically impossible. ISR overhead dominate kar jaata hai. Conclusion: high data rates par, per-byte interrupts collapse ho jaate hain. Yahi exactly DMA kyun exist karta hai — poora block move karo, ek baar interrupt karo.

Yeh claim galat hai. DMA aur CPU memory bus share karte hain. Jab bhi DMA controller ek word move karne ke liye bus grab karta hai, CPU us cycle mein memory use nahi kar sakta aur stall ho sakta hai — ise cycle stealing kehte hain. Jo SACH HAI: DMA CPU ko byte-copying loop se hata deta hai, toh uska load $O(N)$ se $O(1)$ ho jaata hai. Yeh ek badi bachat hai — lekin contention-free nahi, kyunki dono masters ek bus ke liye compete karte hain (bus arbitration se resolve hota hai). Sachchi baat: "CPU copying se free hai, lekin occasional bus stalls se nahi."

Polling: $N$ moves $+$ wasted polls $=4096+10,000=14,096$ units. (CPU poore time stuck rehta hai.) Interrupt-driven: $N$ ISRs $=4096\times 50=204,800$ units of overhead. (Per-byte interrupts bade $N$ par hurt karte hain.) DMA: $1$ setup $+1$ ISR $\approx 50+\epsilon \approx \sim 100$ units, CPU meanwhile free. Rank (best = least CPU work): DMA $⋘$ Polling $<$ Interrupt-driven. YE SURPRISE KYU? Bade blocks ke liye, per-byte interrupts yahan actually worst hain kyunki $t_{int}$ (50) $\gg$ per-byte poll savings — DMA ka block-at-a-time model decisive win hai. Yeh parent ka "forecast then verify" confirm hua. ✅

(a) Keyboard → Interrupt-driven. Rare events (bahut bada $T_{dev}$) ⇒ polling millions of cycles waste karta hai; sirf 1 byte ⇒ DMA setup worth it nahi. Interrupt = "rare ding pe mujhe jagao." (b) NIC → DMA. Huge blocks + high rate ⇒ per-byte interrupts collapse ho jaate hain (L3·Q2); ek completion interrupt ke saath block transfer hi ek sane choice hai. (c) Always-ready sensor → Polling. $T_{dev}$ kuch ns hai $<t_{int}$ ⇒ interrupt overhead poll cost se zyada ho jaayega. Seedha read kar lo. Unifying rule: technique ko device ki rate (kitni baar) aur block size (kitna zyada) se match karo. Koi ek method sab jagah nahi jeetta.

(a) Poll vs interrupt. Polling CPU ko poori wait $\approx T_{dev}$ ke liye tie up karta hai; interrupts ek fixed $t_{int}$ cost karte hain aur CPU ko free karte hain. Poll tabhi karo jab expected wait interrupt overhead se chhoti ho: $\text{poll if }{T}_{dev}<t_{int}=5\mu s,\text{else interrupt.}$ ($T_{dev}=5\mu s$ par dono tie karte hain; usse neeche, ~$5\mu s/250\text{ns}=20$ polls spin karna ek interrupt se sasta hai.)

(b) DMA switch karo jab transfer ek block ho ($N$ bada) aur per-byte interrupt cost $N\cdot t_{int}$ CPU ke time budget se exceed kare — matlab jab bhi $N$ ek fast device par kuch bytes se zyada ho. DMA cost ko $O(N)$ ki jagah $O(1)$ bana deta hai.

(c) Pseudocode:

handle_io(request):
    if request.is_block and request.N > SMALL_THRESHOLD:
        setup_DMA(src, dst, N)     # one completion interrupt
    elif expected_Tdev < t_int:     # 5 microseconds
        poll_status_until_ready()   # busy-wait, cheaper here
    else:
        issue_command(); return     # interrupt-driven; ISR finishes it

Defence: har branch wahan choose ki gayi hai jahan uska cost model provably lowest hai — near-instant devices ke liye polling, slow single-unit events ke liye interrupts, large blocks ke liye DMA. Yeh parent ka "P < I < D offloading" ek actual, defensible policy mein convert hua. Interrupts minimize karna kyun zaroori hai, iske liye CPU utilization and throughput aur Context switching dekho (har interrupt ek context save/restore cost karta hai).

KYA: solve karo $\underset{\text{interrupt}}{\underbrace{50N}}>\underset{\text{DMA total}}{\underbrace{S+50}}$. KYU: crossover dhundo jahan DMA ki constant cost interrupts ki linear cost se neeche aa jaaye. $50N>60+50=110\Rightarrow N>\frac{110}{50}=\mathrm{2.2.}$ Toh $N\ge 3$ bytes ke liye, DMA CPU work mein already jeet jaata hai. Interpretation: chote blocks ke liye bhi break-even chota hai — DMA ka $O(1)$ behaviour almost immediately dominate karta hai jaise hi transfer do-teen bytes se zyada ho.

Kya tumne har numeric answer sahi paya? ::: L2: 80000; 20480; 40. L3: crossover 2 μs; 2.0 s (200%). L4: 14096 / 204800 / ~100. L5: poll if under 5 μs; DMA wins for N ≥ 3; break-even N = 2.2. Kya tumne har choice ko rate AUR block size dono se justify kiya? ::: Agar nahi, toh L4·Q2 dobara padho. Kya tum driver policy memory se likh sakte ho? ::: Agar nahi, toh L5·Q1 pseudocode dobara padho.