application crash consistency and performance with ccfs
play

Application Crash Consistency and Performance with CCFS - PowerPoint PPT Presentation

Jul 13, 2023 •691 likes •2.09k views

Application Crash Consistency and Performance with CCFS Thanumalayan Sankaranarayana Pillai, Ramnatthan Alagappan, Lanyue Lu, Vijay Chidambaram, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau Application-Level Crash Consistency Storage must

  1. False Ordering Dependencies Application A Application B 31

  2. False Ordering Dependencies Time Application A Application B pwrite(f1, 0, 150 MB); 1 32

  3. False Ordering Dependencies Time Application A Application B pwrite(f1, 0, 150 MB); 1 write(f2, “hello”); 2 write(f3, “world”); 3 33

  4. False Ordering Dependencies Time Application A Application B pwrite(f1, 0, 150 MB); 1 write(f2, “hello”); 2 write(f3, “world”); 3 fsync(f3); 4 34

  5. False Ordering Dependencies In a globally ordered file system ... Time Application A Application B write(f1) has to be sent to disk before write(f2) pwrite(f1, 0, 150 MB); 1 write(f2, “hello”); 2 write(f3, “world”); 3 fsync(f3); 4 35

  6. False Ordering Dependencies In a globally ordered file system ... Time Application A Application B 2 seconds, irrespective of implementation used pwrite(f1, 0, 150 MB); 1 to get ordering! write(f2, “hello”); 2 write(f3, “world”); 3 fsync(f3); 4 36

  7. False Ordering Dependencies Problem: Ordering between independent applications In a globally ordered file system ... Time Application A Application B 2 seconds, irrespective of implementation used pwrite(f1, 0, 150 MB); 1 to get ordering! write(f2, “hello”); 2 write(f3, “world”); 3 fsync(f3); 4 37

  8. False Ordering Dependencies Problem: Ordering between independent applications Solution: Order only within each application - Avoids performance overhead, provides app consistency Time Application A Application B pwrite(f1, 0, 150 MB); 1 write(f2, “hello”); 2 write(f3, “world”); 3 fsync(f3); 4 38

  9. Stream Abstraction New abstraction: Order only within a “stream” - Each application is usually put into a separate stream Time Application A Application B stream-A pwrite(f1, 0, 150 MB); 1 stream-B 0.06 seconds write(f2, “hello”); 2 write(f3, “world”); 3 fsync(f3); 4 39

  10. Stream API: Normal Usage New set_stream() call - All updates after set_stream(X) associated with stream X - When process forks, previous stream is adopted Time Application A Application B set_stream(A) set_stream(B) pwrite(f1, 0, 150 MB); 1 write(f2, “hello”); 2 write(f3, “world”); 3 fsync(f3); 4 40

  11. Stream API: Normal Usage New set_stream() call - All updates after set_stream(X) associated with stream X - When process forks, previous stream is adopted Using streams is easy - Add a single set_stream() call in beginning of application - Backward-compatible: set_stream() is no-op in older FSes 41

  12. Stream API: Extended Usage set_stream() is versatile - Many applications can be assigned the same stream - Threads within an application can use different streams - Single thread can keep switching between streams 42

  13. Stream API: Extended Usage set_stream() is versatile - Many applications can be assigned the same stream - Threads within an application can use different streams - Single thread can keep switching between streams Ordering vs durability: stream_sync(), IGNORE_FSYNC flag - Applications use fsync() for both ordering and durability [Chidambaram et al., SOSP2013] - IGNORE_FSYNC ignores fsync(), respects stream_sync() 43

  14. Streams: Summary In an ordered FS, false dependencies cause overhead - Inherent overhead, independent of technique used Streams provide order only within application - Writes across applications can be re-ordered for performance - For consistency, ordering required only within application Easy to use! 44

  15. Outline Introduction Background Stream API Crash-Consistent File System Evaluation Conclusion

  16. CCFS: Design “Crash consistent file system” - Efficient implementation of stream abstraction 46

  17. CCFS: Design “Crash consistent file system” - Efficient implementation of stream abstraction Basic design: Based on ext4 with data-journaling - Ext4 data-journaling guarantees global ordering - Ordering across all applications: false dependencies - CCFS uses separate transactions for each stream 47

  18. CCFS: Design “Crash consistent file system” - Efficient implementation of stream abstraction Basic design: Based on ext4 with data-journaling - Ext4 data-journaling guarantees global ordering - Ordering across all applications: false dependencies - CCFS uses separate transactions for each stream Multiple challenges 48

  19. Ext4 Journaling: Global Order Ext4 has 1) main-memory structure, “running transaction”, 2) on-disk journal structure Running transaction Main memory On-disk journal 49

  20. Ext4 Journaling: Global Order Application modifications Application A Application B recorded in main-memory Modify blocks #1,#3 Modify blocks #2,#4 running transaction Running transaction 1 3 2 4 Main memory On-disk journal 50

  21. Ext4 Journaling: Global Order On fsync() call, running Application A Application B transaction “committed” to Modify blocks #1,#3 on-disk journal Modify blocks #2,#4 fsync() Running transaction 1 3 2 4 Main memory On-disk journal 51

  22. Ext4 Journaling: Global Order On fsync() call, running Application A Application B transaction “committed” to Modify blocks #1,#3 on-disk journal Modify blocks #2,#4 fsync() Running transaction Main memory begin On-disk journal end 1 3 2 4 52

  23. Ext4 Journaling: Global Order Further application writes Application A Application B recorded in new running Modify blocks #1,#3 transaction and committed Modify blocks #2,#4 fsync() Modify blocks #5,#6 Running transaction 5 6 Main memory begin On-disk journal end 1 3 2 4 53

  24. Ext4 Journaling: Global Order Further application writes Application A Application B recorded in new running Modify blocks #1,#3 transaction and committed Modify blocks #2,#4 fsync() Modify blocks #5,#6 Running transaction 5 6 Main memory begin On-disk journal end 1 3 2 4 54

  25. Ext4 Journaling: Global Order Further application writes Application A Application B recorded in new running Modify blocks #1,#3 transaction and committed Modify blocks #2,#4 fsync() Modify blocks #5,#6 Running transaction Main memory begin begin On-disk journal end end 1 3 2 4 5 6 55

  26. Ext4 Journaling: Global Order On system crash, on-disk journal transactions recovered atomically, in sequential order Running transaction Main memory begin begin On-disk journal end end 1 3 2 4 5 6 56

  27. Ext4 Journaling: Global Order On system crash, on-disk journal transactions recovered atomically, in sequential order Global ordering is maintained! Running transaction Main memory begin begin On-disk journal end end 1 3 2 4 5 6 57

  28. CCFS: Stream Order CCFS maintains separate running Application A Application B transaction per stream set_stream(A) set_stream(B) Modify blocks #1,#3 Modify blocks #2,#4 stream-A transaction stream-B transaction 1 3 2 4 Main memory On-disk journal 58

  29. CCFS: Stream Order On fsync(), only that stream is Application A Application B committed set_stream(A) set_stream(B) Modify blocks #1,#3 Modify blocks #2,#4 fsync() stream-A transaction stream-B transaction 1 3 2 4 Main memory On-disk journal 59

  30. CCFS: Stream Order On fsync(), only that stream is Application A Application B committed set_stream(A) set_stream(B) Modify blocks #1,#3 Modify blocks #2,#4 fsync() stream-A transaction stream-B transaction 1 3 Main memory begin On-disk journal end 2 4 60

  31. CCFS: Stream Order Ordering maintained within Application A Application B stream, re-order across streams! set_stream(A) set_stream(B) Modify blocks #1,#3 Modify blocks #2,#4 fsync() stream-A transaction stream-B transaction 1 3 Main memory begin On-disk journal end 2 4 61

  32. CCFS: Multiple Challenges Example: Two streams updating adjoining dir-entries Application A Application B set_stream(A) set_stream(B) create(/X/A) create(/X/B) 62

  33. CCFS: Multiple Challenges Example: Two streams updating adjoining dir-entries Application A Application B set_stream(A) set_stream(B) Block-1 (belonging to directory X) create(/X/A) create(/X/B) Entry-A Entry-B 63

  34. Challenge #1: Block-Level Journaling Two independent streams can Application A Application B update same block! set_stream(A) set_stream(B) create(/X/A) create(/X/B) Block-1 Entry-A Entry-B stream-A transaction stream-B transaction ? ? Main memory 64

  35. Challenge #1: Block-Level Journaling Two independent streams can Application A Application B update same block! set_stream(A) set_stream(B) create(/X/A) create(/X/B) Block-1 Entry-A Entry-B stream-A transaction stream-B transaction ? ? Main memory Faulty solution: Perform journaling at byte-granularity - Disables optimizations, complicates disk updates 65

  36. Challenge #1: Block-Level Journaling CCFS solution: Application A Application B Record running transactions at set_stream(A) set_stream(B) byte granularity create(/X/A) create(/X/B) stream-A transaction stream-B transaction Entry-A Entry-B Main memory 66

  37. Challenge #1: Block-Level Journaling CCFS solution: Application A Application B Record running transactions at set_stream(A) set_stream(B) byte granularity create(/X/A) create(/X/B) Commit at block granularity stream-A transaction stream-B transaction Entry-A Entry-B Main memory On-disk journal 67

  38. Challenge #1: Block-Level Journaling CCFS solution: Application A Application B Record running transactions at set_stream(A) set_stream(B) byte granularity create(/X/A) create(/X/B) Commit at block granularity stream-A transaction stream-B transaction Entry-A Entry-B Main memory Old version of entry-A Entry-A begin On-disk journal end Entry-B 68 Entire block-1 committed

  39. More Challenges ... 1. Both streams update directory’s modification date - Solution: Delta journaling 69

  40. More Challenges ... 1. Both streams update directory’s modification date - Solution: Delta journaling 2. Directory entries contain pointers to adjoining entry - Solution: Pointer-less data structures 70

  41. More Challenges ... 1. Both streams update directory’s modification date - Solution: Delta journaling 2. Directory entries contain pointers to adjoining entry - Solution: Pointer-less data structures 3. Directory entry freed by stream A can be reused by stream B - Solution: Order-less space reuse 71

  42. More Challenges ... 1. Both streams update directory’s modification date - Solution: Delta journaling 2. Directory entries contain pointers to adjoining entry - Solution: Pointer-less data structures 3. Directory entry freed by stream A can be reused by stream B - Solution: Order-less space reuse 4. Ordering technique: Data journaling cost - Solution: Selective data journaling [Chidambaram et al., SOSP 2013] 72

  43. More Challenges ... 1. Both streams update directory’s modification date - Solution: Delta journaling 2. Directory entries contain pointers to adjoining entry - Solution: Pointer-less data structures 3. Directory entry freed by stream A can be reused by stream B - Solution: Order-less space reuse 4. Ordering technique: Data journaling cost - Solution: Selective data journaling [Chidambaram et al., SOSP 2013] 5. Ordering technique: Delayed allocation requires re-ordering - Solution: Order-preserving delayed allocation 73

  44. More Challenges ... 1. Both streams update directory’s modification date - Solution: Delta journaling 2. Directory entries contain pointers to adjoining entry - Solution: Pointer-less data structures 3. Directory entry freed by stream A can be reused by stream B - Solution: Order-less space reuse 4. Ordering technique: Data journaling cost - Solution: Selective data journaling [Chidambaram et al., SOSP 2013] 5. Ordering technique: Delayed allocation requires re-ordering - Solution: Order-preserving delayed allocation Details in the paper! 74

  45. Outline Introduction Background Stream API Crash-Consistent File System Evaluation Conclusion

  46. Evaluation 1. Does CCFS solve application vulnerabilities? 76

  47. Evaluation 1. Does CCFS solve application vulnerabilities? - Tested five applications: LevelDB, SQLite, Git, Mercurial, ZooKeeper - Method similar to previous study ( ALICE tool) [Pillai et al., OSDI 2014] - New versions of applications - Default configuration, instead of safe configuration 77

  48. Evaluation 1. Does CCFS solve application vulnerabilities? Vulnerabilities Application ext4 ccfs LevelDB 1 0 SQLite-Roll 0 0 Git 2 0 Mercurial 5 2 ZooKeeper 1 0 78

  49. Evaluation 1. Does CCFS solve application vulnerabilities? Ext4: 9 Vulnerabilities Vulnerabilities - Consistency lost in LevelDB Application ext4 ccfs - Repository corrupted in Git, Mercurial LevelDB 1 0 - ZooKeeper becomes unavailable SQLite-Roll 0 0 Git 2 0 Mercurial 5 2 ZooKeeper 1 0 79

  50. Evaluation 1. Does CCFS solve application vulnerabilities? Ext4: 9 Vulnerabilities Vulnerabilities - Consistency lost in LevelDB Application ext4 ccfs - Repository corrupted in Git, Mercurial LevelDB 1 0 - ZooKeeper becomes unavailable SQLite-Roll 0 0 CCFS: 2 vulnerabilities in Mercurial Git 2 0 - Dirstate corruption Mercurial 5 2 ZooKeeper 1 0 80

  51. Evaluation 2. Performance within an application - Do false dependencies reduce performance inside application? - Or, do we need more than one stream per application? 81

  52. Evaluation 2. Performance within an application Throughput: normalized to ext4 (Higher is better) ext4 ccfs 82

  53. Evaluation 2. Performance within an application Throughput: normalized to ext4 (Higher is better) ext4 ccfs Real applications Standard benchmarks 83

  54. Evaluation 2. Performance within an application Standard workloads: Similar performance Throughput: normalized to ext4 for ext4, ccfs (Higher is better) But ext4 re-orders! ext4 ccfs 84

  55. Evaluation 2. Performance within an application Git under ext4 is slow because of safer Throughput: normalized to ext4 configuration needed for correctness (Higher is better) ext4 ccfs 85

  56. Evaluation 2. Performance within an application SQLite and LevelDB : Similar performance Throughput: normalized to ext4 for ext4, ccfs (Higher is better) ext4 ccfs 86

  57. Evaluation 2. Performance within an application But, performance can be improved with Throughput: normalized to ext4 IGNORE_FSYNC and stream_sync()! (Higher is better) ext4 ext4 ccfs ccfs ccfs+ 87

  58. Evaluation: Summary Crash consistency: Better than ext4 - 9 vulnerabilities in ext4, 2 minor in CCFS Performance: Like ext4 with little programmer overhead - Much better with additional programmer effort More results in paper! 88

  59. Conclusion FS crash behavior is currently not standardized 89

  60. Conclusion FS crash behavior is currently not standardized Ideal FS behavior can improve application consistency 90

  61. Conclusion FS crash behavior is currently not standardized Ideal FS behavior can improve application consistency Ideal FS behavior is considered bad for performance 91

  62. Conclusion FS crash behavior is currently not standardized Ideal FS behavior can improve application consistency Ideal FS behavior is considered bad for performance Stream abstraction and CCFS solve this dilemma 92

  63. Conclusion FS crash behavior is currently not standardized Ideal FS behavior can improve application consistency Ideal FS behavior is considered bad for performance Stream abstraction and CCFS solve this dilemma Thank you! Questions? 93

  64. Examples 1. LevelDB: a. creat(tmp); write(tmp); fsync(tmp); rename(tmp, CURRENT); --> unlink(MANIFEST-old); i. Unable to open the database b. write(file1, kv1); write(file1, kv2); --> creat(file2, kv3); i. kv1 and kv2 might disappear, while kv3 still exists 2. Git: a. append(index.lock) --> rename(index.lock, index) i. “Corruption “ returned by various Git commands b. write(tmp); link(tmp, object) --> rename(master.lock, master) i. “Corruption “ returned by various Git commands 3. HDFS: a. creat(ckpt); append(ckpt); fsync(ckpt); creat(md5.tmp); append(md5.tmp); fsync(md5.tmp); rename(md5.tmp, md5); --> rename(ckpt, fsimage); i. Unable to boot the server and use the data

  65. File System Study: Results Atomicity One sector overwrite: Atomic because File system One sector One sector Many sector Directory configuration of device characteristics overwrite append write operation async ✘ ✘ ✘ ext2 Appends: Garbage in some file systems sync ✘ ✘ ✘ writeback ✘ ✘ ext3 ordered ✘ File systems do not usually provide data-journal ✘ atomicity for big writes writeback ✘ ✘ ordered ✘ ext4 no-delalloc ✘ data-journal ✘ btrfs ✘ default ✘ xfs wsync ✘

  66. File System Study: Results Atomicity One sector overwrite: Atomic because File system One sector One sector Many sector Directory configuration of device characteristics overwrite append write operation async ✘ ✘ ✘ ext2 Appends: Garbage in some file systems sync ✘ ✘ ✘ writeback ✘ ✘ ext3 ordered ✘ File systems do not usually provide data-journal ✘ atomicity for big writes writeback ✘ ✘ ordered ✘ ext4 Directory operations are usually atomic no-delalloc ✘ data-journal ✘ btrfs ✘ default ✘ xfs wsync ✘

  67. Collecting System Call Trace git add file1 Application Workload Record strace, memory accesses (for mmap writes), initial state of datastore Trace Initial state creat(index.lock) creat(tmp) .git/... append(tmp, data, 4K) fsync(tmp) link(tmp, permanent) append(index.lock) rename(index.lock, index)

  68. Calculating Intermediate States a. Convert system calls into atomic modifications creat(index.lock) creat(inode=1, dentry=index.lock) creat(tmp) creat(inode=2, dentry=tmp) append(tmp, 4K) truncate(inode=2, 1) truncate(inode=2, 2) ... truncate(inode=2, 4K) write(inode=2, garbage) write(inode=2, actual data) ... fsync(tmp) link(tmp, permanent) link(inode=2, dentry=permanent) ... ...

  69. Calculating Intermediate States b. Find ordering dependencies creat(index.lock) creat(inode=1, dentry=index.lock) creat(tmp) creat(inode=2, dentry=tmp) append(tmp, 4K) truncate(inode=2, 1) truncate(inode=2, 2) ... truncate(inode=2, 4K) write(inode=2, garbage) write(inode=2, actual data) ... fsync(tmp) link(tmp, permanent) link(inode=2, dentry=permanent) ... ...

  70. Calculating Intermediate States c. Choose a few sets of modifications obeying dependencies Set 1: creat(inode=1, dentry=index.lock) creat(inode=1, dentry=index.lock) creat(inode=2, dentry=tmp) <all truncates and writes to inode 2> truncate(inode=2, 1) Set 2: truncate(inode=2, 2) ... creat(inode=1, dentry=index.lock) truncate(inode=2, 4K) <all truncates and writes to inode 2> write(inode=2, garbage) link(inode=2, dentry=permanent) write(inode=2, actual data) Set 3: ... creat(inode=1, dentry=index.lock) creat(inode=2, dentry=tmp) link(inode=2, dentry=permanent) ... truncate(inode=2, 1) ... more sets

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend

