Ken Moffat wrote: > As a non-statistician, what does the standard deviation mean in > this context ? e.g. diffutils chapter 5 SBU Average 0.1 SBU Std > Dev 0.6. I could understand 0.1 plus or minus 0.1 (well, any bigger > number plus or minus, 0.1 minus anything is technically below the > minimum), but I can't make any sense of '0.6'. > > Those figures look somewhat old, too (the presence of MAKEDEV). > > Anyway, for 6.3 I suppose we should continue to provide some > figures.
In on-technical terms, standard deviation is a measure of dispersion of the values. About 68% of all data will be within one standard deviation of the average. About 95% of all data will be within two standard deviations of the average. This assumes the data has "normal" variations. I used the standard deviation to just provide more information than just the arithmetic mean of the data input. This is not true if some LFSers run tests and others do not when collecting their data. On the other hand, if the standard deviations are relatively small, the user can be assured that the times are reasonably consistent. > 1. kernel headers - call it 304 MB and blame it on the new safer way > of installing. (reminder: chapter 5 too) > 2. glibc - I install _all_ locales, so I won't object that I'm using a > little more space, but I manage to do that in 14.3 SBU instead of > 19.5. Or maybe I'm missing the point about standard deviations ? > 3. gcc - for me, it takes 25.7 SBU not 22. > 4. db - 88MB rather than 77MB. > 5. e2fsprogs uses 46.9MB for me, not 31.2MB. > 6. coreutils takes 0.6 SBU, not 1.0 SBU - for consistency with item > 12 below, I think this is 70.7 or 71MB depending on how we are > currently rounding, otherwise I wouldn't get worked up about 1MB in > 70. > 7. perl takes 1.2 SBU for me rather than 1.5, which is just about > enough of a difference to notice. > 8. for me, bzip2 needs 6.4MB not 5.3MB - maybe somebody didn't > count the docs ? > 9. gettext for me took 1.3 SBU not 1.0 (again, just about enough to > notice the difference), and more importantly it needed 83.5MB > instead of 65MB. > 10. I'll treat my space difference on gzip as splitting hairs, > unless pressed (3.3MB for 2.2MB) > 11. inetutils for me needed 12.1 MB, not 8.9MB, and if I'm going to > change the figure it used 0.3 SBU for me, not 0.2. > 12. shadow took 0.5 SBU for me, not 0.3SBU, and if I'm going to > change it I think the space is 21.6MB (or 22MB if rounded?) Your values don't seem too much out of line. Your speeds seem to generally (not always) run a bit faster and use more disk space. It could be a difference in the way you measure, the amount of memory you have, the amount of cache, the disk sector sizes, disk cache, disk speed, etc. > For 7.0, I'll be happy to round future changes to 0.5 SBU, and go > with x86 space usage (nearest 1MB/10MB, or nearest 100MB for gcc and > glibc ?), but I don't think this thread is the right place to discuss > that. Perhaps we could develop a way to populate the SBU database with data extracted from jhalfs logs. I haven't looked into that though. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
