Soma at 19:28, 11 January 2023

2023-01-11T19:28:48Z

← Older revision		Revision as of 19:28, 11 January 2023
Line 20:		Line 20:

	Note that you do not need to discuss all of the above; instead, use them as inspiration for your own discussion of distributed applications.		Note that you do not need to discuss all of the above; instead, use them as inspiration for your own discussion of distributed applications.

			==Notes==

			<pre>
			Lecture 2
			---------

			group comments
			- peer-to-peer
			- replication (how much?)
			- caching
			- partitioning data
			- partitioned networks (systems drop off)
			- routing
			- load balancing
			- fault tolerance & recovery
			- partial file transfers
			- sharding (geo, etc)
			- concurrent access
			- optimistic access (and conflict recovery)

			What scenarios seemed to be the hardest? Why?
			the weather simulation, because it is not "embarassingly parallel"

			The sad thing about distributed systems is...we really can't do much unless the problem is mostly embarassingly parallel
			- that's the only situation that truly scales
			- you really need high bandwidth, low latency to do these kinds of problems

			What is difficult in parallel problems is managing communication
			- because communication is necessary and expensive

			low latency allows for rapid communication - because communication requires
			back-and-forth interactions

			Amdahl's law
			- performance is limited by part that cannot be parallized
			- if you make one component super fast/parallel, it will be held back by the rest of the system
			- to make a system high performance every part has to be optimized
			- and some components and interactions are much harder to speed up than others

			For example, consider CPU design
			- why don't we have n-core systems, for n "big"?
			- we have them for GPUs?

			GPUs are optimized for parallel processing
			- mostly embarassingly parallel, i.e., tasks that can be cleanly partitioned

			CPUs are optimized for sequential processing first
			- highly branched code

			Sequential code can only be parallelized with hard work
			- automated parallelization is possible to some degree,
			if we are willing to waste resources
			(see CPU speculative execution)

			The main way computers get faster now is through parallelization
			- through increasingly clever ways
			- and being clever doesn't scale

			When we go distributed, the situation is much worse
			- because of higher latency and increased possibility of errors
			</pre>

Soma: Created page with "==Group Discussion== Today we'll be discussing the challenges in building distributed applications. To this end, we will start with the following design exercise. You'll be split into small groups to discuss, and then we'll meet together to discuss what you all found. Every group should take notes so you can write up a group report afterwards. You should also appoint someone to tell the class a 2 minute (or less) highlights from your discussion. ===The Scenarios===..."

2023-01-10T23:38:29Z

Created page with "==Group Discussion== Today we'll be discussing the challenges in building distributed applications. To this end, we will start with the following design exercise. You'll be split into small groups to discuss, and then we'll meet together to discuss what you all found. Every group should take notes so you can write up a group report afterwards. You should also appoint someone to tell the class a 2 minute (or less) highlights from your discussion. ===The Scenarios===..."

New page

==Group Discussion==

Today we'll be discussing the challenges in building distributed applications. To this end, we will start with the following design exercise. You'll be split into small groups to discuss, and then we'll meet together to discuss what you all found. Every group should take notes so you can write up a group report afterwards. You should also appoint someone to tell the class a 2 minute (or less) highlights from your discussion.

===The Scenarios===

You have 10,000 networked computers. Consider the following tasks:
* A file server for storing lots of small files for many users
* A file server for storing relatively few but enormous files that are accessed my many systems at the same time
* A whole-planet weather simulation
* A database for airline reservations
* A social media app where individuals only communicate with a small number of friends
* A social media app where users can subscribe to topics, groups, and individual feeds, potentially allowing for the sharing of information amongst all users at the same time.
* (Make up your own tasks.)

At a high level, how would you architect a system to distribute these workloads over the available computers? Be sure to consider:
* Would your architecture be robust to individual hosts crashing, being corrupted, or becoming malicious?
* How performant is your solution? Will it scale to even more hosts?
* Are some hosts more important than other hosts?

Note that you do not need to discuss all of the above; instead, use them as inspiration for your own discussion of distributed applications.

DistOS 2023W 2023-01-11 - Revision history

Soma at 19:28, 11 January 2023