The problem: crash consistency Single operaBon updates mulBple blocks System might crash in

The problem: crash consistency Single operaBon updates mulBple blocks System might crash in

Consistency Without Ordering Vijay Chidambaram, Tushar Sharma, Andrea ArpaciDusseau, Remzi ArpaciDusseau The Advanced Systems Laboratory University of Wisconsin Madison The problem: crash consistency Single operaBon updates mulBple

953 views • 49 slides
Optimistic Crash Consistency Vijay Chidambaram Thanumalayan Sankaranarayana Pillai Andrea

Optimistic Crash Consistency Vijay Chidambaram Thanumalayan Sankaranarayana Pillai Andrea

Optimistic Crash Consistency Vijay Chidambaram Thanumalayan Sankaranarayana Pillai Andrea Arpaci-Dusseau Remzi Arpaci-Dusseau Crash Consistency Problem Single file-system operation updates multiple on-disk data structures System may crash

1.29k views • 83 slides
TxFS: Leveraging File-System Crash Consistency to Provide ACID Transactions Yige Hu, Zhiting

TxFS: Leveraging File-System Crash Consistency to Provide ACID Transactions Yige Hu, Zhiting

TxFS: Leveraging File-System Crash Consistency to Provide ACID Transactions Yige Hu, Zhiting Zhu, Ian Neal, Youngjin Kwon, Tianyu Chen, Vijay Chidambaram, Emmett Witchel The University of Texas at Austin 1 Crash Applications need crash

