Prevention Of Energy Loss in Mobile Computing Using FLEXFETCH Scheme

8/14/2019 Prevention Of Energy Loss in Mobile Computing Using FLEXFETCH Scheme

1/73

Prevention Of Energy Loss in Mobile Computing Using FLEXFETCH Scheme

CHAPTER -1

INTRODUCTION

An appealing feature of pervasive computing is its ability to access

consistently maintained set of data and programs anywhere via network

connections. Relying on this feature, people can keep working on their data

without disruption when they move around.

In the application of pervasive computing, a commonly used

technique is data hoarding, where commonly used set of data are replicated

on users mobile computer, so that data can be accessed from the computers

local disk when the user is on travel or even disconnected, and the local data

can be kept consistent by a replication system .

When data are available both on the local disk and on the server via

wireless network, an intuitive choice would be to access the data from the

local disk to save communication cost.

However, this choice can be sub-optimal in terms of energy

consumption, which can be a major concern because mobile devices are

constrained by the limited lifetime of their batteries. The reason of the sub-

optimality is that the hard disk is energy inefficient if the disk is in the

standby state and only a small amount of data is accessed there.

1 Department Of Information Technology


2/73


1.1ENERGY SAVING MODES IN HARD DISK:

Typically, a hard disk has four power-consumption states:

Active,

Idle,

Standby,

Sleep.

1.1.1.Active State:

A disk carries out its reading or writing in its active state.

1.1.2.Idle State:

In the idle state disk platters keep spinning with no data transfer.

1.1.3.Standby State:

In the standby state the disk is spun down, disk electronics are

partially Unpowered, and disk heads are unloaded or parked.

1.1.4.Sleep State:

In the sleep state all the remaining electronics are powered off, and a

hard reset is needed to reactivate the disk.



3/73


To save energy, disk is spun down to the standby state if it has been

idle for a threshold period of time, and to service a request it has to be spun

up to the active state.

1.1.5.Busy Period:

We call the time period between the disk spin-up and its adjacent

spin-down a busy period.

1.1.6.Quiet Period:

The time period between the disk spin-down and its adjacent spin-up a

quiet period. Because of substantial energy consumption with disk state

changes, the quiet period must be sufficiently long to justify the energy cost

for the disk spin-down/up.

1.1.7.Break-even time:

The minimum length of quiet period to pay off the cost is referred to

as the break-even time.

That is, if a disk stays in the standby state for a period of time that is

less than the break-even time, it consumes more energy, rather than saves

energy, by spinning down the disk.

If data requests are always first attempted at the hard disk, quiet

periods can be broken into pieces that are shorter than the break-even time

and render the spin-down energy saving efforts fruitless, or even harmful.



4/73


In addition, it can take a delay of about one second or more for a

spun-down laptop disk to service the first byte of a request.

1.2.ENERGY SAVING MODES IN WIRELESS NETWORK:

The 802.11wireless network interface card used in a mobile computer

has power consumption comparable to that for the hard disk. Compared with

disks in terms of the energy saving model, a wireless card has its unique

characteristics:

There are two energy modes: continuously-aware mode (CAM)

power-saving mode (PSM).

1.2.1. Continuously-Aware Mode:

In the CAM mode, the wireless card keeps active with high powerconsumption.

1.2.2. Power Saving Mode:

In the PSM mode, the wireless card turns radio off and periodically

wakes up to check with access point.

Data transmission can be carried out in both CAM and PSM, but with

different latencies and bandwidths. While there is also time and energy cost

for the mode changes, the cost is smaller than that for the hard disk.



5/73


1.3. COMPARISON BETWEEN THE HARD DISK AND

THE WIRELESS NETWORK:

For example, spinning down a Hitachi DK23DA hard disk to the

standby state needs 2.3 seconds and 2.94 joules energy. In contrast, a Cisco

Aironet 350 wireless card takes only 0.41 seconds to switch from CAM

mode to PSM mode with an energy cost of only 0.53 joules.

This characteristic suggests that wireless connection can be a good

choice for data access when the hard disk is not ready (in the standby mode)

or is not worth being spun up to service only a small amount of data.

Wireless network bandwidth is usually lower than disk bandwidth.

In addition, wireless network bandwidth may be changing with the

variation of reception strength when user changes the location of his

computer. This characteristic suggests that the network is preferred only

when a small amount of data is requested and this amount is related to the

current network bandwidth.



6/73


CHAPTER -2

LITERATURE SURVEY:

2.1.Hitachi-DK23DA HARD DISK DRIVE:

A simulator that is driven by real-life applications execution traces to

evaluate the performance of FlexFetch. It simulates the management of two

storage devices (hard disk and wireless interface card) and the buffer cache

in the memory. The simulator emulates the policies used for Linux buffer

cache management, including the 2Q-like page replacement algorithm, the

two-window read ahead policy that prefetches up to 32 pages, the C-SCAN

I/O request scheduling mechanism, and the asynchronous write-back

scheme. We also simulate the policies adopted in the Linux laptop mode,

such as eager writing back dirty blocks to active disks and delaying write-

back to disks in the standby mode.

The disk simulated in our experiment is the Hitachi- DK23DA hard

disk. It has a 30GB capacity, 4200 RPM, and 35MB/second peak bandwidth.

Its average seek time is 13ms, and its average rotation time is 7ms. Its

energy- related parameters are listed in Table 2.1. The timeout threshold for

disk spin-down is set as 20 seconds, the default value used in the Linux

laptop mode.



7/73


Figure 2.1 The Energy consumption parameters for the DK23DA

Hard Disk Drive.

2.2. CISCO AIRONET 350 WIRELESS CARD:

The simulated wireless network interface card (WNIC) is the Cisco

Aironet350 with a bandwidth of 11Mbps. The card adopts an adaptive

dynamic power management mechanism. It switches to the PSM mode from

the CAM mode when WNIC has been idle for more than 800msec, and it

