[Study] Real Time Task Model - Definition of Reference model in work load

 System을 설계할 때는 두가지 접근 방식이 있다. 하나는 Monolithic Approach이고 다른 하나는 Do-It-Yourself Approach이다. 사실 생각해보는 사람에 따라서 어떤 접근 방식을 취하느냐가 다를 수 있는데 Realtime System의 경우에는 Monolithic Approach가 적합하지 않다. 왜냐하면 Realtime System 자체가 여러개의 모듈의 결합으로 만들어진 경우가 대부분이기 때문에 뭔가를 하나로 뭉뚱그려서 정의를 할 수 없다. 또한 경우에 시간에 따라 system의 결과물이 가변적이기 때문에 이 또한 정의하기가 힘들어서이다.

 그 대신 어떤 기준 모델에 대한 정의를 할 필요성은 있다. 이전 포스트에서 잠깐 언급했던 workload라는 기준으로 Reference model을 정의할 필요도 있으며, 또는 System 자체에 할당된 Resource에 관해서도 Reference를 둘 수 있다. 만약 이렇게 둔다면 뭔가 디자인하거나 특수 환경에 맞춰서 쉽게 응용할 수도 있을 것이고, 이로써 직접적으로 부딪치는 여러가지 문제에 대해서도 solution을 쉽게 일반화시킬 수 있을 것이다. 

 만약 기기를 어떤 기준에 나눠서 분류할 수 있을까? 그건 참 어렵다. 

 주위를 둘러보면 알겠지만 System 자체가 각기 만든 곳도 다르고 주어진 환경도 다르기 때문에 이런 Reference model을 만들기가 쉽지 않은 것이다. 벌써 스마트폰만 봐도 어떤 건 ARM core를 사용한게 있고, 어떤 건 x86 기반의 mpu를 사용했을 수도 있다. 또는 ARM core를 사용하는 스마트폰이라도 내부에 어떤 센서를 달았느냐에 따라서 그 기준을 두기가 참 쉽지 않은 것이다. 이에 따라서 스마트폰 개발자도 어플을 개발하는데 있어서 어려움이 발생할 수 있다. 이때문에 나온 것이 넥서스와 같은 Reference model이다. 물론 이 Reference model의 의미 자체가 안드로이드에서는 조금 의미가 없긴한데, 아무튼 이 Reference model에서 돌아가는 것을 보장한다면 개발자들도 그만큼 개발을 쉽게 할 수 있을 것이다.(안드로이드에선 Reference model 자체가 그냥 구글에서 만든 실험용 기기일뿐인 듯 하다...) 

 그럼 이런 환경적요소에 따른 Reference model을 고려할 것이 아니라 앞에서 언급한 workload나 resource에 따른 reference model을 만들어보는 건 어떨까? 그렇게 일반화를 시키면 어떤 장치를 더해서 구현하던 추구하는 목적은 같기 때문에 구현에 있어서 편의를 가져갈 수 있을 것이다. 물론 확실성은 떨어지고 모호성이 증가하겠지만... 

 그래서 이번 포스트에서 다뤄볼 건 workload와 resource, algorithm에 따라 나눌 수 있는 reference model을 정리해보려고 한다. 

  이런 시스템을 공부하면서 어떤 것을 workload라고 구분지을 수 있을까?

이 이미지가 보통 workload를 전부 표현한 단편적인 예이다. 여기서 보면 task도 있고, task에 대한 deadline도 존재한다. 또는 task가 실질적으로 실행되는 Execution Time도 포함되어 있다. 이 모든게 다 workload이고 이 것들에 맞춰서 reference model을 설계할 수 있을 것이다. 강의자료에서는 다음과 같이 나눠서 workload reference model을 구분했다.

 - Release Time 

 - Deadline

 - Execution Time

일단 다음 그림을 보자.

Release Time과 deadline은 짧게 이야기 하면 Task의 시작과 끝에 대한 기준점이다. 그렇다고 Release time이 Task의 Start Time인 것은 아니다. Release time의 정의는 task가 execute할 준비가 된상태를 말하는 것이다. 그래서 위의 그림을 다시 설명하면 Release time과 deadline 사이에 task가 반드시 시작되고 종료되는 것이 가장 이상적인 Task Operation이 되는 것이다. 

 그러면 위와 같은 것도 시간과 관련한 변수이기 때문에 이런 변화가 주기적이냐 비주기적이냐로 구분지을 수 있다. Release time이 Periodic 하면 task는 일단 주기적으로 수행될 준비가 된다는 의미이다. 하지만 앞에서 언급한 것과 마찬가지로 시간이란 요소가 개입되어 있기 때문에 오차가 발생할 여지도 존재하는데 보통 이런 오차를 jitter라고 한다. 아니면 Release Time이 비주기적으로 생성될 수 있는데 특히 그 중에서도 Release Time간의 간격이 매우 작아서 거의 연속적인 task 처럼 보이는 것을 sporadic task라고 말한다. 

 또 다른 관점은 deadline이 어떤식으로 정의되어 있느냐는 것이다. 이 또한 주기성에 따라서 Absolute냐 Relative냐로 나눌 수 있고, 아니면 이전 포스트에서 이야기 했던 것처럼 soft냐 hard냐 로도 나눌 수 있다. 보통 deadline이 정해져 있으면 Execution된 상태와의 시간차이도 정의할 수 있는데 이걸 Laxity라고 한다. 가령 로켓이 발사할 때 세는 Countdown 자체도 하나의 Laxity가 되는 것이다. 

마지막 관점이 바로 Execution Time인데 이를 구분하기 위해서는 Worst-case Execution Time과 Average Execution Time에 대해서 알아야 할 필요가 있다. 앞에서 정의한 것처럼 Task가 수행되는 시간자체가 Execution Time인데 System이 수행하는 이상 Execution time이 항상 고를 수가 없다. 물론 제각각이기에 그에 대한 Average를 내서 계산하는데 이것과 가장 worst case인 Execution Time을  고려하는 것이다. 그래서 그 차이가 얼마 안나면 Deterministic Execution Time, 차이가 나서 고려하지 않는 모델은 Stochastic Execution time을 적용했다고 언급한다. 그러니까 실행되는 정도가 균일한 걸 deterministic, 그 정도 여부를 따지지 않는 것을 stochastic으로 구분짓는 것이다. 예를 들어서 video 재생같은 경우는 실제 우리가 느끼는 실상과는 다르게 잔상이나 열화 현상이 발생하지만 이게 그 동작에 크게 영향을 미치지 않기에 고려하지 않으므로 이런 건 stochastic으로 놓을 수 있을 것이다.

 그래서 위에서 언급한 내용을 하나의 diagram으로 정리해 본다.