ADD answer to questions
This commit is contained in:
		
							
								
								
									
										24
									
								
								README.md
									
									
									
									
									
								
							
							
						
						
									
										24
									
								
								README.md
									
									
									
									
									
								
							@@ -60,8 +60,26 @@ bikeSystem.start();
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
# Some questions
 | 
			
		||||
## If you print CPU statistics at the end of every major cycle (in the super-loop), what CPU usage do you observe? How can you explain the observed CPU uptime?
 | 
			
		||||
## Question 1
 | 
			
		||||
`If you print CPU statistics at the end of every major cycle (in the super-loop), what CPU usage do you observe? How can you explain the observed CPU uptime?`
 | 
			
		||||
 | 
			
		||||
We observe a 100% usage because on each CPU cycle it compare if time is done. 
 | 
			
		||||
 | 
			
		||||
## If you run the program after the change from busy wait to sleep calls, what CPU usage do you observe? How can you explain the observed CPU uptime?
 | 
			
		||||
We can observe only a usage of 75% because the CPU is more on Idle with Thread sleep.
 | 
			
		||||
## Question 2
 | 
			
		||||
`If you run the program after the change from busy wait to sleep calls, what CPU usage do you observe? How can you explain the observed CPU uptime?`
 | 
			
		||||
 | 
			
		||||
We can observe only a usage of 75% because the CPU is more on Idle with Thread sleep.
 | 
			
		||||
 | 
			
		||||
## Question 3
 | 
			
		||||
`If you run the static_scheduling_with_event program, what CPU usage do you observe? How can you explain the observed CPU uptime?`
 | 
			
		||||
 | 
			
		||||
We observe a light usage of 1% of CPU. The CPU is now sleeping all the time and doing small task only on event. 
 | 
			
		||||
 | 
			
		||||
## Question 4
 | 
			
		||||
`When you run multiple tests for computing the response time of the reset event, what do you observe? Is there an improvement as compared to the static_scheduling::BikeSystem implementation?`
 | 
			
		||||
 | 
			
		||||
`    - If you do not press long enough on the push button, the event may be missed and no reset happens.`
 | 
			
		||||
 | 
			
		||||
`Based on the program itself and on the task scheduling, explain these two behaviors. Explain also why such behaviors may be problematic.`
 | 
			
		||||
 | 
			
		||||
We notice, that we miss such less event when is event driven (or not at all). But with a static scheduling the response time is still long because the reset task is call with a certain period.    
 | 
			
		||||
		Reference in New Issue
	
	Block a user