819 views • 30 slides
Web Cache Consistency Web Cache Consistency Web Cache Consistency Web Cache Consistency

Web Cache Consistency Web Cache Consistency Web Cache Consistency Web Cache Consistency

Web Cache Consistency Web Cache Consistency Web Cache Consistency Web Cache Consistency Requirements of performance, availability, and disconnected operation require us to relax the goal of semantic transparency. - HTTP 1.1 specification

598 views • 13 slides
to Systematically Test File-System Crash Consistency Ashlie Martinez Vijay Chidambaram

to Systematically Test File-System Crash Consistency Ashlie Martinez Vijay Chidambaram

CrashMonkey: A Framework to Systematically Test File-System Crash Consistency Ashlie Martinez Vijay Chidambaram University of Texas at Austin Crash Consistency File-system updates change multiple blocks on storage Data blocks, inodes,

499 views • 46 slides
From Crash Consistency to Transactions Yige Hu Youngjin Kwon Vijay Chidambaram Emmett Witchel

From Crash Consistency to Transactions Yige Hu Youngjin Kwon Vijay Chidambaram Emmett Witchel

From Crash Consistency to Transactions Yige Hu Youngjin Kwon Vijay Chidambaram Emmett Witchel Persistent data is structured; crash consistency hard Structured data abstractions built on file system SQLite, BerkeleyDB...

