자신에 대한 고찰

계속 이어서 Utilization Bound Check을 다뤄보려고 한다. 일단 간단히 요약하자면 우리는 task들을 보면서 해당 task의 execution time과 period를 구할 수 있다. 이를 바탕으로 Utilization이라는 것을 구할 수 있었는데 System내에서도 task가 여러 개이기 때문에 Utilization들을 모두 합친 Total Utilization을 얻을 수 있을 것이다. 이 값과 Scheduling algorithm을 적용한 후의 Utilization의 최소값, 즉 Utilization Bound와 비교를 통해서 Schedulability를 측정하는 방식이 지난 포스트에 언급한 Utilization Bound Check의 내용이었다. 그래서 이번에는 실례를 통해서 다시 ..

계속해서 과제를 진행하고 있다. 지금 주목하고 있는 것은 Xenomai에 내장되어 있는 periodic function을 linux system call인 sleep() 으로 대체할 수 있느냐는 것이다. 방법은 간단하다. Iteration을 줄때 job 시작전이나 종료후에 강제로 sleep()을 주면 되는 것이다. 그럼 과연 이렇게 바꿨을 때 expected release time과 actual Release time의 차이는 어떻게 될까? 또는 Expected Finish time과 Actual Finish time간의 차이는 어떻게 될까? 이 값이 얼마 차이가 나지 않는다면 이 Task들은 Periodic이라고 할 수 있을까? 그럼 이걸 개선해서 Sleep만 사용해서 조금더 periodic 하게 바꿀..

바로 이전 포스트에서 Schedulability를 측정하는 방법 중 하나인 Utilization Bound Check을 소개했다. 수식으로 표현하면 다음과 같다.즉 Utilization Bound 를 구하고 sum이 Bound를 넘지 않으면 무조건 schedulable하다는 것이다. 그래서 EDF의 Bound는 1라는 걸 언급했었다. 그런데 내가 숙제로 진행하고 있는 건 EDF같은 Dynamic Priority가 아닌 RM과 같은 Static Priority, 즉 Priority가 아예 정해진 방식이다. 이때는 포스트에선 아직 이야기 하지 않았지만 Liu&Layland 가 증명한 식에 의해서 U(bound) 가 69%이다. 이 값을 보통 L&L Bound 라고 하기도 한다. 아무튼 숙제의 목적은 각 Ti..

이전 포스트를 통해서 Schedulability를 측정하는 방법 중 하나인 Time Demand Analysis를 소개했고, 그걸 Xenomai 상에서 검증하는 과정을 보였다. 우리가 이렇게 Schedulability에 신경쓰는 이유가 무엇일까? 바로 지금 우리가 다루는 것이 Real Time OS이기 때문이다. formal한 OS와 RTOS와의 차이는 Deadline이 Task 처리시 어떻게 작용하냐는 것이고, 특히 RTOS에서는 보통 Deadline이 task scheduling에서 중요한 요소로 고려된다. 즉, task가 적절하게 scheduling이 되지 않아서 발생하는 miss는 시스템의 동작에 치명적으로 작용할 수 있다는 것이다. 그래서 task에 대한 execution time과 period..

지난 포스트중에 Time Demand Analysis에 대한 내용을 다룬 적이 있다. 간단하게 이야기 하면 다음과 같다. 위와 같은 Time Demand Fuction이 존재한다. 이렇게 구한 결과 값이 각 job에 대한 response time인데 이 값이 해당 period 내에서 period보다 넘어서지만 않으면 Schedulable하다고 말할 수 있다. 반면 이 값이 period를 넘어서게 된다면 말그대로 Not schedulable하게 될 것이다. 그걸 지난 시간에 구한 Execution Time Checking을 통해서 구한 결과를 바탕으로 각 job에 대한 response time을 구해봤다. 참고로 이때의 Iteration Time은 10이다. 생각을 잘 못하고 있었던게 이 Time Dema..

현재 과제로 각 Task에 Priority를 준후 Average Execution Time과 Maximum Execution Time, 즉 Worst Case Execution Time을 측정하고 있다. 이를 토대로 RTS 이론 시간에 다뤘던 Time Demand Analysis와 Utilization Bound Checking을 적용하고 이에 따른 Schedulability를 유추하고자 한다. 현재 주어진 Task는 다음과 같다.- Task 1 : Period : 10s 내용 : Task 3, Task 4의 연산 횟수 측정- Task 2 : Period : 0.1s 내용 : fibonacci(1000000) 측정- Task 1 : Period : 1s 내용 : summation(1000) 측정- Tas..

지난 포스트에서 Task의 worst Case를 통해서 Schedulability를 판단하는 Critical Instant Theorem에 대해서 언급을 했었고, 이번 포스트에서는 그때 구한 방법을 통해서 Rate Monotonic 방식이 Optimal인지를 확인해보는 과정을 정리해보고자 한다. 우선 전에도 쓴 내용이겠지만 Optimality를 증명하는 것은 즉, 어떤 task Schedule이라도 특수한 Algorithm을 거치면 RM-based Schedule로 바꿀 수 있다는 것을 보여주기만 되는 것이다. 하지만 Static-priority에서는 그 task의 주기마다 deadline과 만나는지를 검증하는 단계가 있어야 하고 그 걸 확인하기 위해서는 매 주기마다 task를 검증하는 불필요한 과정이 ..

