Presumably seconds since I'm not sure what else would make sense here. It'd also be helpful if the y axis had consistent scale between each graph and horizontal lines are set y axis intervals
The different X axes are because I figured there's no point having a bunch of graphs which are 90% empty. For a long time we only had base/UFS images. (Even arm64 came a few years later than amd64.)
Well start it at 0.00001 then. There's no need for a log axis, as all the values are within 2 orders of magnitude of each other - between 1 and 100. They will fit better, and will no longer be distorted, on a linear Y axis starting from zero.
Seconds was my best guess .. but that doesn't make it certain for the viewer.
No real drama, but FWiW I've looked at a lot of data across engineering, math, geophysics, mining, energy, etc and unlabeled data and graphs are a major annoyance.
Nice improvements in boot speed. Perhaps a little blurb / intro / summary would be helpful to the post to help with understanding the achievements made.
Did the patches ever make it into Firecracker for booting FreeBSD as a guest? I looked back at the paper trail and it seemed like it may have stalled.
Things stalled; there were a couple outstanding bugs (one I know has now been fixed, not sure about the other) and I had to take over FreeBSD release engineering and didn't have time to follow up on the Firecracker bits.
I understand that NetBSD can boot in Firecracker using the same patches so I'm hoping they can resolve any remaining issues and prod the Firecracker developers into merging things.
You’re getting progressively legacy (and more likely to be degraded) hardware. This impacts how tightly packed the instance type as a whole is, which impacts launch instance performance
Depends what you're trying to measure, I think? My goal as a FreeBSD developer is to look at FreeBSD performance -- this is both to show the improvements which have been made over the years and to alert me to any performance regressions (I generate these graphs automatically when I build the weekly snapshots).
If you want to compare EC2 to other clouds you would definitely want to use the latest instance generation, of course.
> They started out with around a three second kernel boot time but cut it down to just 300 ms. Among the optimizations carried out to really speed-up their boot time were ensuring more asynchronous driver probing, only initializing a small amount of RAM at start and then after booted hot-plug the rest of it in parallel via systemd, optimized root file-system mounting, disabling unnecessary kernel modules, and similar approaches. Moving forward they are still looking at optimizations for the boot process around in-kernel deferred memory initialization, SMP initialization changes, ACPI tweaking, and user-space/systemd optimizations.
That suits our deployments where for HA we simply terminate and replace unresponsive EC2 nodes with new ones. I’ll have to talk to other developers to see how much work would it be to compile to freebsd instead of Linux
I have no idea who you are, nor do I check who submits what (the merit of the argument, not who said it and all that), nor do I have a reason to know (I have no reason to follow FreeBSD at this point).
I understand you do important work, but some people, me included, do other stuff. And there's a lot of people here.
Seems zfs is quite a bit faster than ufs