switches back to the CAM mode if more than one packet is ready on the

access point. Its power consumption parameters are shown in Table 2.2.

In addition to FlexFetch, we also simulated the policy adopted in

BlueFS as it shares the same goal with FlexFetch. Also, we compare

FlexFetch with the policies where only disk or WNIC is used, respectively.

In the experiments about FlexFetch and BlueFS, we set maximum tolerable

performance loss rate as 25%.



8/73


Figure 2.2 The Energy Consumption Parameters for the Cisco Aironet

350 wireless card.

The minimal size to form an evaluation stage is set as 40 seconds. In

experiments, we assume that data sets of workloads are available on both

local hard disk and remote server and synced, except as stated otherwise.

Compared with accessing local hard disk, the performance and energy

cost of accessing a remote storage via wireless card are sensitive to the

networking environment. For example, the bandwidth of WNIC highly relies

on the radio quality, which could be affected by many factors, such as

distance and physical geometry.

The 802.11b standard supports four bandwidths: 1Mbps, 2Mbps,

5.5Mbps, and 11Mbps, depending on the quality of radio signals. Moreover,

the latency for accessing remote storage via WNIC is not constant, as it maybe affected by many factors, such as server load and network congestion.

Thus, accessing data via WNIC may experience significant change of

latency and bandwidth, while accessing local hard disk has a constant

performance.



9/73


2.3.TRACES COLLECTION:

Figure 2.3 Trace Description.

We modified the strace utility in Linux to collect traces to drive our

simulator. The modified strace tool can intercept system calls related to file

operations, such as open (), close (), read (), write (), lseek (), etc. For each

system call, we collect the following information: pid, file descriptor, inode

number, offset, size, type, timestamp, and duration.

The blocks of the traced files are sequentially mapped to the local hard

disk with a small random distance between files to simulate a real layout of

files on the disk. We collected traces of six representative applications in a

mobile computing environment, as listed in Table2.3.



10/73


2.4.EXAMPLE SCENARIOS:

2.4.1. A Programming Scenario grep and make:

This workload simulates a typical programming scenario, where a

kernel programmer first searches the Linux source code using grep and then

builds a kernel binary using make.

Figure 2.4.1 Grep+ Make : Energy Consumption with various WNIC

Bandwidth & Latency.

Figure 2.4.1(a) shows the energy consumption with various WNIC

latencies. With a zero latency to access the remote storage viaWNIC, Disk-

only consumes 1743J energy,while WNIC-only requires 1634J. This is

because of expensive head positioning operation in the hard disk.



11/73


In this work load, make requests a large number of small files, where

each request can incur a substantial latency and energy cost on the disk. So

WNIC with a low latency is more cost effective than the hard disk. BlueFS

consumes 2179J energy. In contrast FlexFetch consumes only 1522J, which

is even less than that for WNIC-only.

The difference of energy consumption between BlueFS and FlexFetch

is due to the mixed access patterns exhibited in the workload. In this

experiment, a large number of small files are first accessed in a very short

period (grep), and then the Linux kernel is built (make), which takes several

minutes. FlexFetch identifies different access patterns to select energy-

efficient devices accordingly.

Specifically, at the beginning FlexFetch spins up the hard disk to

service the data set of grep,as the hard disk can complete the whole

operation in a few seconds with small energy consumption.

The data set of make is then mainly serviced by the WNIC, which is

energy efficient for non-bursty workloads. BlueFS, however, has no

knowledge of future accesses and solely relies on the recent history of data

accesses and current storage device status to make a choice, which makes it

lack a long-term view of energy consumption caused by different workload

access patterns.

As a result, it keeps switching between the hard disk and the remote

storage, which incurs significant energy consumption for both devices. With

the increase of WNIC latency, the energy consumption of WNIC-only

quickly increases and exceeds that of Disk-only.



12/73


Meanwhile, BlueFS reduces its energy consumption by dispatching

most of the requests to the hard disk, which now has not only comparable

latency but also much higher bandwidth (35MB/s) than the WNIC (11Mb/s).

Similarly, FlexFetch responds to the change of energy efficiency

caused by the increased WNIC latency by issuing more requests to the hard

disk, which makes its curve increasingly close to the curve of Disk-only.

Figure2.4.1(b) shows the energy consumptions with the variation of

the WNIC bandwidth. WNIC-only is very sensitive to the bandwidth, as the

I/O service time is highly dependent on the bandwidth.

FlexFetch benefits from the increased WNIC bandwidth, which gives

FlexFetch more flexibility to choose between the two devices and useWNIC

to escape from the high cost involved in small file access on disk when it

deems profitable. BlueFS is not sensitive to the change of bandwidth, as it

selects device based on the current status of devices and accumulated

opportunity costs.

2.4.2.A Media Streaming Scenario: mplayer

In this workload, a user uses mplayer to play amovie, which

continuously accesses large movie files. As shown in Figure 2.4.2(a), the

energy consumption for FlexFetch is almost the same as that for WNIC-

only. Mplayer continuously accesses data, but only a small amount of data at

a time, which makes it energy inefficient to use the hard disk. Using the

profile of mplayer,



13/73


FlexFetch can recognize the fact by estimating and comparing energy

consumptions for the WNIC and the disk. BlueFS, however, can only see a

recent history. BlueFS first issues requests to WNIC, as spinning up the hard

disk incurs substantial energy overhead.

a) Energy consumption with various WNIC bandwidth

b) Energy consumption with various WNIC bandwidth

Figure 2.4.2 mplayer: Energy Consumption with various WNIC

Bandwidth & Latency.



14/73


However, when it sees more requests, it issues a ghost-hint to the

hard disk with a hope that servicing the following requests via an active disk

could reduce energy consumption.

Figure 2.4.2(b) demonstrates that FlexFetch can adaptively select a

proper device. With a large WNIC bandwidth, say 5.5Mbps, FlexFetch

