Summary

• Page properties (1 modified, 0 added, 0 removed)
• Objects (1 modified, 0 added, 0 removed)
  • Confluence.Code.ConfluencePageClass[0]

Details

Page properties

Content

...	...	@@ -1,6 +1,6 @@
1	1	== General information: ==
2	2
3		-We are currently running an experiment for which we need participants that are willing to contribute aproximately 20 to 30 minutes of their time. All participants (unless they protest, of course) will be entered into a price draw for 3 amazon vouchers for 25 Euro value each. Thanks if you are considering to take part! Please contact Insa Fuhrmann for one of the time slots from 18th to 25th of January: 0431-880-7526 or in person in room 1113. Also contact Insa Fuhrmann if you have questions that are not answered below.
	3	+We are currently running an experiment for which we need participants that are willing to contribute aproximately 20 minutes of their time. All participants who solve the task will be entered into a price draw for 3 amazon vouchers for 25 Euro value each (if you do not want to enter the draw, just tell us so). Thanks if you are considering to take part! Please contact Insa Fuhrmann for one of the time slots from 18th to 25th of January: 0431-880-7526 or in person in room 1113. Also contact Insa Fuhrmann if you have questions that are not answered below.
4	4
5	5	The participants will be asked to give information on how experienced they are with modeling SCCharts and modeling and programming in general.
6	6
...	...	@@ -8,7 +8,7 @@
8	8
9	9	The participants will be devided into groups that will work with KIELER versions with different degrees of interactive timing support. We will measure the time it takes for each participant to solve the task as well as the number of call replacements. We will also document the final state of the model.
10	10
11		-== Here is a small example to illustrate the work process (please note that the actual model for the experiment will be larger than this example!): ==
	11	+== Here is a small example to illustrate the work process (please note that the actual model for the experiment will be somewhat larger than this example!): ==
12	12
13	13	In a KIELER instance we get a given model:
14	14
...	...	@@ -44,6 +44,26 @@
44	44
45	45	[[image:attach:ExperimentExampleArrows.png]][[attach:ExperimentExampleArrows.png]]
46	46
47		-Suppose we decide to exchange the call to getImage() with a call to takePicture(). Then we will find, that the time values do not change at all:
	47	+Suppose we decide to exchange the call to getImage() with a call to takePicture(). Then we will find that the time values do not change at all:
48	48
	49	+[[image:attach:Bildschirmfoto 2016-01-13 um 18.02.18.png]][[attach:Bildschirmfoto 2016-01-13 um 18.02.18.png]]
	50	+
49	49	[[image:attach:Example1.png]][[attach:Example1.png]]
	52	+
	53	+We can deduce that either getImage() and takePicture() take exactly the same amount of time (which is unlikely) or in worst case the transition with the second priority in HandleMotor is taken (accelerator not true). writeLog() is executed, but not takePicture() (and also not getImage() before). Therefore, exchanging getImage() for takePicture() does not show any effect.
	54	+
	55	+So let's change writeLog() to logProcess() then:
	56	+
	57	+[[image:attach:Example2.png]][[attach:Example2.png]]
	58	+
	59	+Now quite a lot has happened: First of all, we have reduced the overall worst case execution time. The decision to replace writeLog() with logProcess() seems to have been a good one. We are not done however, as we have to get below 500 tu. Second we can see that the worst case execution path has switchend and now HandleEmergency is the most time consuming region of the model. This means that errorLog() must take longer than either takePicture() or logProcess(). So now we exchange errorLog() for logErrors():
	60	+
	61	+[[image:attach:Example3.png]][[attach:Example3.png]]
	62	+
	63	+Now that was successful as well, as the overall worst case execution time is reduced again. Also, the worst case path has switched back to the HandleMotor region. That means that either logProcess() or TakePicture() take longer than logErrors(). As we already know we can only make logProcess() worse by exchanging it for writeLog(), we will now choose to change takePicture() back to getImage(). For, though we were not able to see the effect before, because writeLog() was even worse, we made a bad decision in the beginning by choosing takePicture() over getImage(). So let's revise this:
	64	+
	65	+[[image:attach:Example4.png]][[attach:Example4.png]]
	66	+
	67	+And now we have done it! The overall worst case execution time is finally below 500 and we are finished!
	68	+
	69	+Note that if you get to be part of another group, then maybe you will get only the overall worst case execution time value, or the overall value and the region values, but no hotspot highlighting, respectively.

Confluence.Code.ConfluencePageClass[0]

Id

...	...	@@ -1,1 +1,1 @@
1		-14516386
	1	+14516392

URL

...	...	@@ -1,1 +1,1 @@
1		-https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/14516386/Experiment Hotspot-Highlighting
	1	+https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/14516392/Experiment Hotspot-Highlighting