Hey Chris, I have no idea why you said that the time-quantum expires after the process used up 5 microseconds to perform some computation on the CPU. The timequantum should never have even expired in the first place (since it is always a 100-microsecond cycle - every 100 microseconds on the CPU is when the timequantum keeps expiring and renewing). I tested the other student's simple command in the sample solution, and my time-quantum had never expired, which is logical and how it should correctly function. I have no idea why the other student's time-quantum had expired. Here is my verbose output for the exact same command from the other student: @00*0*0*0 REBOOTING at Thu Sep 14 09:07:36, with timequantum=100 @00*0*0*0 spawn 'shortsleep', pid0.NEW->READY, transition takes 0usecs @00*0*0*0 pid0.READY->RUNNING, transition takes 5usecs (1..5) @00*0*0*1 + OS @00*0*0*2 + OS @00*0*0*3 + OS @00*0*0*4 + OS @00*0*0*5 + OS @00*0*0*5 pid0 now on CPU, gets new timequantum shortsleep(onCPU=0) @00*0*0*6 c shortsleep(onCPU=1) @00*0*0*7 c shortsleep(onCPU=2) @00*0*0*8 c shortsleep(onCPU=3) @00*0*0*9 c shortsleep(onCPU=4) @00*0*0*0 c shortsleep(onCPU=5) @00*0*0*1 exit, pid0.RUNNING->EXIT, transition takes 0usecs shortsleep(onCPU=5) @00*0*0*1 nprocesses=0, SHUTDOWN @00*0*0*1 11usecs total system time, 5usecs onCPU by all processes, 5/11 -> 45% measurements 11 45 As you can see, there is no occurrence of any time-quantum expiration