the punch portal to internet computing: run any software...

The PUNCH Portal to Internet Computing:Run Any Software Anywhere via WWW Browsers

Nirav H. Kapadia Jose A. B. Fortes Mark S. Lundstrom

School of Electrical and Computer Engineering

Purdue University

I. Introduction to PUNCHII. System Design OverviewIII. External System InterfaceIV. Internal ArchitectureV. Supported ResourcesVI. Resource ManagementVII. Conclusions

UPC Presentation, June 2000 Nirav Kapadia, Purdue University

PUNCH Overview:g PUNCH is a distributed network-computing infrastructure that

allows geographically dispersed users to run unmodified toolsvia standard Web browsers( www.ece.purdue.edu/punch )


Core Research Team:Nirav Kapadia, Jose Fortes, Mark Lundstrom, RenatoFigueiredo, and Sumalatha Adabala

Collaborators:Rudolf Eigenmann, Dolors Royo, and Jose Miguel-Alonso

Partner Institutions:Northwestern, U. of Wisconsin at Madison, Chicago State, U. ofIllinois at Urbana-Champaign, Arizona State, Stanford, U. ofTexas at El Paso, SIGDA, IUPUI, and Purdue Calumet.


1999

1995

1M

#Hits

‘‘as is’’ installation in 30 mins

operational for five years

version 5 being developed

50+ engineering tools

3,000,000+ hits

800+ users

users in 10 countries

usage doubles each year


. . .

Physical Location ‘n’Physical Location ‘1’

SCION

(Network Desktop)Front End

. . .

Sof

twar

eS

CIO

N

Tool (Application) Workstation Cluster

Parallel Machine

Compute-Server

Parallel Machine. . . . . . . .

Tool (Application)

Tool (Application) Tool (Application)

Sof

twar

e

CA

Tool (Application)

ESES RT

Workstation Cluster

Toolkit

The

Compute-Server

The

SimulationHub

Semiconductor . . .

Network -Desktop Interface

Tool (Application)

TheComputer

HubArchitecture

SC

ION

TheParallel

ProgrammingHub

D

TheVLSI

DesignHub

Internet / Intranet

Network -Desktop Interface

The Purdue University Network-Computing Hubs (PUNCH)


Portal Screen Shot( http://www.ece.purdue.edu/punch/ )


Resource Management (application management; resource allocation)

Resources Supported (class of programs/machines supported)

Internal Architecture (internal system design and structure)

External System Interface (external view of the system)

Net

wor

k-C

ompu

ting

Sys

tem

s


External System Interface:g Objective: universal access

g Approach: leverage the World Wide Web

g Challenge: work within the existing WWW framework

g Status: students and researchers in ten countries routinelyuse PUNCH via standard Web browsers; 50+discipline-specific and productivity tools are available


Internal Architecture:g Objective: scalability and interoperability

g Approach: hierarchically distributed architecture

g Challenge: manage tools and information in situ

g Status: system deployed on Unix; support for customized userviews, global user accounts, and virtual filesystems;root access not required


Supported Resources:g Objective: work with unmodified tools

g Approach: virtual interfaces; configurable environment

g Challenge: state management; flow control

g Status: batch, interactive, and graphical tools supported; newprototype supports PVM programs and Condor, DQS,and PBS jobs


Resource Management:g Objective: address usage policy and performance issues

g Approach: metaprograms; application management

g Challenge: predictive performance modeling; interoperability

g Status: scheduling customizable on a per-tool and per-userbasis; prototype machine learning system facilitatesautomated cost/performance tradeoff decisions


External System Interface:

g Problem: must work within existing WWW frameworkSolution: virtual URLs; web-accessible OS

g Problem: HTML is staticSolution: HTML templates; embedded variables/objects

g Problem: no flow-controlSolution: metaprograms; programmable state machine


WWW-Based Computing (Issues):

Processing supported as anadd-on via CGI scripts.

Processing is an integral partof the service.

Integration of distributedcomputing and WWW.

Designed for a (mostly)read-only environment.

A read-write environment iscritical for correct operationof OS services.

Need synchronization andresource locking. Supportfor a multi-user web OS.

Designed for documentserving, with some supportfor dynamic information.

Primarily provides OS functions(e.g., process management).Document serving is secondary.

Standard WWW resourcemanagement model notappropriate.

WWW-BasedInternet/Intranet ComputingWWW Framework Issues

Mostly public space, with somesupport for access control.

Mostly private space, with somesupport for sharing user data.

Authentication model forWWW does not scale.

Unique mapping between URLand some entity within thefilesystem (physical URL).

URL is a functional request thatis mapped in a context-sensitivemanner (virtual URL).

WWW URL model doesnot support truely dynamicURL mappings.


Virtual Addresses:

AddressTranslation

VirtualAddress

PhysicalAddress

OffsetBase

Page Address Offset in Page

Translation process involves a simpletable lookup.


Virtual URLs:

URLTranslation

PartiallyTranslated URL

VirtualURL Base Offset Base Offset Meta-Information. . .

Repeat Process

Base-Offset Pairfor each

Physical‘‘URL’’

and generates side-effects (e.g., state andcontext initialization).

Translation process involves database queries,

Meta-Information. . .Object Handle Target Module

Base Offset Meta-Information. . .Object Handle


HTML Templates (Variables/Objects):

Begin PageTemplate Begin Declarations menu myFiles = 1:<UserFiles>; bind myFiles = <WorkingFolder>; End Declarations

Begin HTML <FORM> Select a file (or folder to open): <myFiles> <P> <CENTER><INPUT TYPE="submit" VALUE="Proceed"></CENTER> </FORM> End HTMLEnd PageTemplate


Metaprograms (Flow Control):

.

.

.

retrievestate ’directory’;display ’Page1’;while(isdir(<myFiles>)){ chdir(<myFiles>); display ’Page1’;}savestate ’directory’;


Performance Summary:

60

61

75

61

64

47

53

58

27

27

35

27

30

29

20

24

Entry Page

Input Management

Run Management

Output ManagementToo

l Int

erfa

ceS

tatic

Info

Publicly-Accessible URL

Access Control Enforced

Process Status

Dynamic Information

No Preforking With Preforking

Response Time (milliseconds)Type of Transaction


Internal Architecture:

g Problem: dynamic/incremental/distributed informationSolution: hierarchically distributed architecture

g Problem: multiple administrative domainsSolution: resources usable/visible/invisible; partitioned root

g Problem: scalability of information retrievalSolution: hashing; access codes


Core Architecture:

Management Unit

Execution Unit

Client Unit

InterfaceNetwork

InterfaceNetwork

Resources

User

User-Specific Information

Site-Specific Information

Tool-Specific Information

(e.g., tool-input, preferences, etc.)

(e.g., algorithmic complexity,

(e.g., default configuration,

platforms supported, etc.)

path to executable, etc.)


RepositoriesApplication

Managed

. . .

Application

Resources

Units Units

Resources

Execution5

Managed

Desktop

Repositories

4

Interface

Hub UserAccounts

Units

3

Hub UserAccounts

Network. . .2

Management

Desktop

1

Pu

rdu

e U

niv

ersi

ty N

etw

ork

-Com

pu

tin

g H

ub

s

Execution

Interface

Tools

Network

Interface

Logical Resource-InterfaceScheduling Job Control

Network

Tool-SpecificInput Analysis

Desktop

ResourceResolution

SCIONAllocationResource

Tool-K

eye

d K

now

ledge B

ase

Mach

ine L

earn

ing S

ubsyste

m

ManagementUser-Command

Authentication

URL Translation

View-CustomizationHTML

Data FilesPreferences Restrictions

State Info.

World-Wide WebStandard

Browser

3. Application-invocation requests are forwarded

to an appropriate Management Unit.

resource requirements, and selects Execution Unit.

4. Management Unit authenticates request, determines

5. Execution Unit processes run request and notifies

Management Unit on completion.

‘‘non-application-invocation’’ requests.

2. Network Desktop processes and responds to all

1. User-access via standard WWW browsers.

Management

Application Specs.

UserPlatform

Front End

Units

UserPlatform

UserPlatform

. . .

Use

r n

Use

r 2

Use

r 1

HTTP

UPC

Pres

enta

tion,

June

2000

Nir

avK

apad

ia,P

urdu

eU

nive

rsity

ComputeServer

ComputeServer

ServerR1.1

Hub UserAccounts

Server

Network

. . . UserPlatform

UserPlatform

Desktop

M1.1

Router Router

Router

Router

Server

R1.2

Repository

Accounts

Platform

Router

. . .

Application

Router

Machine

Accounts

Execution

Unit

Hub User

ApplicationE

xecutionU

nitRepository

Desktop

Server

ClusterFront-End

Network

ComputeServer

S1.2

Execution

Unit

Platform

UnitManagement

User

. . .ServerCompute

Server

ComputeServer

Platform

Unit

Execution

User

ServerCompute

Hub User

Unit

Execution

Router

Router

Main Site ‘M1’

Intranet

‘O’

Organization

‘R1’Site

Remote

‘S1’Service Provider

Internet

ProviderInternet

PlatformUser

Parallel

User

S1.1

ManagementUnit

ServerM1.2

NetworkDesktop

. . .

UPC

Pres

enta

tion,

June

2000

Nir

avK

apad

ia,P

urdu

eU

nive

rsity

Scalable Information Retrieval:

(O(1) accesswith code)

Hash Function

Resource-Lookup Manager

(k files; ~ n/kentries per file)

Password

Resource Access Code(Offset in File)

Hash Index(Filename Extension)

Identifier

Identifier

(Offset in File)Access Code

Hash-Table Size (k)

(n Identifiers)


0 10 20 302

4

6

8

10

12

14

16

18

20Effects of Using a Hash Function (994 Users)

Number of Buckets

Ave

rage

Aut

hent

icat

ion

Tim

e, in

mill

isec

onds

0 10 20 300.5

0.55

0.6

0.65

0.7

0.75

0.8

0.85

0.9

0.95

1Effects of Using Access Codes (994 Users)

Number of Buckets

Ave

rage

Aut

hent

icat

ion

Tim

e, in

mill

isec

onds


Member Authentication

Internal References

1,086,732

946,652

45,896

81

Present Absent

Access CodeType of Use

Access Code Proliferation


Supported Resources:

g Problem: many tools are not network-awareSolution: configurable ‘‘operating system’’ and environment

g Problem: must accommodate independently-developed toolsSolution: resource description language for tools

g Problem: graphical user interfacesSolution: leverage display-management technologies


DatabaseHub

DatabaseHub

Filesystem Map

. . .

TemplateServer

Com

piler

URL Map

Organization

URL MapFilesystem Map

Access Control MapMIME Types

Tool

Behavior

MIME Types

ToolSpecification

Server

ToolSpecification

Configuration

DirectoryCompiler

File Server

Cache

Workspace

User Accounts

Template

Specification

Programmable State Machine

Access Manager

Run TimeServices

Intranet / Internet

Run-Time System

LA

N

UPC

Pres

enta

tion,

June

2000

Nir

avK

apad

ia,P

urdu

eU

nive

rsity

Compiler

Tool

Input Translation

Specification

Input Pre-ProcessingExecution Syntax

Implementation Selection

Application Management

Access ControlLogical IndexingDocumentation

MIME Types

General Information

Output Post-Processing

Interface TemplateFlow Control

Input GrammarAnalysis Rules

Interface Generation


Resource Management:

g Problem: usage policies and performance issues intertwinedSolution: metaprograms; application management

g Problem: dynamic, heterogeneous environmentSolution: run-time cost/performance tradeoff decisions

g Problem: need a priori estimates of resource usageSolution: predictive application-performance modeling


Resource Management Model:

Status

Resource

Availability

Scheduling

Objective

PerformanceConstraints

Resource

Control

AdministrativeConstraints

Policies

Usage Access Tool-specific

Information

Run-specific

Information

PerformanceModeling

Demand-driven Resource Management


Resource Management Architecture:

5

SCION

1

PUNCH

4

ResourcesManaged

6

3

. . .

UsersUsers

2

Network DesktopNetwork DesktopPUNCH

ApplicationManagement

Pool

Manager

Manager

Pool

Resource Management Pipeline

for Computational Grids

Resource

Know

ledge-base

Manager

Hierarchy

Pool Softw

areM

achines

ManagementPool

Pool

ResourceManager

Query


e.g.: #carriers #nodes in grid device size convergence norm

Parse User-Input

Extract RelevantParameters

Qualify ExtractedInformation

Select AppropriateAlgorithm(s)

Rank Algorithms: f(parameters, available algorithms)e.g.: Monte Carlo, Hydro-Dynamic, Drift Diffusion

e.g.: cpuUnits = f(parameters) memReqd = g(parameters)

Determine HardwareRequirements

Reserve Resource(s)

VerifyDelivered

QoS

MoreOptions

?

Dispatch RequestRe-Negotiate QoSand Repeat/Abort

(Retry using alternate

architectures and/or algorithms)

Com

man

d-K

eyed

Kno

wle

dge

Bas

e

User-Supplied Command,Input, and QoS Range e.g.:

Simulate carrier transport for the given device specs; QoS specified in terms of one or more of wall-clock time, Mflop/s, I/O, etc.

e.g.: SPARC or HP Architecture with >=256MB RAM and >=300 SPECfp

Get Resource: f(Architecture, Memory, I/O, Performance, QoS)e.g.: SPARC ULTRA (karr.ecn)

Ok

Low

Y

N

UPC

Pres

enta

tion,

June

2000

Nir

avK

apad

ia,P

urdu

eU

nive

rsity

Performance Modeling (Synthetic Dataset):

0 10 20 30 40 500

10

20

30

40

50Target Concept

Feature Value

CP

U T

ime

0 10 20 30 40 500

10

20

30

40

501−Nearest−Neighbor Algorithm

Feature Value

Pre

dict

ed C

PU

Tim

e

0 10 20 30 40 500

10

20

30

40

503−point Weighted Average

Feature Value

Pre

dict

ed C

PU

Tim

e

0 10 20 30 40 500

10

20

30

40

50Linear Locally Weighted Regression

Feature Value

Pre

dict

ed C

PU

Tim

e


Performance Modeling (Real Dataset):g Tool ≡ T-Suprem3, a commercial silicon process simulator

g Data ≡ ∼∼8,100 runs from normal use of PUNCH over 10 months

g Features for T-Suprem3:- number of grid points,- total diffusion time,- cumulative epitaxial growth,- minimum implant energy,- number of deposit steps,- number of etch steps,- number of implant steps


Summary of Results:

0 1000 2000 3000 4000 5000 6000 7000 80000

10

20

30Results for T−Suprem3 Data−Set

Run Number

Pre

dict

ion

Err

or (

s) NN Wtd. Avg.LLWR

0 1000 2000 3000 4000 5000 6000 7000 80000

0.1

0.2

0.3

0.4

Run Number

Look

up T

ime

(s) noedit, c=0

noedit, c=5 iedit, c=0 iedit, c=5

0 5 10 15 20 25 300

500

1000

CPU Time

#Occ

urre

nces

Exact MatchLinear LWR


Related Research:

g Application-specific designsExploratorium, JSPICE, SIP, Virtual Lab, etc.

g Systems for numerical softwareMMM, NEOS, NetSolve, Ninf, RCS, etc.

g Systems for general-purpose softwareBond, Nimrod, PUNCH, Rivendell, WinFrame, etc.

g Systems for metacomputing applicationsATLAS, Globe, GUSTO, IceT, Legion, etc.


Industry Directions:g New ASPs -- e.g., AppCity and Corio

( focus is on business apps, as opposed to computing apps )

g Sun, Microsoft, and others( focus is on new or rewritten applications )

g Software vendors -- e.g., CAD companies( applications are modified to work with browsers )

g Middleware companies -- e.g., Citrix and SCO( closest to PUNCH’s approach; connectivity solution )

g PUNCH infrastructure( deployed and tested over 5 years; version 5; global user base )


Summary: External System Interfaceg Access via standard WWW browsers

g Semantics for computing services via virtual URLs

g HTML templates (embedded objects); compiler; generator

g Token-based caching (access codes); user-view customization

Summary: Internal Architectureg Scalable information management

g Security and access-control across domains

g Account, process, and data management

g Error management and recovery


Summary: Supported Resourcesg Tool specification and metaprogramming languages; compilers

g Metaprogramming environment (interpreter, virtual machine)

g State/session management; persistence engine

g Programmable parser (to emulate interactivity)

Summary: Resource Managementg Run-specific resource-usage prediction

g Knowledge management; locality of runs

g Run-time cost/performance tradeoff decisions

g Interoperation with external resource management systems


Hierarchically distributedarchitecture; partitionable.

Ability to work acrossadministrative domains.

removed via configuration files.Resources can be added orDynamic addition and

removal of resources.

Learning algorithms allowresource-usage prediction.

Ability to determinerun-specific ‘‘needs’’.

Users access and run toolsvia standard WWW browsers.

Pervasive access to comp-uting for authorized users.

Unmodified tools installed inas little as thirty minutes.

Ability to work withdiverse software.

The Purdue University

Network-Computing Hubs

Implications of Network-Based

Wide-Area Computing


the punch portal to internet computing: run any software...

Documents