What is DRAM? In which form does it store data?

The random access memory is of two types out of which one is dynamic random access memory or DRAM and the other one is SRAM or static random access memory. 

Here we shall focus up on the first type i.e., the Dynamic RAM. 

What is Dynamic Random Access Memory (DRAM)?

- In dynamic RAM, each bit of the data is stored in a separate capacitor. 

- All these capacitors are housed within an IC (integrated circuit).

- These capacitors can be in either of the two states:

1. Charged and
2. Discharged

- The two values of a bit are represented by means of these two states only. 

- The two values of bit are 0 and 1. 

- However, there is a disadvantage of the dynamic RAM. 

- These capacitors tend to leak charge and therefore may lose all the stored information. 

- Therefore, it is very important to keep the capacitors flushing with fresh charge. 

- They are refreshed at regular intervals of time. 

- It is because of this refreshing requirement this type of RAM has been named so. 

- The main memory or the physical memory of the CPU is constituted of this dynamic RAM only.

- Apart from desktops, DRAM is also used in workstation systems, laptops, video game consoles etc. 

- The structural simplicity is one of the biggest advantages of the DRAM. 

- For each bit it only requires one capacitor and one transistor, whereas SRAM requires 4 to 6 transistors for the same purpose. 

- This enables the dynamic RAM to attain very high density. 

- DRAM is a volatile memory unlike the flash memory and so it loses data whenever the power supply is cut.

- The capacitors and the transistors it uses are extremely small and so billions of them can be easily be integrated in to one single memory chip.

- DRAM consists of array of charge storage cells arranged in a sort of rectangular way. 

- Each of the cells consists of one transistor and one capacitor. 

- Word lines are the horizontal lines that connect the rows with each other. 

- Two bit lines compose each of the columns of cells. 

- These lines are called the + and – bit lines.

- It is specified by the manufacturers that at what rate the storage cell capacitors are to be refreshed. 

- Typically, it is less than or equal to 64 ms. 

- The DRAM controller consists of the refresh logic that is responsible for automating the periodic refresh. 

- This job cannot be done by any other software and hardware. 

- Thus, the circuit of the controller is very complicated. 

- The capacity of DRAM per unit surface is greater than that of the SRAM. 

- Some systems may refresh one row at one instant while others may refresh all the rows simultaneously every 64 ms.  

- Some systems use an external timer based up on whose timing they refresh a part of the memory. 

- Many of the DRAM chips come with a counter that keeps track of which row is to be refreshed next.

- However, there are some conditions under which the data can be recovered even if the DRAM has not been refreshed since few minutes. 

- Bits of the DRAM might flip to opposite state spontaneously because of the electromagnetic interference in the system. 

- Background radiation is the major cause for the occurrence of the majority of the soft errors.

- Because of these errors the contents of the memory cells may change and circuitry might be harmed. 

- Redundant memory bits along with the memory controllers are one potential solution to this problem. 

- These bits are within the modules of the RAM. 

- The parity is recorded by these bits which enable the reconstruction of the missing data via ECC or error – correcting code.

Risk planning - Accounting for when estimates are prepared by one person and task done by another

Let me admit it straight out, this is a pretty difficult topic to write about. In all my years of experience as a manager, trying to have a simple equation or factor for working out what happens when somebody prepares an estimate and somebody else has to do the actual development / coding for that work was not possible. There was no one size fits all for this kind of situation. In the previous post on this topic (Using a confidence level for estimates for later refinement), I put some initial thoughts on this subject. The idea was that estimates are prepared at the beginning of a cycle and can be different from the actual effort put in when the work happens on that features.
It could be argued about why estimates are needed to be prepared at the beginning of the cycle, but there can be many reasons for that. One of the biggest reasons was about wanting to have a good idea about the number of features that would be possible to be done in the given cycle. This is necessary for the team, and this is very important for the stakeholders and sponsors of the team. In a number of cases, the plan for the release will not be approved until there is an assurance that a Minimum Viable Product has not been planned. Given that the release of a product can have profound implications on the financial status of an organization, it can be very important to do planning about the number of features that can be fit into the release.
Doing this estimation also allows the team to do the required resource planning, and even though the number of resources may not change too much between releases, if there is a need to do a big bang release, then the team would want to know the number of extra resources that are required for this release. So, let us work with the assumption that the team needs to do the initial estimation for the features that are planned for the release.
Now, the biggest problem that occurs is that when the work for a release is being estimated, the people doing the estimation are the more senior developers in the team. Typically, the estimation exercise can only last for around 5-10% of the total time of the release, and it is really not possible to do the logical task of breaking down the features into detail deep enough that the estimate would be very accurate. So, a lesser number of people are drafted in to do this kind of work, and an equal assumption is that the estimation is primarily done by the person using their previous experience to determine the scope of work for the details of the feature and using this for the future.
But when it comes to doing the actual development work for the feature, you cannot have these senior people doing all the work. The work is shared among the team members and this is where discrepancies come in. You can have the senior person being very skilled in doing such work, but the person who is actually doing this work is not so skilled and you end up with more effort required for doing this work. So, whenever the work allocation is being done, there is a need to map the estimate with the person who did the estimate, and the person who is actually going to be doing the work. A skilled manager who knows both these people would be able to do this to a large extent and be pretty accurate in this. At the same time, the project manager should continue to track and compare the effort discrepancy mentioned by the engineering manager with the actual effort discrepancy.