accesses data via WNIC and achieves an energy consumption similar to that

of WNIC-only.For WNIC with a bandwidth lower than 2Mbps, FlexFetch

switches to the local hard disk, which is more efficient than a low-bandwidth

WNIC, and consumes the amount of energy that is comparable to that for

Disk-only andupto45% less than that for WNIC-only.



15/73


CHAPTER -3

SYSTEM ANALYSIS

3.1.EXISTING SYSTEM:

BLUE FILE SYSTEM (BlueFS):

The Blue File System (BlueFS), a distributed le system for mobile

computing that addresses the new opportunities and challenges created by

the evolution of mobile storage. Rather than embed static assumptions about

the performance and availability of storage devices, BlueFS has a flexible

cache hierarchy that adaptively decides when and where to access data based

upon the performance and energy characteristics of each available device.

BlueFS's flexible cache hierarchy has three significant benefits: it

extends battery lifetime through energy-efficient data access, it lets

BlueFS efficiently support portable storage, and it improves performance by

leveraging the unique characteristics of heterogeneous storage devices.

BlueFS uses a read from any, write to many strategy. A kernel module

redirects file system calls to a user-level daemon, called Wolverine, that

decides when and where to access data. For calls that read data, Wolverine

orders attached devices by the anticipated performance and energy cost of

fetching data, then attempts to read information from the least costly device.



16/73


This lets BlueFS adapt when portable storage devices are inserted or

removed,when the dynamic power management status of a device changes,

or when wireless network conditions fluctuate. For calls that write data,

Wolverine asynchronously replicates modifications to all devices attached to

a mobile computer. Wolverine aggregates modifications in per-device write

queues that are periodically flushed to storage devices.

BlueFS reduces file system energy usage by up to 55% and interactive

delay by up to 76% compared to the Coda distributed file system. BlueFS

also provides up to 3 times faster access to data replicated on portable

storage. Further, BlueFS masks the performance impact of disk power

management and leverages new types of storage technology such as flash

memory to save power and improve performance.

BlueFS distinguishes itself from prior distributed file systems by

using an adaptive cache hierarchy to reduce energy usage and efficiently

integrate portable storage.

BlueFS further reduces client energy usage by dynamically

monitoring device power states and fetching data from the device that will

use the least energy. Finally, BlueFS proactively triggers power mode

transitions that lead to improved performance and energy savings.

Previous file systems differ substantially in their choice of cache

hierarchy. NFS uses only the kernel page cache and the file server. AFS

adds a single local disk cache file however, it always tries to read data from

the disk before going to the server.



17/73


18/73


19/73


Using other file systems, fetching the first block incurs a large delay

as the disk spins up (800ms for the Hitachi microdrive and one second for

the IBM T20 laptop drive). In contrast, BlueFS hides this delay by fetching

blocks over the network.

For each block that it fetches from the network, BlueFS issues a ghost

hint that discloses the opportunity cost of the disk being in standby. While

the disk spins up in response to the ghost hints, BlueFS continues to fetch

blocks from the server. After the transition completes, BlueFS fetches

remaining blocks from disk. Eventually, the network device enters a power-

saving mode since it is now idle. No ghost hints are issued to the network

device because the disk offers both the lowest current and ideal cost.

3.1.3.Energy Efficiency:

The energy-efficiency of BlueFS by running the Purcell trace on the

iPAQ handheld using the microdrive as local storage. In this, it is important

to correctly capture the interaction of file system activity and device power

management by replicating the inter arrival times of file system operations.

Thus, between each request, replay pauses for the amount of time recorded

in the original trace. Since running the entire trace would take too long using

this methodology, we replay only the first 10,000 operations this

corresponds to 42:36 minutes of activity.

In the below Figure, all files accessed by the trace are initially cached

on the microdrive. The left graph compares the interactive delay added to

trace replay by BlueFS and Coda this shows the time that the user waits for



20/73


file operations to complete. The right graph shows the amount of additional

energy used by the iPAQ to execute file system operations (i.e. it excludes

energy expended during think time). Coda uses default powermanagement

(PSM for the network and the microdrive's ABLE power manager).

Figure 3.3 Interactive Delays and Energy usage.

With 0ms latency, BlueFS reduces interactive delay by 35% and file

system energy usage by 31%. Since all files are on disk, Coda only uses the

network to asynchronously reintegrate modifications to the server. BlueFS,

however, achieves substantial performance and energy benet by fetching

small objects from the server and by using the network when the disk is in

standby. With 30ms network latency, the microdrive always offers better

performance than the server when it is active. In the absence of power

management, Coda's static hierarchy would always be correct.



21/73


However, because BlueFS hides performance delays caused by the

drive entering standby mode, it reduces interactive delay by 8% compared to

Coda.

3.1.4.Limitations of BlueFS:

There are several limitations in the BLUE FILE SYSTEM which are listed

as below:

Tracking recently received requests can only tell which device shouldhave been used for the optimal energy consumption, but cannot

confidently predict how much data will be accessed in the future.

This scheme cannot predict temporal distribution of files to be

requested, includingthe distribution of think times between data

requests, which is important because it directly affects energy and

time of servicing the requests. As an example, a sequence of

intermittent requests for files are preferred to be serviced through

network because of its low utilization of disk bandwidth and high

energy consumption for disk to stay idle waiting for the next request

to arrive.

Without recording and analyzing file access history, BlueFS has to

reactively make decisions by evaluating opportunity cost, or the time

and energy wasted by using the current device (e.g., network) instead

of activating the other device (e.g., disk).



22/73


23/73


CHAPTER -4

SYSTEM DESIGN:

4.1.BLOCK DIAGRAM:

Figure 4.1. Block Diagram of FLEXFETCH



24/73


4.2.DESCRIPTION:

The Block diagram of the FlexFetch scheme consists of three layers:

Input unit.

Processing unit.

Output unit.

INPUT UNIT:

It fetches the input from the user. It may be either be an write (WR)

instruction or read (RD) instruction.

PROCESSING UNIT:

All the functions are carried out in this unit such as

Profiling programs execution.

Adaptive selection of Data source.

Re-evaluating the profile.

OUTPUT UNIT:

It produces the output to the user. Based upon the operations

performed in the processing unit the output is displayed.



25/73


4.3. UML DIAGRAMS:

4.3.1.Use Case Diagram:

A use case is a set of set of scenario that describing an interaction

between a user and a system. The two main components of the use case

diagram are use cases and actors.

In this diagram, there are three use cases such as

Profiling the program execution.

Adaptive selection of the data source.


The actors involved here are

User

System.



26/73


4.3.2.Class Diagram:

Class diagrams are some of the most difficult UML diagrams to draw.

This will give a very high level overview of the process. They are composed

of three things: a name, attributes, and operations.

Profile, Adaptation, Re-evaluation is the names of the classes. Merge

sequence data, Divide program, Local disk, New profile are some of the

attributes. Profiling, Calculation, Updation, assembling are some of the

operations performed.



27/73


4.3.3.Activity Diagram:

4.3.3. a) Profiling:

