Your SlideShare is downloading. ×
How to Measure RTOS Performance
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

How to Measure RTOS Performance

2,079
views

Published on

How to Measure RTOS Performance – Colin Walls …

How to Measure RTOS Performance – Colin Walls

In the world of smart phones and tablet PCs memory might be cheap, but in the more constrained universe of deeply embedded devices, it is still a precious resource. This is one of the many reasons why most 16- and 32-bit embedded designs rely on the services of a scalable real-time operating system (RTOS). An RTOS allows product designers to focus on the added value of their solution while delegating efficient resource (memory, peripheral, etc.) management. In addition to footprint advantages, an RTOS operates with a degree of determinism that is an essential requirement for a variety of embedded applications. This paper takes a look at “typical” reported performance metrics for an RTOS in the embedded industry.

Published in: Technology

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,079
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
88
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. How to Measure RTOS Performance Colin Walls colin_walls@mentor.comwith acknowledgement to Faheem Sheikh & Dan Driscoll mentor.com/embedded
  • 2. AgendaIntroductionRTOS MetricsMemory FootprintInterrupt LatencyScheduling LatencyTiming Kernel ServicesConclusions
  • 3. AgendaIntroductionRTOS MetricsMemory FootprintInterrupt LatencyScheduling LatencyTiming Kernel ServicesConclusions
  • 4. Introduction – Why? Desktop computers Embedded systems – Infinite CPU power – Enough CPU power – just – Infinite memory – Adequate memory – none to spare – Costs nothing – Power consumption an issue – Cost normally critical
  • 5. Introduction – Choosing an RTOSRTOS solutions – Proprietary [in-house; home brew] – Commercial – At least 200 product available – Open sourceAsking the right questions is importantUnderstanding the answers is critical – Pitfalls with misinterpretation
  • 6. AgendaIntroductionRTOS MetricsMemory FootprintInterrupt LatencyScheduling LatencyTiming Kernel ServicesConclusions
  • 7. RTOS MetricsThree common categories: – Memory footprint – Program and data – Latency – Interrupt and scheduling – Services performanceNo real standardization – Embedded Microprocessor Benchmark Consortium (EEMBC) not widely adopted – Oriented towards CPU benchmarking
  • 8. AgendaIntroductionRTOS MetricsMemory FootprintInterrupt LatencyScheduling LatencyTiming Kernel ServicesConclusions
  • 9. Memory FootprintRAM and ROM requirements of RTOS – On a specific platform ROM size:  RAM size: – Kernel code – Kernel data structures – Read-only data – Global variables – Runtime library code – May need – Maybe in flash; accommodate “ROM” possibly copied to RAM
  • 10. Memory Footprint – DependenciesKey factors affect the footprint calculationCPU architecture – Huge effect on number of instructionsSoftware configuration – Which kernel components are included – Scalability ...Compiler optimization – Reduces code size, but may adversely affect performance
  • 11. Memory Footprint – Scalability RTOS Application Memory Service #1 … rtos_call_1(); Service #2 … rtos_call_3(); Application Service #3 … Code Service #4 rtos_call_157(); … RTOS Service #271 core Service #1 Service #3 Service #157
  • 12. Memory Footprint – MeasurementMaking measurement need not be difficultTwo key methods: – Memory MAP file – Generated by standard linkers – Quality and detail varies between tools – Specific tool – Shows footprint information for selected executable image – Example: objdump
  • 13. Memory Footprint – ImportanceLimited memory availability – Small on-chip memory – No external memory option – Application code is priorityLarger systems – Kernel performance a priority – Place in on-chip memory – Lock into cacheUsing a bootloader – Non-volatile memory and RAM space used
  • 14. Memory Footprint – PitfallsVendor data can be readily misinterpretedLook at minimum configuration definition – It may be a tiny, impractical subsetRuntime library functions are often not includedRAM/ROM sizes should have a min/max range – RAM is likely to be application dependent – ROM driven by kernel configuration – Need minimum “useable” size – Also maximum measure with all services – Scalability variable – may be different kernel versions
  • 15. Memory Footprint – ExampleNucleus RTOS kernel is fully scalableExample: ARM Cortex A8 in ARM modeBuilt with Mentor Sourcery CodeBench toolchainFull optimization for sizeROM = 12-30 KbytesRAM = 500 bytes
  • 16. Memory Footprint – ExampleMin has essential kernel services [dynamic memory, threads, semaphores, events, queues] – Runtime library excludedMax includes all kernel servicesCompiling for Thumb-2 mode reduces ROM by 35% – So Nucleus kernel can use 7.8 Kbytes on a Cortex-M based controller
  • 17. AgendaIntroductionRTOS MetricsMemory FootprintInterrupt LatencyScheduling LatencyTiming Kernel ServicesConclusions
  • 18. Interrupt Latency Definitions of interrupt latency
  • 19. Interrupt Latency – DefinitionDifferent definitionsSystem: Time between interrupt assertion and the instant an observable response happensOS: Duration of when the CPU was interrupted until the start of the corresponding interrupt service routine (ISR) – This is really OS overhead – Many vendors refer to this as the latency – Hence often report zero latency
  • 20. Interrupt Latency – MeasurementInterrupt response is the sum of two distinct times: ƮIL = ƮH + ƮOSwhere: ƮH is the hardware dependent time – depends on the interrupt controller on the board as well as the type of the interrupt ƮOS is the OS induced overhead – Best and worst case scenarios – Worst when kernel disables interrupts
  • 21. Interrupt Latency – MeasurementBest approach is to record time between interrupts source and response – Use an oscilloscope – For example: – One GPIO pin can generate an interrupt – Another pin toggled at the start of the ISR
  • 22. Interrupt Latency – ImportanceSpecific types of designs rely on this metric: – Time critical – Fault tolerantIf high I/O bandwidth is needed, measure the latency of a particular interruptMost systems can tolerate interrupt latency of tens of microseconds
  • 23. Interrupt Latency – PitfallsMain danger is interpretation of published figuresKey factors to check:Hardware configuration OS configuration – Which platform? – Where is code running – CPU speed? from? [Flash, SDRAM ...] – Cache configuration? – Which interrupt used? – Timer frequency? – Code optimized for speed? – Interrupt controller type? – Is metric best or average case?
  • 24. Interrupt Latency – ExampleNucleus RTOS – ARM Cortex A8 – 600MHz – Running from SRAMAverage interrupt latency of less than 0.5 microseconds
  • 25. AgendaIntroductionRTOS MetricsMemory FootprintInterrupt LatencyScheduling LatencyTiming Kernel ServicesConclusions
  • 26. Scheduling Latency – DefinitionPerformance of RTOS thread schedulerVery wide variation in measurement technique and interpretationTwo distinct related quantities: – Context switch time – Scheduling overhead
  • 27. Scheduling Latency – DefinitionContext switch time
  • 28. Scheduling Latency – DefinitionScheduling overhead
  • 29. Scheduling Latency – MeasurementScheduling latency is the maximum of two times: ƮSL = MAX(ƮSO, ƮCS)where: ƮSO is the scheduling overhead – End of ISR to start of task schedule ƮCS is the time taken to save and restore thread context
  • 30. Scheduling Latency – ImportanceMost systems that have stringent interrupt latency demands also need low scheduling latencyBroadly, systems that are: – Time critical – Fault tolerant
  • 31. Scheduling Latency – PitfallsIgnoring initial system state – If system is idle, there is no time taken saving contextKey factors to check:Hardware configuration OS configuration – Which platform? – Where is code running – CPU speed? from? [Flash, SDRAM ...] – Cache configuration? – Which interrupt used? – Timer frequency? – Code optimized for speed? – Interrupt controller type? – Is metric best or average case?
  • 32. Scheduling Latency – ExampleNucleus RTOS – ARM Cortex A8 – 600MHz – Running from SRAMScheduling latency is 1.3 microseconds
  • 33. AgendaIntroductionRTOS MetricsMemory FootprintInterrupt LatencyScheduling LatencyTiming Kernel ServicesConclusions
  • 34. Timing Kernel ServicesRTOS may have a great many API callsTiming of keys ones may be of interest – Focus on frequently used API callsFour key categories: – Threading services – Synchronization services – Inter-process communication services – Memory services
  • 35. Timing Kernel ServicesThreading Services – Control of fundamental kernel functionality: – Create thread – Start thread – Resume thread – Stop thread – Many multi-taking applications make heavy use of these calls
  • 36. Timing Kernel ServicesSynchronization Services – Services to synchronize between contexts, like an ISR and a thread – Also protection of critical code sections from concurrent access – e.g. Semaphore may be used by Ethernet ISR to write data into shared memory that is also used by a task – Timing is important is the application has numerous shared resources or peripherals
  • 37. Timing Kernel ServicesInter-process Communication Services – Services to share data between multiple threads – Examples: – FIFOs – Queues – Mailboxes – Event flags – Many multi-taking applications make heavy use of this type of service
  • 38. Timing Kernel ServicesMemory Services – In a multi-threaded context, kernel is used to manage dynamic memory – Allocation and de-allocation times are important – Applications with large data throughput are particularly sensitive
  • 39. Timing Kernel Services – PitfallsHardware configuration – Which platform? – CPU speed? – Cache configuration?OS configuration – Where is code running from? [Flash, SDRAM ...] – Code optimized for speed? – Is metric best or average case? – Is kernel configured for reduced error checking?
  • 40. Timing Kernel Services – Example Nucleus RTOS Kernel Service Time in µS Task resumption 0.3 Task suspension 0.3 Obtaining a semaphore 0.5 Set an event 0.4 Send message to queue 0.9 Allocate memory 0.2 De-allocate memory 0.7 Allocate partition 0.4
  • 41. AgendaIntroductionRTOS MetricsMemory FootprintInterrupt LatencyScheduling LatencyTiming Kernel ServicesConclusions
  • 42. ConclusionsRTOS performance data provided by vendors can be usefulIt can also be misleading if it is misinterpretedNeed a thorough understanding of: – Measurement techniques – Terminology – Trade-offs to conduct fair comparisonRecommendation is to rely on holistic or application- oriented measurements
  • 43. Thank you Colin Walls colin_walls@mentor.com http://blogs.mentor.com/colinwalls See white paper:"Measuring RTOS Performance: What? Why? How?" mentor.com/embedded