468 views • 34 slides
Specifying and Checking File System Crash-Consistency Models James Bornholt Antoine Kaufmann

Specifying and Checking File System Crash-Consistency Models James Bornholt Antoine Kaufmann

Specifying and Checking File System Crash-Consistency Models James Bornholt Antoine Kaufmann Jialin Li Arvind Krishnamurthy Emina Torlak Xi Wang University of Washington File systems persist our data Application File System File systems

937 views • 91 slides
Specifying and Checking File System Crash-Consistency Models Steven Lang September 4, 2016

Specifying and Checking File System Crash-Consistency Models Steven Lang September 4, 2016

Specifying and Checking File System Crash-Consistency Models Steven Lang September 4, 2016 Specifying and Checking File System Crash-Consistency Models Johannes Gutenberg Universitt Mainz Motivation The problem: POSIX

982 views • 71 slides
Memory Consistency Models CSE 451 James Bornholt Memory consistency models The short version:

Memory Consistency Models CSE 451 James Bornholt Memory consistency models The short version:

Memory Consistency Models CSE 451 James Bornholt Memory consistency models The short version: Multiprocessors reorder memory operations in unintuitive, scary ways This behavior is necessary for performance Application programmers

803 views • 36 slides
Finding Crash-Consistency Bugs with Bounded Black-Box Testing Jayashree Mohan , Ashlie Martinez,

