|
|
|
Thomas Kunz |
|
Systems and Computer Engineering |
|
Carleton University |
|
http://kunz-pc.sce.carleton.ca/ |
|
tkunz@sce.carleton.ca |
|
|
|
|
Background: Motivation and Related Work |
|
Mobile Code Toolkit |
|
Experimental Results |
|
Scalability: Performance Models (LQM) |
|
Conclusions and Future Research |
|
|
|
|
|
|
|
|
Typically, related work focuses on bandwidth
variation |
|
Other resources are also constrained (memory,
power, CPU capabilities) and may vary over time |
|
Majority of solutions: introduce proxy between
client (application executing on mobile device) and server, proxy
compresses and filters data stream |
|
sometimes, degree of compression depends on
available bandwidth |
|
user mobility often not addressed/supported |
|
Other solutions: |
|
view mobile purely as User Interface (WWW
browsers, Teleporting, ....) |
|
partition client application between mobile and
proxy |
|
partition directed by application (Rover, MaROS,
....) |
|
partition transparent to application (our own
focus) |
|
|
|
|
|
|
|
|
|
Extend JVM on client and proxy server |
|
Monitor |
|
Code Storage |
|
Object References and Profiling |
|
Object Server |
|
Remote Method Invocation Protocol |
|
Dynamic Decision |
|
Communication Control Layer |
|
Extend garbage collection to deal with remote
references |
|
Provide abstractions to notify runtime system
about environment and changes in environment (bandwidth, power, …), based
on events and event notification |
|
|
|
|
|
|
Implemented MP3 player, encapsulated decoder as
mobile agent, to execute locally or remotely |
|
Various performance experiments, study impact of |
|
Available Bandwidth (19.2 kbps – 2 Mbps) |
|
Relative CPU speed (Mobile CPU: Proxy CPU) |
|
1:4 for laptop as client device |
|
1:116 for Windows CE palmtop as client device |
|
Results: |
|
for high bandwidth and slow client, offloading
decoding “agent” to proxy can speed up application performance by a factor
of 20 and reduce power consumption by 95% |
|
For faster client devices, independent of
bandwidth, no benefit (actually worse performance) when decoding sound
samples in access network |
|
|
|
|
|
|
|
Many parameters deduced from traces collected
from live cellular network (Bell Mobility’s MicroBrowser) |
|
Study system capacity under changing load
conditions, vary computational load off-loaded to proxy |
|
Results: |
|
Proxy makes slow handsets/clients faster |
|
System capacity decreases slightly |
|
For system under study, application server more
likely to become bottleneck than proxy |
|
č single proxy server can support current
client population |
|
Caveat: results specific for application
studied, may not generalize for more demanding multi-medial 3rd-generation
mobile applications |
|
|
|
|
|
Conclusions: |
|
Implemented Mobile Code Toolkit with small
footprint for Windows CE devices |
|
Collected experimental evidence to verify
validity of our approach |
|
Developed a general approach to study
scalability |
|
Future Work: |
|
Improve toolkit: better RMI performance,
automatic generation of proxy objects, port to Palm OS |
|
Study additional applications and more dynamic
scenarios |
|
How to predict scalability when agent’s
functionality is not similar to a “server” (i.e., decode next frame and
return sampled sound) |
|
Interaction between application-aware (MP3
player reduces sound quality, sampling rate, …. ) and
application-transparent (runtime system migrates decode agent from handset
to proxy) adaptation |
|
Notes