Activity diagram describe the workflow behavior of the system. The

diagrams describe the state of activities by showing the sequence of

activities. The figures shows the various activities performed in profiling the

program execution such as Dividing program into multiple sequence,

multiple sequence data are merged together, etc.,



28/73


4.3.3.b) Adaptation:

There are three conditions in selecting the data source such as

If Tdisk


29/73


4.3.3.c)Re-evaluation:

The last step of activity performed in the operation is profile updation.

That is the re-evaluation of the new profile in comparison with the old

profile. Determining whether the initial decision is still valid, we need to

compare the (partial) profile that is being generated with the old profile.



30/73


4.3.4.Sequence Diagram:

This diagram demonstrates the behavior of objects in a use case by

describing the objects and the messages they pass.



31/73


4.3.5. Collaberation Diagram:

These diagram shows the relationship between objects and the order

of messages passed by them. The objects are listed as icons and arrows

indicate the messages being passed between them. The numbers next to the

messages are called the sequence numbers.



32/73


5.SYSTEM IMPLEMENTATION:

5.1. DATA FLOW DIAGRAM:



33/73


5.2. DESCRIPTION:

The first step is to get the input from the user. Then we have to track

the RD/WR system calls and monitor the system modes. There are two types

of system modes.

Active mode and

Not in active mode.

If the system is in Active mode then leave it as it is (i.e., local disk)

otherwise choose the wireless network.

In the FLEXFETCH scheme we have to first profile the program

execution. Then this profiled program is allowed to enter the evaluation

stage. Based upon the profiling the data source is selected. It may be either

the local disk or it may be the wireless network.

The necessary operations are performed and the datas are stored in

the respective storage devices. The final step is to Re-evaluate the existing

profile with the incoming new program. The necessary modifications are

done in the Re-evaluating stage.

The output the process is either we have the local disk or the wireless

network.



34/73


5.3.MODULES USED:

Profiling programs execution.

Adaptive selection of Data source.


5.4.MODULES EXPLANATION:

5.4.1.Profiling Programs Execution:

The purpose of the profiling is to obtain the execution information that

can be used to estimate execution times and energy costs with different I/O

sources. A program execution alternates between I/O requests and

computations. A programs life time consists of I/O times and compute

times (or think times). The lengths of think times, as well as their

contribution to the entire programs execution time and energy cost are not

subject to I/O source. So we focus on profiling I/O behaviors in a programs

execution.

In the FlexFetch scheme, we monitor and track file read/write system

calls made by a process, which provides file path-name, offset, and size ofeach request. If running a program involves only one process, we can

associate all the file accesses from the process with the program. If there are

multiple processes created when a programis running (such as make, which

could generate multiple gcc processes concurrently to build executable), we



35/73


leverage process group structure in Linux to associate all the file accesses

requested by processes belonging to the same group with the program.

Though profiling I/O system calls can precisely characterize

applications behavior, the profile cannot be directly used to estimate request

service time in real systems. This is because operating systems usually

conduct many optimizations on the I/O path, and the requests are not

necessarily serviced in their arrival order. For example, most OS kernels

prefetch sequential data in files, which helps translate interleaved accesses

into multiple sequential streams . Also, I/O schedulers attempt to re-arrange

pending requests and merge requests for contiguous data blocks to achieve

high throughput.

To estimate the service time of I/O requests, we adopt the concept of

I/O burst, in which

we assume sequential data in a file that are requested in the

same I/O burst are accessed in a devices peak bandwidth, even

though these data may be requested by multiple system calls

and these system calls may be interleaved with other system

calls asking for data in other files. This is the expected

consequence of I/O scheduling and I/O prefetching.

The (think) time gap between any two adjacent read/write

system calls in an I/O burst can be masked by the prefetching

I/O time or can be considered as negligible relative to the I/O

cost.

So we do not count small think times in an I/O burst into the total

execution time.



36/73


To this end, we define an I/O burst as a sequence of read/write system

calls where the think time is less than the I/O burst threshold. In our

experiment we set the threshold as the disk access time, i.e., the average time

to receive the first byte of a random request on disk. We conservatively

assume that when a think time exceeds the threshold, the time cannot be

masked or neglected, so the following access belongs to a new I/O burst.

Multiple requests that sequentially access the same file are merged into one

request.

Figure 5.4.1.a. Home Form

The home form shows all the forms which we are using the project.



37/73


Figure 5.4.1.b. Input Read Form

The Input read form is used to get the user Inputs. The user has to

give the input for the Request, Response, Request Time, Response Time.

Then it automatically calculates the Think time. If the Think Time is less

than 100, then we can go for profiling.



38/73