What is Context Switch?

- The context switch refers to the process that involves storing and restoring of the context or the state of the process. 

- This makes it possible to resume the execution of the process from that same saved point in the future. 

- This is very important as it has enabled the various processes for sharing one CPU and therefore it represents one of the essential features of an operating system that is capable of multi – tasking. 

- It is the operating system and the processors which decide what will constitute the context. 

- One of the major characteristic of the context switches is that they are computationally very intensive.

- Most of the designing of the operating systems is concerned with the optimization of the use of these switches. 

- A finite amount of time is required for switching from one process to another one. 

- This time is spent in the administration of the process which includes saving and loading of the memory maps, registers etc. plus the various lists and tables are updated. 

- A context switch may mean either of the following:

Ø  A register context switch

Ø  A task context switch

Ø  A thread context switch

Ø  A process context switch

Potential Triggers for a Context Switch

There are three potential triggers for a context switch. A switch can be triggered in any of the three conditions:

1. Multi-tasking: 

- It is common that one process has to be switched out of the processor so as to execute another process. 

- This is done by the use of some scheduling scheme. 

- Here, if the process makes itself un-executable, then it can trigger this context switch. 

- The process can do this by waiting for synchronization or an I/O operation to finish. 

- On a multitasking system that uses pre-emptive scheduling, the processes that are still executable might be switched out by the scheduler. 

- A timer interrupt is employed by some of the preemptive schedulers to avoid process starving of the CPU time.

- This interrupt gets triggered when the time slice is exceeded by the process. - Furthermore, this interrupt makes sure that the scheduler will be able to gain control for switching.

2. Interrupt handling: 

- Modern architectures are driven by the interrupts. 

- This implies that the CPU can issue the request while continuing with some other execution and without waiting for the current read/ write operation to get over. 

- When the currently executing operation is over, the interrupt fires and presents the result to the CPU. 

- Interrupt handler is used for handling the interrupts. 

- The interrupts are handled by this program directly from the disk. 

- A part of the context is automatically switched by the hardware up on the occurrence of an interrupt. 

- This context is enough for the handling program to go back to the code that raised the interrupt.

- The additional context might be saved by the handler as per the details of both the software and hardware designs. 

- Usually, only a required small context’s part is changed so as to keep the amount of time required for handling as minimum as possible. 

- Kernel does not take part in scheduling a process that would handle the interrupts.

3. User and kernel mode switching: 

- A context switch is not required for making a transition between the kernel mode and the user mode in an operating system.

- A mode transition in itself cannot be considered to be a context switch. 

- But, it depends on the OS whether or not the context switch will take place. 

What is a Dispatcher?

A number of types of schedulers are available that suit the different needs of different operating systems. Presently, there are three categories of the schedulers:

1. Long-term schedulers
2. Medium-term schedulers
3. Short-term schedulers

Apart from the schedulers there is one more component involved in the scheduling process and is known as the dispatcher. 

- It is the dispatcher that gives a process power to control the CPU. 

- To which process this control is to be given is selected by the short-term scheduler. 

- This whole process involves the following three steps:

1. Switching the context
2. Turning on the user code
3. Making a jump to the exact location of the program from where it has to be restarted.

- Values taken from the program counter are analyzed by the dispatcher and accordingly it fetches instructions and feeds data in to the registers. 

- The dispatcher unlike the other system components needs to be very quick since it is invoked during all the switches that occur. 

- Whenever a context switch is invoked, the processor gets in to an idle state for a very small period of time. 

- Hence, it is required that the context switches that are not necessary might be avoided. 

- The dispatcher takes some time for stopping one process and start running the other one. 

- The dispatch latency is what we call this time.

