A Worked MRTPN Example (or: The Pholly of Physicists…) (June 2005)

The Problem Brand new sensor measures inspirons. But, the PC-card only has one register! If we miss 3 readings in a row the results will be useless!  Samples are timed, so double-reading is ok.

The Solution Model the system with ‘outer bounds’ values. Check for triple miss. Three components: –sensor –single register –software monitor sensor monitor register write read

Sensor Takes a few moments to warm up if it’s cold. Takes a few moments to take a measurement. Then transfers the reading to the PC card off ready analysing activate writesample [1,3] [2,4][0,1]

Register Very simple, powers up quickly. Very rapid read & writes. off ready activate readwrite 1 [0,1]

Monitor Software to accumulate the results in a file. Reading and writing take a few moments for the O/S calls to execute. off ready buffering activate storeread [2,4] [1,2] [2,3]

Modular Algorithm Initial state = {(s0 γ, 0)} Aγ For each state M: –find the locally reachable states, M’ lreach(M, δ ) = { (M’, λ ) } <= (future state, leftover delay) –find global events that can then be fired, tf (M →* M’) Λ (M’ [ λ, tf > M’’) => M’’ is a new state! –continue until time is exhausted for M lather, rinse, repeat!

Let’s go… Initial state: {(s0,0),(r0,0),(m0,0)} Need to calculate the lreach sets for those… For convenience: –local pairs (s,d) –global pairs [s,d] –omega pair [[s,d]] (s0,0), (r0,0), (m0,0) ???

lreach(s0) 0 => (s0,0), (s1,0), (s2,0), (s3,0) 1 => (s1,1), (s2,1), (s3,1), (s4,0), (s5,0), (s6,0) 2 => (s2,2), (s3,2), (s4,1), (s5,1), (s6,1), (s4,0), (s5,0), (s6,0) 3 => (s3,3), [s4,2], (s5,2), (s6,2), (s4,1), (s5,1), (s6,1), (s4,0), (s5,0), (s4,0) 4=> [[s4,3]], [s5,3], (s6,3), [s4,2], (s5,2), (s6,2), (s4,1), (s5,1), (s6,1) s1 s0 s2s3 0,act sample ,write3,write4,write5,write 3,write4,write s4 s5 s6

lreach(s0) – cont’d 4=> [[s4,3]], [s5,3], (s6,3), [s4,2], (s5,2), (s6,2), (s4,1), (s5,1), (s6,1) 5 => [[s4,3]], [[s5,4]], [s6,4],[s5,3], (s6,3), [s4,2], (s5,2), (s6,2) 6 => [[s4,3]], [[s5,4]], [[s6,5]], [s6,4], [s5,3], (s6,3) 7 => [[s4,3]], [[s5,4]], [[s6,5]], [s6,4] 8 => [[s4,3]], [[s5,4]], [[s6,5]] Saturated! Hence Ω(s0) = 8 s1 s0 s2s3 0,act sample ,write3,write4,write5,write 3,write4,write s4 s5 s6

lreach(m0) 0 => (m0,0), (m1,0), (m2,0), (m3,0) 1 => (m1,1), (m2,1), (m3,1) 2 => (m1,2), (m2,2), (m3,2) 3 => [m1,3], (m2,3), (m3,3) 4 => [[m1,4]], [m2,4], (m3,4) 5 => [[m1,4]], [[m2,5]], [m3,5] 6 => [[m1,4]], [[m2,5]], [[m3,6]] Saturated! Hence Ω(m0) = 6 m1 m0 m2 m3 0,act 3,read4,read5,read6,read 4,read5,read

lreach(r0) 0 => (r0,0), (r1,0) 1 => [r1,1] 2 => [[r1,2]] Saturated! Hence Ω(r0) = 2 r0 r1 0,act 2,read 1,read 1,write 2,write

Back to the big picture Next set of states found by taking pair- wise matches from the modules lreach sets. Notice there is no (7,write) or (8,write)? –(6, read) is a globally certain event –stragglers will have to wait for the next state (s0,0), (r0,0), (m0,0) (s7,0), (r2,0), (m0,3) (s7,0), (r2,0), (m0,4) (s7,0), (r2,0), (m0,5) (s7,0), (r2,0), (m0,6) (s0,3), (r2,0), (m4,0) (s0,4), (r2,0), (m4,0) (s0,5), (r2,0), (m4,0) (s0,6), (r2,0), (m4,0) 4,write 3,write 5,write 6,write 3,read 4,read 5,read 6,read sg0 sg1 sg2 sg3 sg4 sg8 sg7 sg6 sg5

New States – s7 New state found. lreach(s7): 0 => (s7,0), (s4,0), (s5,0), (s6,0) 1 => (s4,1), (s5,1), (s6,1) 2 => [s4,2], (s5,2), (s6,2) 3 => [[s4,3]], [s5,3], (s6,3) 4 => [[s4,3]], [[s5,4]], [s6,4] 5 => [[s4,3]], [[s5,4]], [[s6,5]] Saturated! Hence Ω(s7) = 5 2,write 3,write 4,write 5,write 3,write4,write s4 s5 s6 0,sample s7

New States – m4 New state found. lreach(m4): 0 => (m4,0) 1 => (m4,1) 2 => (m4,2), (m5,0) 3 => (m4,3), [m5,1], (m5,0) 4 => [[m5,2]], [m5,1] 5 => [[m5,2]] Saturated! Hence Ω(m4) = 5 m1 m2 m3 4,read 5,read 4,read5,read 3,read 6,read 2,read1,read 3,store2,store m4 m5

New States – r2 New state found. lreach(r2): 0 => [r2,0] 1 => [[r2,1]] Saturated! Hence Ω(r2) = 1 r1 2,read 1,read1,write 2,write r2 1,read 0,read 0,write 1,write

Back to the big picture – cont’d The local state spaces are all saturated, so now we just need to keep exploring… (s0,3), (r2,0), (m4,0) (s7,0), (r2,0), (m4,0) (s7,0), (r2,0), (m4,1) (s7,0), (r2,0), (m4,2) (s7,0), (r2,0), (m4,3) (s0,6), (r2,0), (m4,0) (s0,7), (r2,0), (m4,0) (s7,0), (r2,0), (m4,4) 1,write 0,write 2,write 3,write 3,read 4,read 4,write sg1 sg4 sg9 sg15 sg14 sg13 sg12 sg11 (s0,8), (r2,0), (m4,0) 5,read sg10 (s7,0), (r2,0), (m4,5) 5,write sg16

Back to the big picture – cont’d The exploration continues… (s7,0), (r2,0), (m0,3) (s7,0), (r2,0), (m0,5) (s7,0), (r2,0), (m0,6) (s7,0), (r2,0), (m4,0) (s7,1), (r2,0), (m4,0) (s7,2), (r2,0), (m4,0) (s7,3), (r2,0), (m4,0) 3,write 2,write 0,read 1,read 2,read 3,read sg7 sg8 sg5 sg11 sg17 sg18 sg19

Back to the big picture – cont’d And a bit more… (s7,0), (r2,0), (m4,0) (s7,0), (r2,0), (m4,2) (s7,0), (r2,0), (m4,3) (s7,0), (r2,0), (m4,4) (s7,0), (r2,0), (m4,5) (s7,3), (r2,0), (m4,0) (s7,4), (r2,0), (m4,0) (s7,5), (r2,0), (m4,0) 3,write 2,write 4,write 5,write 3,read 4,read 5,read sg11 sg13 sg15 sg14 sg16 sg19 sg20 sg21

Back to the big picture – cont’d And some congruent activity… (s7,2), (r2,0), (m4,0) (s7,0), (r2,0), (m4,0) (s7,0), (r2,0), (m4,1) (s7,0), (r2,0), (m4,2) (s7,0), (r2,0), (m4,3) (s7,5), (r2,0), (m4,0) 1,write 0,write 2,write 3,write 3,read sg18 sg11 sg13 sg12 sg14 sg21

Ω Limits We will only find events in these ranges: –write Є (s0, [3,8]) U (s7, [2,5]) –read Є (m0, [3,6]) U (m4, [3,5]) –both of these dominate the register ranges. In practise a ‘real’ tool would probably throw out most of the lreach data once the event ranges for each entry state have been calculated.

Guestimating |SG|… From the previous ranges we know that s7 and m4 can only go up to 5s before they will definitely ‘go off’. –so there are less than ~12 ‘core’ states because at least two modules will always be 0 –plus we need to clear the initialisation delays out at the start, less than ~14 states –Should be less than ~26 states in the synch graph, which is well below 7 x 6 x 3.

Guestimating |SG|… - cont’d

And the triple-write property? Can happen for really bad cases: –[…, sg21, (0,write), sg11, (2,write), sg13, (2,write), sg15, …] This is because the read cycle is between [3,5] and the write cycle is between [2,5]. So if the sensor is having a good day, and the monitor a bad one, we can miss out. But this is not necessarily ‘obvious’ from eye- balling the model, as one’s first thought might be that since > 5 we should be safe…

What can we do? Need to bring the two interval ends closer. –get the reading cycle down to 3s; or –add a choke to the writing cycle for an extra 1s Unless both ranges are constant, we can always fire the first event for “free” (zero time), so the rate test is simply: –min(acycle) * (n – 1) > max(bcycle)

What next?