Figure 5.4.1.c. Profiling Program Execution Form

The user has to give the input for the Request, Response, Request

Time, Response Time. Then it automatically calculates the Think time. If the

Think Time is less than 50, then we can go for sequencing.



39/73


Figure 5.4.1.d. Sequence Data Form

The user has to give the input for the Request, Response, Request

Time, Response Time. Then it automatically calculates the Think time. If the

Think Time is less than 30, then the Input read becomes disable.

5.4.2.Adaptive Selection of Data Source:

By monitoring execution of a program, we obtain its profile includinga series of I/O bursts, and think times between these I/O bursts. To

characterize the behaviors of a long running program in an appropriate

granularity, we collect continuous I/O bursts, including think times between

them, whose length just exceeds a pre-determined threshold, into an



40/73


evaluation stage. Profile-based decision about data source can be made for

each stage, which allows the profile accuracy and decision correctness to be

evaluated in a timely manner and necessary adjustments can be made

accordingly. When we have the profile and the program is to enter its first

evaluation stage, we estimate the execution times and energy costs for the

stage assuming disk or network is used, respectively, to determine I/O data

source, using the profile that has been recorded for the program.

In order to estimate execution times and energy costs for servicing I/O

requests on various data sources, we need to calculate the length of period of

time when a device stays at each power mode. To this end, we maintain an

on-line simulator for each device to emulate their power saving policies.

Such simulation causes minimal overhead, since only a small amount of

computation is needed.

According to the power saving models if the idle period between two

consecutive I/O requests is larger than a time-out threshold, the device

switches from a high-power mode (the active/idle mode for the disk and the

CAM mode for the wireless network card) to a low-power mode (the

standby mode for the disk and the PSM mode for the wireless network card).

For each request, its service time includes a latency and a transfer time.

The disk latency is calculated using the average seek and rotation

time, and an average network latency is used for the network card. The

transfer time can be derived from the request size and device bandwidth. If a

power mode transition is involved in servicing a request, the associated

energy and time overhead is counted in the estimation. Notice that the mode-



41/73


switch threshold as well as its time and energy cost for the network card are

smaller than those for the disk, which makes wireless network a desired

alternative data source in some I/O access patterns.

In this way, we can estimate the execution time Tdisk and the energy

consumption Edisk for accessing data on the disk, and the execution time

Tnetwork and energy consumption Enetwork for servicing requests from a

remote storage server via network. FlexFetch optimizes energy usage for I/O

operations by treating equally the I/O energy cost and performance and

obeying a user-specified maximum tolerable I/O performance loss rate. A

threshold loss rate of m% means that FlexFetch will not switch to the other

I/O data source by saving x% energy consumption but extending I/O

execution time by n% if xm. Asking for user to provide this kind of

preference, such as loss rate, is common in todays battery-powered system,

such as the Power manager in the IBM ThinkPad laptop. Using the

estimated energy cost, execution time, and the user-specified performance

loss rate, we summarize the rules determining I/O data source for an

evaluation stage as follows:

If Tdisk


42/73


Figure 5.4.2. Adaptive Selection Form.

The Adaptive selection is based upon the Execution time, systemmodes, bandwidth, data size, data storage. Each of these will have separate

forms.

5.4.3.Re-evaluating the Profile:

While an I/O data source is used in an evaluation stage according to

the decision made based on the old profile, a new profile is being generated

for the current execution. To determine whether the initial decision is still

valid, we need to compare the (partial) profile that is being generated with

the old profile.



43/73


An intuitive way of the comparison is to try to match, between these

two profiles, the files requested in each I/O burst and the length of think time

between two adjacent I/O bursts, and then use the result to decide if the

current data source should be kept. However, an exact match of the two

profiles is not directly relevant to the validity of the decision. From one run

to another run of a program, the data it processes might be different, and the

distribution of data requests and think times might be changing, more or

less. However, this may not necessarily invalidate the decision made by

using the rule.

Our method is to replace the corresponding portion of the old profile

with the current partial profile and use the assembled profile to run the rule.

Specifically, we monitor the amount of data that have been requested in the

current run. Whenever the amount just exceeds the amount of data requested

in the first N I/O bursts, we use the new profile for this run to replace the N

I/O bursts in the old profile and re-evaluate the rule using the assembled

profile to decide if the data source should be changed.

In this way, in the current run of a program, its initial behaviors are

examined in a bigger history picture, and as time goes on, the current

behaviors will have more weight in the re-evaluation. Finally, the new

profile will be recorded to replace the old profile for future use at the end of

this run.

To further reduce the interference from invalid profile, we conduct a

periodical evaluation of the effectiveness of a profile-based decision at the

end of each evaluation stage.



44/73


CHAPTER -6

TESTING TECHNIQUES / TESTING STRATEGIES

6.1. TESTING TECHNIQUES:

Testing is a process of executing a program with the intent of finding

an error. A good test case is one that has a high probability of finding an as-

yet-undiscovered error. A successful test is one that uncovers an as-yet-

undiscovered error. System testing is the stage of implementation, which is

aimed at ensuring that the system works accurately and efficiently as

expected before live operation commences.

It verifies that the whole set of programs hang together. System

testing requires a test consists of several key activities and steps for run

program, string, system and is important in adopting a successful new

system. This is the last chance to detect and correct errors before the system

is installed for user acceptance testing.

The software testing process commences once the program is created

and the documentation and related data structures are designed. Software

testing is essential for correcting errors. Otherwise the program or the

project is not said to be complete.



45/73


Software testing is the critical element of the software quality

assurance and represents the ultimate the review of specification design and

coding. A successful test is one that uncovers an undiscovered error. Any

engineering product can be tested in one of the two ways:

6.1.1.White Box Testing:

This testing is also called as Glass box testing. In the testing, by

knowing the specific functions that a product has been design to perform test

can be conducted that demonstrates each function is fully operational at thesame time searching for errors in each functions. It is a test case design