Finding Crash-Consistency Bugs with Bounded Black-Box Testing Jayashree Mohan , Ashlie Martinez,

Finding Crash-Consistency Bugs with Bounded Black-Box Testing Jayashree Mohan , Ashlie Martinez, Soujanya Ponnapalli, Pandian Raju, Vijay Chidambaram Crashes I crashed This is very File saved! important File missing Image

878 views • 87 slides
Understanding and Finding Crash-Consistency Bugs in Parallel File Systems Jinghan Sun , Chen Wang,

Understanding and Finding Crash-Consistency Bugs in Parallel File Systems Jinghan Sun , Chen Wang,

Understanding and Finding Crash-Consistency Bugs in Parallel File Systems Jinghan Sun , Chen Wang, Jian Huang, and Marc Snir University of Illinois at Urbana-Champaign Contact: Jinghan Sun (js39@illinois.edu) PFS failures are frequent and

912 views • 17 slides
1 Applications ? Trading Consistency for Performance Applications ? Trading Consistency for

1 Applications ? Trading Consistency for Performance Applications ? Trading Consistency for

Consistency in Replication Consistency in Replication ! Replication comes with consistency cost: Continuous Consistency Continuous Consistency ! Reasons for replication: Better performance and availability and Availability and Availability !

280 views • 6 slides
Consistency - Chapter 5 Introduce several notions of Local Consistency: arc consistency,

