-
Mike Hibler authored
1. Implement PREQUEST message which passes a bit map of desired blocks. We still use the REQUEST message (start block + number of blocks) for full chunk requests as that is more efficient. This message also includes a flag indicating whether it is a retry of a request we originally made or not. This gives the server more accurate loss info. 2. More stats and tracing goo. Frisbee client: 1. Add 'C' and 'W' command line options to specify amount of memory for chunk buffers (network buffering) and for write buffers (disk buffering). The Emulab frisbee startup script uses these to partition up all the available memory on a machine. Previously we were just using a fixed ~128MB even though our machines have 256 or 512MB of memory. Also add the 'M' option which specifies the overall memory, internally dividing it up between chunk buffers and write buffers. 2. Add 'S' command line option to explicitly specify the server. This allows us to make a feeb...um, "lightweight" authentication check on incoming messages. 3. Use the common BlockMap data struct to track which pieces of a chunk we have received. This is easily inverted to make PREQUESTS and it is also smaller than the older byte-per-block technique. 4. Allow partial request-ahead. Previously, we only issued request-ahead if there were enough empty chunk buffers for a maximum (2) request-ahead. Frisbee server: 1. Use BlockMap for workQ elements. An easy way to allow a complete merge of incoming requests with existing ones. 2. Check for overlap of incoming requests with the request currently being serviced. This happens surprisingly often. 3. Dubious: burst gap becomes burst interval. The latter takes into account the time required to read data, etc., in other words, we now have variable-sized gaps and put out bursts at specific times rather than having fixed gaps and putting out bursts at variable times. This gives us more accurate pacing over shorter time periods. I thought this might be important for dynamic pacing. 4. Add 'W' command line option to specify a target bandwidth. Frisbeed will use this to calculate a burst size/interval. 5. Rewrote the dynamic pacing code. It is now easily as bad as before if not worse. But it does have fewer magic constants! Needs to be redone by someone who understands the TCP-friendly rate equation. Imagezip: 1. add 'R' option to specify one or more partitions for which to force raw (naive) compression even if the FS format is understood. Useful for benchmarking. 2. add 'D' option to allow "dangerous" writes. In this mode, we don't do the fsync's or retries of failed writes. Overrides the hack we put in for NFS. Use this if writing to a local filesystem (or /dev/null). 3. Eliminate an extra copy of every chunk header. Imageunzip: 1. Eliminate extra copy of decompressed data that we were doing between the single decompression buffer and the disk buffers. Helps on slow machines (like gatech's 300Mhz machines with 66MHz memory bus). 2. Allow dynamic number of variable-sized write buffers. Total memory not to exceed the writebufmem limit. Previously we had a small number of fixed-size (256K) buffers. 3. Add debugging 'C' option to just compute a single CRC of the decompressed image. Back-ported to older imageunzip and used to make sure my write buffer changes were correct. Maybe handy for similar massive changes in the future.
9e55b0b1