method that uses the control structure of the procedural design to derive test

cases. Basis path testing is a white box testing.

Basis path testing:

Flow graph notation

Cyclometric complexity

Deriving test cases

Graph matrices Control

6.1.2.Black Box Testing:

In this testing by knowing the internal operation of a product, test can

be conducted to ensure that all gears mesh, that is the internal operation

performs according to specification and all internal components have been



46/73


adequately exercised. It fundamentally focuses on the functional

requirements of the software.

The steps involved in black box test case design are:

Graph based testing methods

Equivalence partitioning

Boundary value analysis

Comparison testing.

6.1.3.System Testing:

Testing is performed to identify errors. It is used for quality assurance.

Testing is an integral part of the entire development and maintenance

process. The goal of the testing during phase is to verify that the

specification has been accurately and completely in corporated into the

design, as well as to ensure the correctness of the design itself. For examplethe design must not have any logic faults in the design is detected before

coding commences, otherwise the cost of fixing the faults will be

considerably higher as reflected. Detection of design faults can be achieved

by means of inspection as well as walkthrough.

Testing is one of the important steps in the software development phase.

Testing checks for the errors, as a whole of the project testing involves the

following cases:

Static analysis is used to investigate the structural properties of the

source code.



47/73


48/73


Execute all loops at their boundaries and within their operational

bounds.

Exercise internal data structures to assure their validity.

Checking attributes for their correctness.

Handling end of file condition, I/O errors, buffer problems and textual

errors in output information.

6.2. SOFTWARE TESTING STRATEGIES:

A software testing strategy provides a road map for the software

developer. Testing is a set activity that can be planned in advance and

conducted systematically. For this reason a template for software testing a

set of steps into which we can place specific test case design methods should

be strategy should have the following characteristics:

Testing begins at the module level and works outward toward theintegration of the entire computer based system.

Different testing techniques are appropriate at different points in time.

The developer of the software and an independent test group conducts

testing.

Testing and Debugging are different activities but debugging must be

accommodated in any testing strategy.



49/73


50/73


requirement. After validation test has been conducted, one of two conditions

exists.

The function or performance characteristics confirm to specifications

and are accepted.

A validation from specification is uncovered and a deficiency created.

Deviation or errors discovered at this step in this project is corrected

prior to the completion of the project with the help of the user by negotiating

to establish a method for resolving deficiencies. Thus the proposed system

under consideration has been tested by using validation testing and found tobe working satisfactorily. Though there were deficiencies in the system they

were not catastrophic.



51/73


CHAPTER -7

CONCLUSION:

Energy consumption remains a pressing issue in mobile computing,

where on-demand data could be available in both local hard disk and remote

storage via wireless network. In this paper, we propose an effective power-

saving scheme, FlexFetch, to save energy by adaptively selecting the most

cost-efficient data source for various workloads. By considering both I/O

devices characteristics and run-time dynamics, FlexFetch estimates and

compares energy consumption of various data sources and redirects I/O

requests to the least costly data source.

Our experiments based on trace-driven simulations show that

FlexFetch can achieve significant energy saving, compared to existing

energy-saving schemes that use the local disk only or that select data source

solely based on recently serviced requests.



52/73


53/73


CHAPTER 9

APPENDICES

9.1 SAMPLE CODES:

HOME FORM:

namespace FlexFetch

{

partialclassHome

{

///

/// Required designer variable.

///

private System.ComponentModel.IContainercomponents = null;

///

/// Clean up any resources being used.

///

///true if managed resources should be

disposed; otherwise, false.

protectedoverridevoid Dispose(bool disposing){

if(disposing && (components != null))

{

components.Dispose();



54/73


}

base.Dispose(disposing);

}

#region Windows Form Designer generated code

///

/// Required method for Designer support - do not modify

/// the contents of this method with the code editor.

///

privatevoid InitializeComponent()

{

this.label1 = new System.Windows.Forms.Label();

this.panel1 = new System.Windows.Forms.Panel();

this.BtnEnd = new System.Windows.Forms.Button();

this.BtnFileHistory = new System.Windows.Forms.Button();

this.BtnProfileUpdation = new System.Windows.Forms.Button();

this.BtnAdaptiveSel = new System.Windows.Forms.Button();

this.BtnProfile = new System.Windows.Forms.Button();

this.Btnread = new System.Windows.Forms.Button();

this.panel1.SuspendLayout();

this.SuspendLayout();

//

// label1

//

this.label1.AutoSize = true;



55/73


56/73


this.BtnEnd.Size = new System.Drawing.Size(177, 23);

this.BtnEnd.TabIndex = 13;

this.BtnEnd.Text = "End Application";

this.BtnEnd.UseVisualStyleBackColor = true;

this.BtnEnd.Click += new System.EventHandler(this.BtnEnd_Click);

//

// BtnFileHistory

//

this.BtnFileHistory.Location = new System.Drawing.Point(108,

166);

this.BtnFileHistory.Name = "BtnFileHistory";

this.BtnFileHistory.Size = new System.Drawing.Size(177, 23);

this.BtnFileHistory.TabIndex = 11;

this.BtnFileHistory.Text = "Show File History";

this.BtnFileHistory.UseVisualStyleBackColor = true;

this.BtnFileHistory.Click += new

System.EventHandler(this.BtnFileHistory_Click);

//

// BtnProfileUpdation

//

this.BtnProfileUpdation.Location = new System.Drawing.Point(108,

137);

this.BtnProfileUpdation.Name = "BtnProfileUpdation";

this.BtnProfileUpdation.Size = new System.Drawing.Size(177, 23);

this.BtnProfileUpdation.TabIndex = 10;

this.BtnProfileUpdation.Text = "Profile Updation";

this.BtnProfileUpdation.UseVisualStyleBackColor = true;



57/73


this.BtnProfileUpdation.Click += new

System.EventHandler(this.BtnProfileUpdation_Click);

//

// BtnAdaptiveSel

//

this.BtnAdaptiveSel.Location = new System.Drawing.Point(108,

108);

this.BtnAdaptiveSel.Name = "BtnAdaptiveSel";

this.BtnAdaptiveSel.Size = new System.Drawing.Size(177, 23);

this.BtnAdaptiveSel.TabIndex = 9;

this.BtnAdaptiveSel.Text = "DataSource AdaptiveSelection";

this.BtnAdaptiveSel.UseVisualStyleBackColor = true;

this.BtnAdaptiveSel.Click += new

System.EventHandler(this.BtnAdaptiveSel_Click);

//

// BtnProfile

//

this.BtnProfile.Location = new System.Drawing.Point(108, 79);

this.BtnProfile.Name = "BtnProfile";

this.BtnProfile.Size = new System.Drawing.Size(177, 23);

this.BtnProfile.TabIndex = 8;

this.BtnProfile.Text = "Profiling Program Execution";

this.BtnProfile.UseVisualStyleBackColor = true;

this.BtnProfile.Click += new

System.EventHandler(this.BtnProfile_Click);

//

// Btnread



58/73


//

this.Btnread.Location = new System.Drawing.Point(108, 50);

this.Btnread.Name = "Btnread";

this.Btnread.Size = new System.Drawing.Size(177, 23);

this.Btnread.TabIndex = 7;

this.Btnread.Text = "Input Read";

this.Btnread.UseVisualStyleBackColor = true;

this.Btnread.Click += new

System.EventHandler(this.Btnread_Click);

//

// Home

//

this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);

this.AutoScaleMode =

System.Windows.Forms.AutoScaleMode.Font;

this.ClientSize = new System.Drawing.Size(695, 419);

this.Controls.Add(this.panel1);

this.Controls.Add(this.label1);

this.Name = "Home";

this.Text = "Home";

this.panel1.ResumeLayout(false);

this.ResumeLayout(false);

this.PerformLayout();

}

#endregion



59/73


private System.Windows.Forms.Label label1;

private System.Windows.Forms.Panel panel1;

private System.Windows.Forms.Button BtnFileHistory;

private System.Windows.Forms.Button BtnProfileUpdation;

private System.Windows.Forms.Button BtnAdaptiveSel;

private System.Windows.Forms.Button BtnProfile;

private System.Windows.Forms.Button Btnread;

private System.Windows.Forms.Button BtnEnd;

}

}