Consistency - Chapter 5 Introduce several notions of Local Consistency: arc consistency,

Constraints Course - Justin Pearson - Consistency 1 Consistency - Chapter 5 Introduce several notions of Local Consistency: arc consistency, hyper-arc consistency, k-consistency and strong k-consistency. Local

728 views • 37 slides
Constraint Programming - An overview Node-consistency Arc-consistency Path-consistency

Constraint Programming - An overview Node-consistency Arc-consistency Path-consistency

Constraint Programming - An overview Node-consistency Arc-consistency Path-consistency I-consistency Generalised Arc-consistency Bounds-Consistency Propagators: The COMET example 7 November 2011 Constraint Propagation

615 views • 60 slides
1 HTTP 1.1 Expiration and Validation in HTTP 1.1 HTTP 1.1 Expiration and Validation in HTTP 1.1

1 HTTP 1.1 Expiration and Validation in HTTP 1.1 HTTP 1.1 Expiration and Validation in HTTP 1.1

Web Cache Consistency Web Cache Consistency Requirements of performance, availability, and disconnected operation require us to relax the goal of semantic transparency. - HTTP 1.1 specification Web Cache Consistency Web Cache Consistency

280 views • 3 slides
Towards a General Consistency Management Framework in the Context of Database Application

Towards a General Consistency Management Framework in the Context of Database Application

