Planning around Technology Prof. Eric A. Brewer UC Berkeley ICT for Developing Regions September 17, 2003
Download ReportTranscript Planning around Technology Prof. Eric A. Brewer UC Berkeley ICT for Developing Regions September 17, 2003
Planning around Technology Prof. Eric A. Brewer UC Berkeley ICT for Developing Regions September 17, 2003 Today’s Focus How to think about technology… Not very technical Goal: map applications into technology options Architecture Networking Devices and Sensors General Architecture Data Center Internet Data Center Data Center Proxies, Basestations cell Devices or sensors “disconnected” Data Centers Best place to store persistent data (device is second best) Can justify backup power, networking, physical security Cheapest source of storage/computer per user 100-1000x less than a personal device (!) Factors: shared resources, admin cost, raw costs (power, disks, CPUs) Need at least two for disaster tolerance Plan about 3 in urban centers (for one region) Berkeley will be the data center for our early work… Networking The key enabler… distribution for information. Focus on wireless Packets allow efficient use of media Vastly cheaper to deploy Wide range of options “multiplexing” IP = “Internet Protocol” Global names for every device Way to route packets to names Basics Bandwidth = data/sec Latency = transmission delay in seconds Modem = 56 kilobits/sec DSL = 384 kilobits/sec Ethernet = milliseconds Satellite = ¼ second Power should be mostly tied to transmission Double distance => quadruple power Sequence of short hops usually lower power (but higher latency) Communication Attributes Directional or Omnidirectional Broadcast or Unicast Wireless is always broadcast Shared or Single User Wireless is always shared Synchronous or Asynchronous Cellular is synchronous: full-time two-way connection E-mail is asynchronous: send now, receive later Understanding Range Range costs power (squared) Long distances best covered with directional antennas User density matters: 10x difference in range for low cost “Point-to-point” links Can go 50km at reasonable cost Range also limited by total users Urban areas thus use short-range wireless Rural areas need long-range Claim: need islands of coverage (with point-to-point) Islands are the dense areas (e.g. villages) Example: India Mumbai (Bombay) Chennai (Madras) Mumbai Broadcast vs. Unicast Broadcast: same data to everyone Unicast: data to one person Web page, e-mail Wireless broadcast is *cheap* TV, radio, newspaper Easy to reach many users with one transmission Example: satellite TV Claim: we will need to exploit broadcast Broadcast common data even for unicast applications Example: common web content Goal: minimize unicast data Synchronous vs. Asynchronous Synchronous: two-way communications Low latency, e.g. Phone = ¼ sec or less Expensive: dedicated resources along whole path Examples: phones, games, web browsing Async One-Way: e.g. TV, Internet movie Delay allowed: e.g. “buffering” for Real Player Hides losses: resend data before it is missed Typical delay is 10 seconds Good fit for broadcast Examples: Streaming, Market Prices, Weather alerts Sync vs. Async (2) Async Two-Way: e.g. e-mail request Delay in getting response (= two async one-way) Savings: Semi-interactive, but potentially much cheaper… No need for dedicated resources Can “store-and-forward” data (like real mail) Can hide problems (e.g. power out) by waiting Examples: e-mail, correspondence classes, medical diagnosis (non-emergency), coordinating money transfers, ecommerce (e.g. catalogs) Open Questions: How much cheaper? How much more reliable? When is async good enough? Intermittent Networking Physical: Low-earth orbit satellites: connect only while they are overhead “Mules” – moving basestation collects data Basestation could be on a bus Weather, e.g. some places only get radio on clear nights Overloaded network may delay transmission Extended coverage: User may periodically enter the coverage area E.g. coverage only near market or school The Case for Intermittent Pros: Cost: better use of resources, more tolerant of problems Reliability: delay hides transient problems Ease of deployment: can be more ad hoc, less coordination than a synchronous system Coverage: Intermittent coverage >> full time coverage Cons: Not really interactive, or only interactive in some areas Need to design apps around this (new) model Don’t know what delay is OK (depends on the app) Cellular Phones Advantages: User interface works well (no need for literacy) High demand for voice, but some data provided High-volume phones and basestations Disadvantages: Hard and expensive technically Voice may be inefficient use of bandwidth Poor fit for rural users (low density of users) Typical data rate < 9600 baud Example: Cellular Standards Cell Range Cost Bandwidth bits/sec GSM 10 km $100K 9600 ~800 PHS 100-300 m $3K 9600 ~200 35 km ? 9600 ~800 System MiniGSM Simult. Users Satellites Pros: great for broadcast, coverage Cons: limited shared bandwidth, mostly one-way, high latency GEO (geostationary – stays in one place) 35000 km up, very high latency Mostly one-way due to power LEO (low-earth orbit), <1000 km up Intermittent coverage (only when overhead) Better latency and power, cheaper Need lots of satellites (800?) Two-way using Satellites Option 1: transmit up to the satellite Very high power required, and large antenna Very low bandwidth (9600 or less) Option 2: use a different network Telephone is most common, could use wireless Tricky but possible to do TCP Variation: upload data later when convenient (intermittent) Good for mostly broadcast applications, coverage WiFi: 802.11 Made for wireless local-area network Three variations: b: 1 Mb/s, oldest and cheapest, $5/chipset a: 11 Mb/s, shorter range g: 54 Mb/s, shorter range, more channels Best for long-distance links Best for omni coverage of local area (if cheap) Decent for long distance: (802.11b) Special directional antennas & alignment, ($20-$200) 30km seems easy, 88km is current record Longer distances need towers, 40’ typical WiMax (802.16) New standard for metro areas Target is 30km radius, $20K for basestation High bandwidth, low density Cost should come down (as with 802.11) Receiver per village, not per person 100 villages per basestation plausible Probably requires licensing (not free for all) Complements 802.11 for local coverage Expect this combo to be very popular… Proxies and Basestations Cellular => one basestation per cell Proxies are similar: locally shared computing/storage 10x less than devices (per user!) Target cost: $200 or about 20¢ per user Good way to share computing, storage Relay point for networking Typically stationary, may be solar powered “Mules” are mobile proxies Easy to upgrade in place (like Tivo) Not good for long-term storage (“persistent data”) No backup plan, unreliable power and security… Example Proxy Tasks Caching of frequently used data Temporary storage Packets waiting for LEO Transactions in progress Computation-intensive tasks: Such data can be broadcast to proxies Speech recognition Sensor data analysis Process data for “dumb” device Can double as “big” device, e.g. Internet kiosk Devices Wide range of devices are possible Two broad classes: General-purpose computer (Simputer, PDA, laptop) Task specific: water testing, telephone, camera Claim: task specific is a better choice Much simpler to use (and train for) Can be more cost effective Volume should be high enough to justify Shared Devices Sharing reduces the cost per user Village phones have 4-8x better cost/performance May only need one per village (water testing) Some design issues: Does behavior depend on which user? E-mail does, telephone does not Need for authentication, accounting? Claim: Most projects should start with shared devices Can move to personal devices if demand warrants… Device Costs Big costs: General driver: too many components Packaging Screen: color is >3x monochrome Battery UI: keyboard, buttons, touch screen, … Solution: better integration into silicon Silicon is ~free… (marginal cost) We are working on real details of costs… How to think about devices… Sharing is good (but design for it) Task-specific is good (simpler and cheaper) UI and size have a lot to do with cost… Dependence on infrastructure is good Reduces cost (and theft) Can push work into infrastructure as needed Increases extensibility, decreases obsolescence … but requires thought about disconnected operation Sensors Sensors on silicon => very cheap Basic: temp, humidity, pressure, moisture, light… Moderate: acceleration, magnetic, position Simple chemical: gases, smoke Complex biological: toxic agents Actuators: control environment as well Much harder: usually want human in the loop… Sensor Applications Environmental monitoring Aid to Infrastructure Electrical grid loss/theft Water distribution loss/theft/quality Commerce Water testing Weather warnings? Butterfat testing for milk pricing Health Home environment Human tests? (or animal) Example: Great Duck Island Monitoring petrels on an island in Maine About 50 sensors Some in burrows, detect occupancy Some to track environmental conditions Fits architecture: 1.25 inch Data center in Berkeley Network: local wireless in patches, satellite to UCB Proxies: process/manage data collection Mix of sensors Intermittent connectivity (to save power) Summary Decide on the task Intermittent networking may be sufficient Not about internet access (per se), about applications Drives UI, leads to simplicity, lower cost Long-term: single chip per app is ideal… Wide range of devices can share infrastructure Greater coverage, much lower cost, more reliable Not always interactive Share, share, share Data centers are big shared resources, >100x savings Proxies are locally shared resources, >10x savings Share devices as well