60/73


9.2 SOFTWARE DETAILS:

9.2.1 DOTNET Framework:

Microsoft .NET is a set of software technologies for connecting

information, people, devices and systems. This generation of technology is

based upon Web services ie., Small building block applications that can

connect to each other as well as to other, larger applications over the

internet.

The .NET framework is an environment for building, deploying and

running web services and other applications. The .NET framework version

1.1 extends the .NET framework version 1.0 with new features,

improvement to existing features, and enhancements to the documentation.

The .NET framework is made up of four parts like

1. Common Language Runtime.2. Set of class Libraries.

3. Set of Programming Langauges.

4. ASP .NET Environment.

The .NET framework was designed with three goals in mind. First it

was intended to make windows applications much more reliable, while also

providing an application with a greater degree of security. Second, it was

intended to simplify the development of the web applications and services

that not only work in the traditional sense, but no mobile devices as well.



61/73


62/73


The .NET architecture as follows:

It is a set of common services, which can be used for number of object

languages.

These services are executed in the form of intermediate code that is

independent of the underlying architecture.

They operate in a runtime (CLR) which manages resources and

monitor application execution.

9.2.4 Introduction to C#:

C# is the new language introduced in the .NET framework, is derived

from C++ and it is first component oriented language in the C/C++ family.

Everything is an object in the CSharp. C# is a modern, object oriented, type-

safe language.

C# is provided as a part of Microsoft Visual Studio .NET.C# is an

object oriented language, but C# further includes support for component

oriented language.

C# has a unified type system. All C# types, including primitive types

such as int and double, inherit from a single root object type. Thus, all types

shares a set of common operations, and values of any types can be stored,

transported, and operated upon in a consistent manner.

C# is standardized by ECMA International as the ECMA-334

standard and by ISO /IEC as the ISO/IEC 23270 standard. Microsofts C#



63/73


64/73


CHAPTER 10

REFERENCES:

[1] Linux laptop mode document. http://lxr.linux.no/

source/Documentation/laptop-mode.txt.

[2] F. Chen, S. Jiang, and X. Zhang. SmartSaver: Turning flash memory into

a disk energy saver for mobile computers. In Proc. of 2006 International

Symposium on Low Power Electronics and Design (ISLPED06), 2006.

[3] X. Chen and X. Zhang. A popularity-based prediction model for webprefetching. In IEEE Computer, volume 36, March 2003.

[4] CISCO. http://www.cisco.com/application/pdf/en/us/guest/

products/ps448/c1650/ccmigration 09186a0080088828.pdf.

[5] X. Ding, S. Jiang, F. Chen, K. Davis, and X. Zhang. DiskSeen:

Exploiting disk layout and access history to enhance I/O prefetch. In Proc. of

USENIX07, 2007.

http://lxr.linux.no/http://www.cisco.com/application/pdf/en/us/guest/http://lxr.linux.no/http://www.cisco.com/application/pdf/en/us/guest/


65/73


[6] F. Douglis, P. Krishnan, and B.Marsh. Thwarting the power- hungry

disk. In Proc. of 1994 Winter USENIX Conference, January 1994.

[7] D. P. Helmbold, D. D. E. Long, and B. Sherrod. A dynamic disk spin-

down technique for mobile computing. In Proc. Of the 2nd Annual

International Conference on Mobile Computing and Networking, 1996.

[8] HITACHI. http://www.hitachigst.com/tech/techlib.nsf/products/

DK23DA Series.