Towards a General Consistency Management Framework in the Context of Database Application Evolution Anthony Cleve 10th December 2007 Joint work with Ragnhild Van Der Straeten (VUB) Jean-Luc Hainaut 1 Computer Science Faculty University of

488 views • 31 slides
Overview of IKEv2 Dan Harkins Charlie Kaufman Radia Perlman 1 Radia Perlman A n a l y s i s

Overview of IKEv2 Dan Harkins Charlie Kaufman Radia Perlman 1 Radia Perlman A n a l y s i s

A n a l y s i s o f I K E Overview of IKEv2 Dan Harkins Charlie Kaufman Radia Perlman 1 Radia Perlman A n a l y s i s o f I K E What we were trying to do Consolidate RFCs 2407, 2408, and 2409 in one document Not make gratuitous

643 views • 16 slides
2019 Academic Advising In Service Training June 18th &amp; 19th Hosted by the Office of Campus

2019 Academic Advising In Service Training June 18th &amp; 19th Hosted by the Office of Campus

2019 Academic Advising In Service Training June 18th &amp; 19th Hosted by the Office of Campus Advising Coordination Why were here Why were focusing on the 4th year Focus on Advising NACADAs Concept of Advising Advising as a

989 views • 79 slides
State of Multicore OCaml KC Sivaramakrishnan University of OCaml Labs Cambridge Outline

State of Multicore OCaml KC Sivaramakrishnan University of OCaml Labs Cambridge Outline

State of Multicore OCaml KC Sivaramakrishnan University of OCaml Labs Cambridge Outline Overview of the multicore OCaml project Multicore OCaml runtime design Future directions Multicore OCaml Multicore OCaml Add native

932 views • 62 slides
Your Resume or CV as an Undergrad or Recent Grad Whats Your Spark? This Lesson: Read OR

Your Resume or CV as an Undergrad or Recent Grad Whats Your Spark? This Lesson: Read OR

How to W Walk Through Your Resume or CV as an Undergrad or Recent Grad Whats Your Spark? This Lesson: Read OR Watch It This video walks you through the key points of our undergrad/recent grad templates but its not really

234 views • 12 slides
BEYOND MAJOR AND MINOR 21 st -Century Elementary Music Textbooks by Diane M. Lange Expanding

BEYOND MAJOR AND MINOR 21 st -Century Elementary Music Textbooks by Diane M. Lange Expanding

An Examination of the Tonalities and Meters in BEYOND MAJOR AND MINOR 21 st -Century Elementary Music Textbooks by Diane M. Lange Expanding Musical There is a rich history of songs tonalities. Publishers of kindergarten and throughout the

190 views • 4 slides
POLITICAL Everything youll need to do to graduate is listed in your catalog SCIENCE

POLITICAL Everything youll need to do to graduate is listed in your catalog SCIENCE

SDSU 2020 THE CATALOG POLITICAL Everything youll need to do to graduate is listed in your catalog SCIENCE https://curriculum.sdsu.edu/curriculum-services/general- catalog Use this, and your degree evaluation, throughout

308 views • 6 slides
Disclosures Arrhythmogenic Right Ventricular Cardiomyopathy: Abbott Labs: Grant support

Disclosures Arrhythmogenic Right Ventricular Cardiomyopathy: Abbott Labs: Grant support

9/14/2019 Disclosures Arrhythmogenic Right Ventricular Cardiomyopathy: Abbott Labs: Grant support Diagnosis Harikrishna Tandri Associate Professor of Medicine Director of VT Ablation Johns Hopkins Medical Institutions www.ARVD.com

582 views • 10 slides
and Monitoring wit ith Streaming Spatiotemporal Data Nan Cao, Chaoguang Lin, Quihan Zhu, Yu-Ru

and Monitoring wit ith Streaming Spatiotemporal Data Nan Cao, Chaoguang Lin, Quihan Zhu, Yu-Ru

Voila: Vis isual Anomaly Detection and Monitoring wit ith Streaming Spatiotemporal Data Nan Cao, Chaoguang Lin, Quihan Zhu, Yu-Ru Lin, Xian Teng, Xidao Wen. IEEE Transactions on Visualization and Computer Graphics (Volume: PP, Issue: 99)

388 views • 13 slides

More recommend