이전 포스트 중에 Reference model의 분류에 관한 내용을 다뤘던 적이 있고, 그중에 우선 순위에 따라 Scheduling model을 결정하는 Priority Driven Approach에 대해서 언급했었다.그 때 Scheduling에 고려되는 Priority가 Task에 따라서 변경되는지의 여부에 따라서 Static (Fixed) / Dynamic 으로 나눠졌었다. 그런데 과연 이 Priority가 높다고 해서 그 task가 Critical하다고 할 수 있을까? 사실 그 개념이 애매하긴 하지만 지금까지 배운 내용을 되짚어보면 그렇지 않은 예를 찾아볼 수 있다. System Task의 경우 그 task의 동작이 멈춘다면 시스템의 동작에 영향을 준다. 반면 워드 프로세싱이나 인터넷 같은 task..

Optimal이란 단어 자체는 모호하다.사실 판단하는 기준이 어떻냐에 따라서 Optimal의 정도가 바뀔 수 있기 때문이다. 그래서 시스템의 최적성 판단시 Optimality 를 측정하기란 쉽지 않다. 그런 가운데에서도 가장 쉽게 취할 수 있는 approach는 바로 자기 자신을 기준으로 삼는다는 것이다. 자신을 기준으로 어떤 변형이 가해진 시스템에 적합하다고 증명하면, 다른 시스템에 대해서도 적용하기 쉽다는 방식이다. 지금 다루는 실시간 시스템의 경우에도 만약 자기가 만든 알고리즘이 어떤 환경에서든 schedulable 하다면 완벽하지는 않겠지만 그래도 어느정도 Optimality가 있다고 판단할 수 있을 것이다. Realtime System 책에서 다루는 다음 주제는 지난 포스트에서 다뤘던 Prior..

기본 환경은 다음 환경에서 구축하였고, 앞에서 소개한 스크린샷이 이환경에서 작성되었다. - VMWare Workstation 8.0 - Core 2x2 - RAM : 2GB - OS : Ubuntu 10.04 LTS x86 - Kernel : linux-2.6.32.20 (https://www.kernel.org/pub/linux/kernel/v2.6/) - Tool : Xenomai-2.6.0 (http://www.xenomai.org/index.php/Main_Page)ADEOS2.6.32.20-x86 (http://download.gna.org/adeos/patches/v2.6/x86/older/) (1) kernel package 설치 (2) Kernel build를 위한 essential too..

Xenomai는 Linux기반의 Realtime System을 개발하기 위한 Framework이다.나중에 까먹을 것을 대비해서 몇가지 팁을 정리해보고자 한다.

System이 원활하게 돌아가기 위해서는 무언가의 제어를 받아야 한다. 보통 그 무언가를 processor로 정의하고 있으며, 이 processor가 발생시키는 clock의 timing을 활용해서 Task scheduling을 한다. 이번 포스트에서는 Liu 교수가 쓴 Real Time Systems 의 chapter 4에 나오는 Realtime Scheduling에 대해서 조금 정리해보고자 한다. 앞에서 언급한대로 clock의 timing이라는 건 시스템내에서 주기적으로 정확하게 발생하는 이벤트이다. 즉, 가장 쉽게 생각해볼 수 있는 scheduling은 이 clock을 기준으로 Task를 할당하는 Clock Driven Scheduling Approach가 될 것이다. 다른 말로는 Time-Drive..

지난 포스트에서 Real Time System을 구현할 때 Reference model을 설정해놓으면 좋은 점에 대해서 언급했고, 그 중 하나로 Workload에 따른 분류를 해봤다. 이번 포스트에서 다룰 내용은 Resource 차원과 Scheduling 차원에서 정해진 Reference Model을 정리해보고자 한다. System내에서 Resource라고 부를 수 있는게 뭐가 있을까? 생각해보면 PC의 성능을 나타내는 지표를 쭉 정리해보면 일차적으로 processor가 있을 것이고, 그 processor에 Data를 전달하기 위한 Bus, 그 Data를 담고 있던 storage,communication Channel등 task가 실행되고 전송되면서 거치는 모든 것들이 다 Resource라고 정리할 수 ..

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

실시간 시스템 수업을 듣는 중 RTOS의 정의에 대해서 정리할 필요성이 있어서 남긴다. 시스템이란 간단하게 사용자의 입력에 맞는 적절한 출력을 내보내는 기기들의 총집합이라고 생각한다. 그래서 우리가 생활을 하는 주변에도 시스템은 언제나 존재한다. 그 와중에 Computation을 목적으로 삼지 않는 기기들을 따로 Embeded System이라고 한다. 그래서 컴퓨터와 같이 Computation을 바탕으로 돌아가는 시스템이 아닌, 냉장고, 세탁기와 같은 생활 가전 등에 들어가는 시스템을 embeded System이라고 할 수 있다. 예전에는 Cell phone 같은 경우도 임베디드 시스템에 포함시켰는데 요즘은 그 구분이 점점 모호해지는 듯 하다. 아무튼 그런 기기들을 보면 단순히 한 가지 기능만 수행하는 ..