Embedded.com - Queueing Theory for Dummies

Embedded.com - Queueing Theory for Dummies - Ready for a...

Info iconThis preview shows pages 1–2. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Ready for a change? Open | Close Your ad here. Buy Media Now All Articles Products Column Courses VirtuaLabs Webinars Login | Register Welcome Guest Embedded.com Queueing Theory for Dummies By David Kalinsky Embedded Systems Design (03/15/01, 01:02:04 PM EST) How do you size a buffer or message queue? Queueing theory provides the answer. From time to time when I teach classes on software development for embedded systems, I'm asked how to figure out the maximum number of messages that will queue up in a message queue. When I answer, "Oh, that's just queueing theory," I invariably hear an uncomfortable nervous sort of laughter. Everyone is thinking "Sure! I'm gonna stop my project for a semester so I can take a course in queueing theory just to figure out how long to make my program's message queue. Where's this guy been living?" Similar questions come up about the capacity of linked lists and ring buffers, or the number of buffers in a buffer pool, or even the assignment of dual-port RAM to buffer descriptors inside of PowerQUICC communications processors. These questions impact directly the amount of memory that must be allocated to the resource at issue, and the capacity of an embedded system to handle the ebb and flow of data. Sometimes engineers use empirical methods to estimate the required capacity. In one method, they divvy up all available RAM in their development target board, assigning it to their stacks, their queues, their linked lists, and buffer pools. Hopefully the hardware team has supplied more than enough RAM to accomodate all of these structures. Before running the application software, test software "paints" these structures with a standard but improbable content, for example, patterns of 0xAAAAAAAA, 0x55555555, or 0xDEADDEAD. Then the application is run for a while and later the structures are examined to see how much of the standard "paint" is left. The area where "paint" remains presumably hasn't been used by the application, and most of it can probably be eliminated. In another empirical technique, many RTOS-sensitive debuggers/profilers and "object browsers" can measure the maximum number of messages in a queue at any time during an experimental run of application software. Some will even show you graphs of queue filling as a function of time. Similar graphs can be obtained for stacks and buffer pools. The high point of the graph will tell you how much of the capacity your software actually used. But is this number a good measure of the required capacity for a given message queue, stack, or buffer pool? Perhaps not, since seconds or minutes after the end of the experimental run of the software, its memory needs might increase dramatically had it continued to run. And this information would not be captured by any empirical method....
View Full Document

This note was uploaded on 07/16/2009 for the course SYSC 3303 taught by Professor Shramp during the Spring '09 term at Carleton CA.

Page1 / 5

Embedded.com - Queueing Theory for Dummies - Ready for a...

This preview shows document pages 1 - 2. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online