[9] S. Jiang, X. Ding, F. Chen, E. Tan, and X. Zhang. DULO: an effective

buffer cache management scheme to exploit both temporal and spatial

localities. In Proc. of FAST05, 2005.

[10] E. Jung and N. Vaidya. A power control MAC protocol for Ad Hoc

networks. In Wireless Networks (ACM WINET), 2005.

[11] M. Anand, E. B. Nightingale, and J. Flinn. Self- tuning wireless

network power management. In Proceedings of the 9th Annual Conference

on Mobile Computing and Networking, pages 176189, San Diego, CA,

September 2003.

[12] M. Anand, E. B. Nightingale, and J. Flinn. Ghosts in the machine:

Interfaces for better power management. In Proceedings of the 2nd Annual

Conference on Mobile Computing Systems, Applications and Services,

pages 2335, Boston, MA, June 2004.

http://www.hitachigst.com/tech/techlib.nsf/products/http://www.hitachigst.com/tech/techlib.nsf/products/


66/73


[13] T. E. Anderson, M. D. Dahlin, J. Neefe, D. Patterson, D. Roselli, and R.

Wang. Serverless network file systems. In Proceedings of the 15th

ACMSymp. on Op. Syst. Principles, Copper Mountain, CO, Dec. 1995.

ABSTRACT

Now-a-days the passion is towards the wireless devices. Everyone are

using wireless devices such as mobile phones, laptops, mobile computers

and so on. We might be thinking that charging these devices doesnt

consume much more energy. But the fact is that, the total amount of powerrequired to charge all the mobile phones will be equivalent to the total

amount of power required to run an industry.

Therefore it is must to prevent energy loss in such a devices. Here in

our project we propose a new scheme called FLEXFETCH which is used to

prevent energy loss in mobile computing.

In a pervasive computing environment, the data may either stored in a

local disk or in a remote server. The selection of the data sources depends

upon the operational states (in case of Local Disk), Bandwidth (in case of

Wireless Network) and the amount of data requested. FLEXFETCH is used

to adaptively select the data source (local disk or remote server).

FLEXFETCH is a profile based I/O management scheme that is aware

of file access history and adaptive to current access environment. It is

proactively designed to select the least costly data source to service

applications request.



67/73


68/73


2.3 Traces Collection.

9

2.4 Example scenarios.

10

3 SYSTEM ANALYSIS

15

3.1 EXISTING SYSTEM.

15

3.1.1 Architecture of BlueFS.

17

3.1.2 Integration with Power Mnagement.

18

3.1.3 Energy Efficiency.

19

3.1.4 Limitations of BlueFS.

21

3.2 PROPOSED SYSTEM.

22

CHAPTER TITLE

PAGE NO.

4 SYSTEM DESIGN.

23

4.1 Block Diagram.

23

4.2 Description.

24



69/73


4.3 UML Diagrams.

25

5 SYSTEM IMPLEMENTATION

32

5.1 Data Flow Diagram.

32

5.2 Description.

33

5.3 Modules used.

34

5.4 Modules Explanation.

35

5.4.1 Profiling Program Execution.

35

5.4.2 Adaptive selection of Data source.39

5.4.3 Re-Evaluating the profile.

42

6 TESTING TECHNIQUES/TESTING STRATEGIES.

44

6.1 TESTNG TECHNIQUES.

44

6.1.1 White box Testing.

45

6.1.2 Black Box Testing.

45

6.1.3 System Testing.

46

6.1.4 Unit Testing.

47

CHAPTER TITLE

PAGE NO.

6.1.5 Functional Test.

47

6.1.6 Structured Test.

47



70/73


6.2 SOFTWARE TESTING STRATEGIES.

48

6.2.1 Program Testing.

49

6.2.2 Validation Testing.

49

7 CONCLUSION.

51

8 FUTURE WORK.

52

9 APPENDICES.

53

9.1 Sample Codes.

53

9.2 Software Details.60

10 REFERENCES.

64

LIST OF FIGURES

S.NO TITLE PAGE

NO

2.4.1 grep + make : energy consumption with various

10

Bandwidth and Latencies.

2.4.2 mplayer: energy consumption with various

13

Bandwidth and Latencies.



71/73


3.1 Blue File System Architecture.

17

3.2 Integration with power management. 18

3.3 Interactive delays and Energy Usage.

20

4.1 Block Diagram of FLEXFETCH.

23

4.3 UML Diagrams.

25

4.3.1 Use case Diagram.

25

4.3.2 Class Diagram.

26

4.3.3 Activity Diagrams.

274.3.3.a. Profiling.

27

4.3.3.b. Adaptation.

28

4.3.3.c Re-Evaluation.

29

4.3.4 Sequence Diagram.

30

4.3.5 Collaberation Diagram.

31

5.1 Data Flow Diagram.

32

S.NO TITLE PAGE

NO

5.4.1.a. Home Form. 36

5.4.1.b. Input read Form. 37

5.4.1.c. Profiling Program Execution Form. 38

5.4.1.d. Sequence Data Form. 39

5.4.2 Adaptive Data selection Form. 42

9.1 Architecture of DONET. 61



72/73


LIST OF TABLES

S.NO TITLE

PAGE NO

2.1 The energy consumption parameters for the 7

DK23DA Hard Disk Drive.

2.2 The energy consumption parameters for the 8

CISCO AIRONET 350 Wireless card.

2.3 Trace Description.

9

LIST OF ABBREVATIONS

CAM - Continuous Aware Mode.

PSM - Power Saving Mode.

WNIC - Wireless Network Interface Card.



73/73


BlueFS - Blue File System.

WR - Write.

RD - Read.

UML - Unified Modeling Language.

ASP - Active Server Page.

XML - Extended Markup Language.

CLR - Common Language Runtime.

Documents

Prevention Of Energy Loss in Mobile Computing Using FLEXFETCH Scheme