계속해서 과제를 진행하고 있다. 지금 주목하고 있는 것은 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..
이전 포스트 중에서 Left Recursive와 Right Recursive를 설명하면서 Parse Tree 라는 것을 잠깐 언급한 적이 있다.말 그대로 해당 구문을 분석한 것이다. 그때 어떤 방향으로 분석하는지에 따라서 결과가 다르게 나올 수 있다고 했었다. 그런데 사실 이걸 판단하는 단계는 이전 과정에서 끝나는 것이고, 이 parse 방향이 정해지면 사실 결과만 빼놓고는 필요없는 내용이다. 우리가 필요로 하는 것은 terminal로 구성된 syntax일 뿐이다. 그래서 위의 parse tree 중 derivation 과정을 제외하고 필수적인 정보만 담은 tree를 Abstract Syntax Tree(AST)라고 한다. 물론 이름에서 담고 있듯 축약만 하고 있는 거지 Parse Tree와 동일한 정보..
지난 포스트를 통해서 Context Free Grammar에 대해 다뤘다. 간단히 요약해보자면 Regular Expression으로 표현하기 힘든 문법들이 존재하기 때문에 표현하기 위한 대체 방안으로 CFG를 언급했고, 여기서 Syntax Tree를 그려보았다. 여기서 Left Recursive문제가 발생하기 때문에 이를 해결하기 위한 방법으로 Left Factoring, 즉 terminal을 오른쪽에 배치해서 해결할 수 있다고 했다. 그런데 그때 잠깐 소개했던 내용중에 이런게 있었다. 이 때 이걸 Notational Convention이라고 소개했다. 이게 정의되어 있어야 어떤 부분을 terminal로 할지 또는 nonterminal로 할지를 정할 수 있었다. 사실 위의 내용은 사용자가 임의로 정한 n..
이전 포스트를 통해서 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..
우연한 기회에 Nvidia Seminar를 듣게 되었고 새로운 프로그램에 대한 소개를 받았다. 아시는 분도 있겠지만 지포스 그래픽 카드를 쓰면서 게임을 즐겨 하는 사람한테는 최적의 솔루션이 되지 않을까 생각한다. 이 포스트에서 소개하려는 건 Geforce Experience라는 프로그램이다. 이 프로그램의 역할은 그래픽카드를 오버클러킹해서 성능을 극대화시키는 것이 절대 아니다. 단순히 게임내 환경 설정을 카드의 성능에 맞게 최적화 시켜주는 프로그램이고 그 뿐이다. 사실 게이머가 게임을 시작할때 제일 처음 해보는 것이 비디오 환경 설정인데 이걸 그래픽카드에 맞춰서 일일히 설정하는 일은 참 번거롭다. 그래서 이 설정을 자동화해주는 것이 Experience의 역할이다. Nvidia 측에 따르면 Experien..
연구실에서 관심있으면 해보라고 한 프로젝트가 있어서 잠깐 소개하고자 한다. 뭐 대외비는 아니니까... 인텔이 만드는 프로세서는 참 다양하다. 우리가 쓰고 있는 x86의 거의 대부분을 생산하고(물론 AMD가 있긴 하지만...) 개인용 프로세서는 물론 산업용, 군용 프로세서까지 생산하고 있다. 그중 학교에 하나 마련되어 있는 특수 프로세서가 바로 Single Chip Cloud (SCC)라는 것이다. 미국에는 백여개 대학에 배포되어 있지만 한국에는 딱 한대 존재한다. 2010년에 만들어진 프로세서인데 어떤 사람이 느끼기엔 나온지 너무 오래된거 아니냐고 생각할 수 있다. 하지만 이 작은 프로세서 상에 6개의 섹터가 있는데 하나의 섹터당 8개의 core가 달려있다. 즉, 48개의 core가 달린 단일 프로세서인..
현재 과제로 각 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를 검증하는 불필요한 과정이 ..
학부때는 Visual Studio 쓰다가 대학원 올라와서는 Linux를 다룰 일이 많아서 vim을 쓴다. 생각보다 vim이 직관적이고 plug-in을 잘 활용하면 VS만큼이나 효율성을 가져갈 수 있다고 생각한다. 무엇보다 빠르니까.. 그 중에서도 Taglist를 사용하면 Function이나 macro, variable에 대한 나열을 쉽게 하고 쉽게 찾아갈 수 있기 때문에 필수적인 plug in이 아닌가 싶다. 설치는 무척 쉽다. 그냥 몇가지 설치해주고 파일을 옮겨주기만 하면 끝이다.처음으로 설치 해야 될 것은 Ctag plug-in 이다. sudo apt-get install ctags 그 후 taglist 홈페이지에 가서 압축 파일을 받아 지정된 폴더에 집어넣어주면 된다.mv doc/taglist.tx..
이전 포스트 중에 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..
일요일인데도 이렇게 택배가 오네요. 며칠전에 제 생일이어서 저한테 뜻깊은 선물이 없을까 하다가 고른 물건이 바로 이 Rocksmith입니다. Rocksmith는 기타를 pc와 연결해서 즐기는 리듬형 게임입니다. 기본적으로 스팀과 연동이 되어있어야 하지요. 어떤 게임인지 감이 안잡히시는 분이라면 동영상을 한번 보세요. 원래는 앰프와 연결해서 혼자 즐기던 것을 위와 같이 실제 노드를 짚으면서 즐기는 게임입니다. 사실 이전에도 기타 히어로라는 게임이 있긴 했었는데 그 게임은 위처럼 직접 운지를 해서 즐기는 게 아니라 콘솔에 버튼이 달려있어서 해당 타이밍에 눌러주는 식이었습니다. 물론 쉽게 즐길 수 있기 하지만 그래도 현실감이 없지요. rocksmith는 직접 기타를 현결해서 즐길 수 있어서 좋더군요. 패키지로..
- Total
- Today
- Yesterday
- bias
- Windows Phone 7
- 딥러닝
- Kinect for windows
- TensorFlow Lite
- 강화학습
- 한빛미디어
- SketchFlow
- dynamic programming
- Gan
- windows 8
- Offline RL
- arduino
- Off-policy
- PowerPoint
- RL
- End-To-End
- Distribution
- Kinect SDK
- Expression Blend 4
- reward
- processing
- Policy Gradient
- ColorStream
- 파이썬
- ai
- Variance
- Pipeline
- Kinect
- DepthStream
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |