THIS TEXT WILL NOT BE SHOWN DURING PRESENTATION! Design by Jon Angelo Gjetting Reproducability not allowed without explicit written consent from Jon Angelo Gjetting. The development in Network Performance And its impact on the computing model of tomorrow

The GRiD Named after the power-grid Sometimes referred to as the information power grid Like the power-grid GRID should be powered by large installations –not individual generators

Philosophy Current Internet only allows access to information The GRiD should provide access to any desired resource –CPU/SuperComputers –Storage –Applications

Performance Improvement since 1988

Rules of the Game Copenhagen-Stockholm 1988 –Latency 40 ms –Bandwidth 64 kb/s 2005 –Latency 10 ms –Bandwidth 10Gb/s Networking is much better

Is There an Improvement? Whether we have an improvement depend on our watch!

CPU Whether we have an improvement depend on our watch! Is There an Improvement?

CPU Outer Clock Inner Clock Whether we have an improvement depend on our watch! Is There an Improvement?

Rules of the Game Copenhagen-Stockholm Using the inner clock 1988 –1B: 0.8M CPU cycles –1GB: 2T CPU cycles 2005 –1B: 39M CPU cycles –1GB: 3G CPU cycles Latency is much worse But bandwidth is much better

Rules of the Game Harddrive-Memory Using the inner clock 1988 –1B: 1M CPU cycles –1GB: 1G CPU cycles 2005 –1B: 13M CPU cycles –1GB: 38G CPU cycles Hard-drives are also much worse

Development as seen from the CPU

Why is GRID? Network bandwidth is now here

Transparent Remote File Access Huge input files incur a number of problems: –Download time vs. total execution time –Job execution on the resource is delayed –Storage requirements on resources Often only small scattered fragments of input files are needed How about automatic on-demand download of needed data?

int fd = open(inputfile, O_RDONLY); while ((i=read(fd, &buffer, 2000)) >0){ /* process buffer */ } Example User applications need not be recompiled or rewritten!

Communication Protocol HTTP supports a range parameter in get request: GET /inputfile HTTP/1.1 HOST: MiG_server.imada.sdu.dk Range: bytes= No range support in put requests –In order to support writing to remote files, a custom web server is developed

Overriding file-access Override a subset of file manipulating routines: –open, close, read, write, seek, dup, sync, etc. Preload this library using the LD_PRELOAD environment variable –Requires user apps to be dynamically linked Forward local file access to the native file system using the dlfcn library

Efficient Access Simple solution: general purpose block size based on n/2-analysis Advanced solution: depends on the user application: –The nature of the application (sequential vs non- sequential file access) –The block size used in the application Introduce prefetching (1 block read-ahead) Adjust the block size dynamically based on the prefetching and the time taken to transfer a block

Experiments 4 experiments: – Overhead: read a one byte file – I/O intensive application: Checksum a 1 GB file – I/O balanced application: Process a 1 GB file – Partial file traversal: Search a 360 MB B+ tree for a random key 3 test setups: – Local execution – Copy model – Remote access model

Baseline Performance 100Mb net ExperimentLocalCopyRemote 1B file Checksum Balanced B+ Tree

Latency tests

Checksum

Balanced

B+ Tree

True End of the PC? If we can eliminate the disk we eliminate >60% of the errors in the PC But perhaps we dont need the PC –The average PC utilizes less that 5% of its capacity (Source: Intel) Reality is that the PC is –Much too powerful most of the time –Not nearly powerful enough the rest of the time So we eliminate the PC?

Bandwidth for Remote users A graphics intensive user –Screen size: 1600x1400 –Frequency: 50Hz –Color depth: 32b –Compression 1:10 Required bandwidth: 0.33 Gb/s Translates into 30 users per 10Gb line

Bandwidth for Remote users A typical user –Screen size: 1280x1024 –Frequency: 30Hz –Color depth: 24b –Compression 1:100 Required bandwidth: Gb/s Translates into 1138 users per 10Gb line

World of Tomorrow? GRID User Resource GRID Dis k

The Grid Terminal

Grid terminal

But we have seen this before? Is this not just another thin client? No! –Thin clients work against dedicated servers –Grid has no single point of failure –And Grid has competition

Distributed Shared Memory

DSM Test – the problem… PointsLatency (us)Bandwidth (MB/s) SDU-SDU NBI-NBI SDU-NBI SDU-DIKU NBI-DIKU

The Results

Conclusion and Predictions No reason to expect any change in the development of performance Networks will be increasingly slower But bandwidth is limited only by demand Grid will allow users to ignore computer maintenance and backups Even individual home-users will join Grid

THIS TEXT WILL NOT BE SHOWN DURING PRESENTATION! Design by Jon Angelo Gjetting Reproducability not allowed without explicit written consent from Jon Angelo Gjetting.