diff --git a/cst311/img/not.png b/cst311/img/not.png new file mode 100644 index 0000000..4cf1009 Binary files /dev/null and b/cst311/img/not.png differ diff --git a/cst311/lec/.lec9.md.swp b/cst311/lec/.lec9.md.swp new file mode 100644 index 0000000..036fa63 Binary files /dev/null and b/cst311/lec/.lec9.md.swp differ diff --git a/cst311/lec/lec8.md b/cst311/lec/lec8.md new file mode 100644 index 0000000..acaf9be --- /dev/null +++ b/cst311/lec/lec8.md @@ -0,0 +1,68 @@ +# lec8 + +_Continuing where lec7 left off, so keep that page handy._ +Covering some of the principles of reliable datat transfer. + +Typically we want a sending process to dump a message into a reliable channel so that a receiving process can process that message off that reliable channel(kind of like a pipe). +These processes would live in the _application layer_. + +## Working towards Error correction + +_This sub-section we'll build our way to a system of dealing with errors from nearly nothing up to soething that could reasonably work._ + +### V 2.2 + +Now instead of having `NACK` we have the recevier send two `ACK` of the previous good packet received. +At this point our newly updated _standard_ will make the sender hang for a bit and the second `ACK` will confirm for the sender that the previous packet should be resent. + +### V 3.0 + +Timeout: if a sender does not receive anything in some alotted time frame we should resend, replacing the double `ACK` from before. + + +## TODO: FIX THIS WHOLE SUBSECTION +## Errors + + +First we'll assume that we're not losing pacckets but only getting errors. + +The receiver can try using a checksum to verify the packet was received. +This means we now have `ACK`s to acknowledge good data transfer, however for bad packets we have `NACK` saying that there was error with the checksum. + +> What if the ACK/NACK is corrupted? + +At this point we have to implement some kind of control sequence to show that one packet comes after another. +Each packet in a sequence can now be given a sequence number so that the receiver knows what to request if something goes wrong in the communication. + +Now we can validate checksums and have sequence numbers however, if that ACK is corrupted from receiver to sender then we, _as the sender_, must resend the packet. +We only resend that packet in the sequence if the receiver requests the packet. +On the receiver side that looks like this: +* get packet who's checksum fails +* send ok for _previous_ packet + +### Timeout + +Say we send a packet but never get an acknowledgement of the receival we can resend after some alotted time. +``` +a -> send(p0) -> b +a <- ack(p0) <- b +a -> send(p1) -> b +. +. +. +a -> resend(p1) -> b +``` + +### Performance + +Up until now we have checksums, timeouts, ACK's and the ability to resend. +What does the performance look like at this point? +``` +U_sender = (L/R)/(RTT+(L/R)) +``` + +L=length of packet +R=link speed +RTT=Round-Trip Time + + diff --git a/cst311/lec/lec9.md b/cst311/lec/lec9.md new file mode 100644 index 0000000..6536d2e --- /dev/null +++ b/cst311/lec/lec9.md @@ -0,0 +1,102 @@ +# lec9 + +This lecture has a corresponding activity found in `lab/` it is called `combinational-logic.md`. +It is more useful to practice combinational logic as opposed to read about it so the sub section here will be minimal in information. +It's recommended that you try as many of the problems in the activity until you understand the concept, _don't bother doing them all_. + +## Combinational Logic + +### OR + +`a+b` is equivalent to saying `a` or `b`. + +### AND + +`ab` is equivalent to saying `a` and `b`. + +Note that this syntax is simlar to multiplication so `a*b` is equivalent to the above. + +### NOT + +`!a` is equivalent to saying not `a`. +We can also denote it with a bar over the expression we want to _not_. + +![Figure-Not](../img/syn-not.png) + +## Decoders + +Here we'll learn by doing + +``` +Selector = 2 Bits +Output = 4 Bits +``` +As a challenge you can try using the combinational logic gates from above to try and tackle this yourself +s1 |s2 |o3 |o2 |o1 |o0 + 0 | 0 | 0 | 0 | 0 | 1 + 0 | 1 | 0 | 0 | 1 | 0 + 1 | 0 | 0 | 1 | 0 | 0 + 1 | 1 | 1 | 0 | 0 | 0 + + +## Multiplexor + +Typically we'll refer to multiplexors by their size. + +> what does it do? + +It takes a signal as `2^n` inputs and out puts out `n` signals as output. + +Example: We have a selector(s0), two inputs[in0 & in1], and one output `out`. +The selector will select an input and we will generate some output in `out`. + +s0 | i0 | i1 | out +0 | 0 | 0 | 0 +0 | 0 | 1 | 1 +0 | 1 | 0 | 0 +0 | 1 | 1 | 1 +1 | 0 | 0 | 0 +1 | 0 | 1 | 0 +1 | 1 | 0 | 1 +1 | 1 | 1 | 1 + + +This ultimately lets us pick data out of memory given some address. + +## Half Adder + +For now we'll take two inputs and get 1 output, with a carry-output. + +Let's add 2 bits + +ab |out +00 |0 +01 |1 +10 |1 +11 |0 + +What about the carry bit however? What would _it_ look like given the preivous operations? + +ab |carryout +00 |0 +01 |0 +10 |0 +11 |1 + +Before what this implies note that the result of the carryout resembles + +## Full Adder + +Two inputs, One output, One carry-out, One carry-in + +Here we'll add up `a & b`(inputs) and `c` carry-in + +cab |output +000 |0 +001 |1 +010 |1 +011 |0 +100 |1 +101 |0 +110 |0 +111 |1