Differences
This shows you the differences between two versions of the page.
|
ep:labs:05:contents:tasks:ex2 [2019/10/27 17:10] emilian.radoi created |
ep:labs:05:contents:tasks:ex2 [2026/03/30 22:16] (current) radu.mantu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ==== 02. [30p] Gnuplot bar graphs ==== | + | ==== 02. [20p] RAM disk ==== |
| - | + | ||
| - | Use Gnuplot and the data from {{:ep:labs:ep_lab5_autodata.txt|autoData.txt}} to generate separate **bar** graphs for the following: | + | |
| - | * The "//MidPrice//" of all the "//small//" cars. | + | |
| - | * The average fuel consumption (MPG - miles per gallon) for all the "//large//" cars. | + | |
| - | * The "//MaxPrice//" over the average fuel consumption for all "//chevrolet//" and "//ford//" cars. | + | |
| - | + | ||
| - | The graphs should be as complete as possible (title, axes names, etc.) | + | |
| + | Linux allows you to use part of your RAM as a block device, viewing it as a hard disk partition. The advantage of using a RAM disk is the **extremely low latency** (even when compared to SSDs). The disadvantage is that all contents will be lost after a reboot. | ||
| <note tip> | <note tip> | ||
| - | **Hint:** Gnuplot conditional plotting. | + | There are two main types of RAM disks: |
| + | * **ramfs** - cannot be limited in size and will continue to grow until you run out of RAM. Its size can not be determined precisely with tools like **df**. Instead, you have to estimate it by looking at the "cached" entry from **free**'s output. | ||
| + | * **tmpfs** - newer than **ramfs**. Can set a size limit. Behaves exactly like a hard disk partition but can't be monitored through conventional means (i.e. **iostat**). Size can be precisely estimated using **df**. | ||
| </note> | </note> | ||
| + | === [10p] Task A - Create RAM Disk === | ||
| - | <solution -hidden> | + | Before getting started, let's find out the file system that our root partition uses. Run the following command (T - print file system type, h - human readable): |
| + | |||
| + | <code bash> | ||
| + | $ df -Th | ||
| + | </code> | ||
| + | The result should look like this: | ||
| <code> | <code> | ||
| + | Filesystem Type Size Used Avail Use% Mounted on | ||
| + | udev devtmpfs 1.1G 0 1.1G 0% /dev | ||
| + | tmpfs tmpfs 214M 3.8M 210M 2% /run | ||
| + | /dev/sda1 ext4 218G 4.1G 202G 2% / <- root partition | ||
| + | tmpfs tmpfs 1.1G 252K 1.1G 1% /dev/shm | ||
| + | tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock | ||
| + | tmpfs tmpfs 1.1G 0 1.1G 0% /sys/fs/cgroup | ||
| + | /dev/sda2 ext4 923M 73M 787M 9% /boot | ||
| + | /dev/sda4 ext4 266G 62M 253G 1% /home | ||
| + | </code> | ||
| - | with boxes - pentru bar chart (set style fill solid - sa fie pline) | + | From the results, we will assume in the following commands that the file system is **ext4**. If it's not your case, just replace with what you have: |
| - | reset | + | <code bash> |
| + | $ sudo mkdir /mnt/ramdisk | ||
| + | $ sudo mount -t tmpfs -o size=1G ext4 /mnt/ramdisk | ||
| + | </code> | ||
| + | |||
| + | <note> | ||
| + | If you want the RAM disk to persist after a reboot, you can add the following line to ///etc/fstab//. Remember that its contents will still be lost. | ||
| + | |||
| + | <code> | ||
| + | tmpfs /mnt/ramdisk tmpfs rw,nodev,nosuid,size=1G 0 0 | ||
| + | </code> | ||
| + | </note> | ||
| - | set size 1, 1 | + | That's it. We just created a 1Gb **tmpfs** ramdisk with an **ext4** file system and mounted it at ///mnt/ramdisk//. Use **df** again to check this yourself. |
| - | set multiplot layout 2,2 rowsfirst | + | |
| - | set title 'Graph Small Cars' | + | === [10p] Task B - Pipe View & RAM Disk === |
| - | set xlabel 'Car' | + | |
| - | set ylabel 'MidPrice' | + | |
| - | unset key | + | |
| - | plot "data5.txt" using (strcol(4) eq "small" ? $6 : 0) w l lw 0.5 lc rgb 'red' | + | |
| - | set title 'Graph Fuel Consumption' | + | As we mentioned before, you can't get I/O statistics regarding **tmpfs** since it is not a real partition. One solution to this problem is using **pv** to monitor the progress of data transfer through a pipe. This is a valid approach only if we consider the disk I/O being the bottleneck. |
| - | set xlabel 'Car' | + | |
| - | set ylabel 'Fuel' | + | |
| - | unset key | + | |
| - | plot "data5.txt" using (strcol(4) eq "large" ? ($8 + $9)/2 : 0) w l lw 0.5 lc rgb 'blue' | + | |
| - | set title 'Graph Avg' | + | Next, we will generate 512Mb of random data and place it in ///mnt/ramdisk/file// first and then in ///home/student/file//. The transfer is done using **dd** with 2048-byte blocks. |
| - | set xlabel 'X' | + | |
| - | set ylabel 'Y' | + | |
| - | unset key | + | |
| - | plot "data5.txt" using (strcol(2) eq 'chevrolet' || strcol(2) eq "ford" ? $7 : 0) w l lw 0.5 lc rgb 'green', \ | + | |
| - | "data5.txt" using (strcol(2) eq 'chevrolet' || strcol(2) eq "ford" ? ($8 + $9)/2 : 0) w l lw 0.5 lc rgb 'orange' | + | |
| - | unset multiplot | + | <code bash> |
| + | $ pv /dev/urandom | dd of=/mnt/ramdisk/rand bs=2048 count=$((512 * 1024 * 1024 / 2048)) | ||
| + | $ pv /dev/urandom | dd of=/home/student/rand bs=2048 count=$((512 * 1024 * 1024 / 2048)) | ||
| </code> | </code> | ||
| - | </solution> | ||
| + | Look at the elapsed time and average transfer speed. What conclusion can you draw? | ||