- Scheduling and dispatch are complex processes and interrelation to each other. 

- These two are very much essential for the operation of the operating system. 

- Today, architectural extensions are available for the modern processors that provide a number of banks of registers.

- Swapping of these registers in hardware is possible and therefore a certain number of tasks are capable of retaining their full registers. 

- Whenever an interrupt triggers the dispatcher, it sends to it the full set of the registers belonging to the process that was being executed at the time of occurrence of the interrupt. 

- Here, the program counter is not considered. 

- Therefore, it is important that the dispatcher should be written carefully for storing the present states of the registers on being triggered. 

- In other words, we can say that for the dispatcher itself, there is no immediate context. 

- This saves it from the same problem. 

Process of Dispatcher

Below we try to describe in simple words what actually the process is.

1. The program presently having the context is executed by the processor. Things used by this program include stack base, flags, program counter, and registers and so on. There is a possible exception of the reserved register that is native to the operating system. The executing program does not have any knowledge regarding the dispatcher.
2. For dispatcher a timed interrupt is triggered. Here the program counter jumps to the address listed in the BIOS interrupt. This marks the beginning of the execution of the dispatch sub routine. The dispatcher then deals with the stacks and the registers etc. of the program that raised the interrupt.
3. Dispatcher like the other programs consists of some sets of instructions that operate up on the register of the current program. These instructions know everything of the previously executed programs. Out of these, the first few instructions are responsible for storing the state of the program.
4. Dispatcher next determines which program should be given the CPU next for executing. Now it deletes all the statistics of the previously executed state and fills in the details of the next process to be executed.
5. Dispatcher jumps to the address mentioned in the program counter and establishes a full context on the processor.

- Actually dispatcher does not really require registers since its only work is to write the current state of the CPU in to a memory location that has been predetermined. 

- It then loads in to the CPU another process from other predetermined location. 

Risk planning - Using a confidence level along with estimates so that these are refined later in the schedule

The normal cycle we would follow was for a 6 month period of software development. Every 6 months we would release the next version of our software, and towards that end, we had a list of features ready for the Product Manager to consider for prioritization and decide which features would make it in the next version of the software, and which would be taken up in future versions of the software. Once such a list was prepared, the next step was to get the Product Manager to spend time with the designer and break down the feature set into a slightly more detailed set, something like Use Cases. However, the level of detail that we could do in the time period that we had was of a level higher than Use Cases (the actual Use Cases would be generated only when work on the features was about to start).
Once this level of detail was generated, the next step was to get the senior engineering leads talking to the Product Manager and the designers to get some idea about the feature, look at some workflows and implementation, and then, start looking at how to estimate these. There are many methods of estimation, but in most cases we used the method called heuristics, which is a fancy word that we took to mean that these people knew how to do feature development, they had been doing it for quite some time, and as a result, they would be able to use their experience to determine the typical effort required for doing the feature.
Next, all the effort for the list of features was tabulated, and then assigned to the different members of the team while doing balancing, ensuring that everybody got a mix of interesting and boring work (wherever possible if there was exciting work, since that would help in terms of morale). There was some rationalization of the effort reported to take into account that some of the team members were more capable while others were not so capable. Finally the list of features would be generated to be presented to the stakeholders of the team and the organization.
However, once the team would start actually doing work on these features, then the actual effort would come into play. It was quite possible that the initial effort that was listed was the final effort once the team started implementation, but there was also a high chance that the effort would change once the team actually started implementation. There could be design issues that were not expected before actual implementation started, or there could be other setbacks that happened. It could be that the person doing the estimate had not done a correct estimate and this was clear when the team actually started the estimation.
This has an impact on risk planning. Part of the continuous effort to monitor the risk involved in the project is to determine the actual state of the project and also to determine whether the features that were expected to be done in the initial planning are on schedule or not. However, it should be part of the risk matrix to try and determine the level of inaccuracy present in these estimates (even though it can be pretty difficult) and to estimate the impact this could have on the feature schedule. It is critical that the Project / Program manager has been tracking the estimate accuracy of the features and is not majorly surprised if a feature is running late because of estimation issues.

What is a CPU Scheduler?

Scheduling is a very important concept when it comes to the multi-tasking operating systems. 

- It is the method via which the data flows, threads and processes are provided access to the shared resources of the computer system. 

- These resources include communications bandwidth, processor time, and memory and so on. 

- Scheduling is important as it helps in striking a balance the system processor and its resources effectively. 

- It helps in achieving the target QoS or quality of service. 

But what gave rise to scheduling? 

- Almost all the modern systems require to carry out multiple tasks i.e., multi-tasking and multiplexing as well which require a scheduling algorithm. 

- Multiplexing means transmission of the multiple data flows at the same time. - There are some other things also with which the scheduler is concerned. They are:

1. Throughput: It is the ratio of total number of processes executed to a given amount of time.
2. Latency: This factor can be sub – divided in to two namely response time and the turnaround time. Response time is the time taken from the submission of the process till its output is produced by the processor. The latter i.e., the turnaround time is the time period elapsed between the process submission and its completion.
3. Waiting/ fairness time: This is the equal CPU time given to each process or we can say that the time is allocated as per the priority of the processes. The time for which the processes wait in the ready queue is also counted in this.

- But in practical, conflicts may arise between these goals such as in case of latency versus throughput. 

- If such a case occurs, a suitable compromise has to be implemented by the scheduler. 

- The needs and the objectives of the user are used for deciding to who (of the above concerns) the preference is to be given. 

- In robotics or embedded systems i.e., in the real time environments, it becomes a duty of the scheduler for ensuring that all the processes meet their deadlines. 

- This is important for maintaining the stability of the system. 

- The mobile devices are given the scheduled tasks which are then managed by an administrative back end.

Types of CPU Schedulers

There are many types of CPU schedulers as discussed below:

1. Long-term Schedulers: 

- These schedulers facilitate the long term scheduling and are also known as the high level schedulers and the admission schedulers. 

- It is up to them to determine which processes and jobs are to be sent to the ready queue. 

- When the CPU makes an attempt for executing a program, the long term scheduler has the right to decide whether this program will be admitted to the currently executing set of processes. 

- Thus, it is dictated by this scheduler what processes are to be run and the extent of the concurrency has to be there.

- It also decides what amounts of processes have to be concurrently executed. 

- It also decides the handling of the split between the CPU intensive and I/O processes.  

2. Medium-term Schedulers: 

- The processes are temporarily removed from the main memory and placed up on the secondary memory by this scheduler. 

- This process is called “swapping in” and “swapping out”. 

- Usually this scheduler swaps out the following processes:

a)   processes that have been inactive since some time

b)   the processes that has raised a frequent page faulting

c)   processes having a low priority

d) processes that take up large memory chunks for releasing the main memory to other processes

- The scheduler later swaps in these processes whenever sufficient memory is available and if the processes are unblocked and not in waiting state.

3. Short-term Schedulers: 

It takes decision regarding the processes to be executed after clock interrupt. 

Trying to determine a risk index based on heuristics - would be a good start

Risk planning is a critical part of any project / program manager's job. Anytime during the course of a development cycle, the project may be exposed to a number of risks. If the team has not done as well a job of risk planning as it should have, they can land in a very unpleasant condition; and even if they do got help, the first question that anybody would fire at the manager would be about not properly anticipating these kind of problems and being ready for such problems as they occur.
So what can you do in terms of risk planning even before a project has started, and then continue doing through the course of a project ? There will be always be new risks or problems that will arise during the course of a project that have not happened previously or did not have the same gravity earlier, but there will always be risks that could have been anticipated in advance. And this is where a good project / program manager can excel, in terms of doing a good job at risk planning.
So what does this mean ? Well, the simplest case is if you are working on a new version of a product where there have been earlier versions. In such cases, if you have been around for previous versions, you typically have a good idea of what the risks are like and also know some ways of handling such risks. For example, you know the time period in which defects tend to peak, you know the time periods in which resourcing can become an issue, you know about components that you integrate which can cause the maximum damage to your schedule because they are either late or of bad quality. With all these, you can start to prepare such a list of problem areas.
Typically, risk planning is not something that comes of age in one version. What is required is to ensure that all problems and issues that you face in the previous version of the product have been recorded in some way, along with a note about the critical nature of the issue and the time period in which such an issue came out. With these as an input, an experience project / program manager can figure out which of these issues can become risks in the current versions of the product, and plan accordingly. If issues are not recorded, then you lose out some part of doing an effective risk planning for future versions of the product or project.
It is also necessary to find out more areas of risks that you would not know. There are risks that come to other people in the team, typically to the development or quality teams, which are known by their managers. For example, once we ran into a huge problem due to a different version of Visual Studio that we needed to upgrade to, and one of our components had a consistency problem with that version. This was something that our development managers knew would happen every other version, but we did not know from the project/program management side. It turned out to be a huge risk for the project, with the potential to need cutting out an important feature or add some more weeks to the schedule, and that did cause problems since it was not there in the list of risks, and yet was an old risk.