Rendered at 21:02:23 GMT+0000 (Coordinated Universal Time) with Wasmer Edge.
nijave 7 days ago [-]
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
Seems zfs is quite a bit faster than ufs
cperciva 7 days ago [-]
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.)
mkesper 6 days ago [-]
But you aren't able to compare them then.
bas 7 days ago [-]
Your FreeBSD on AWS work is appreciated, @cperciva.
defrost 7 days ago [-]
That's an impressive drop from 30 minutes in 2019 to under 10 minutes today.
No, wait .. maybe that's seconds? milliseconds?
cperciva 7 days ago [-]
Seconds, yes. Sorry I figured that was obvious, I'll add it to the graphs I generate next week.
amiga386 7 days ago [-]
If you're taking requests, then can the Y axis start at zero, please?
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.
defrost 7 days ago [-]
Good to hear.
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.
7 days ago [-]
tourist2d 7 days ago [-]
[dead]
wright08 7 days ago [-]
[flagged]
pushupentry1219 7 days ago [-]
Thank you! Was about to ask for axis labels as well. I assumed seconds but I had some doubts because there were no labels!
wright08 6 days ago [-]
I wouldn't bother. It is super obvious.
spease 7 days ago [-]
Microts!
alexellisuk 7 days ago [-]
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.
Does anyone know?
cperciva 7 days ago [-]
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.
nostrebored 7 days ago [-]
Fixing instance types was probably wrong.
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
cperciva 7 days ago [-]
Fixing instance types was probably wrong.
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.
silisili 7 days ago [-]
Would be nice to see how this compares to Linux, I think, for perspective.
> 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.
The best summary I can provide is "profiling and lots of small wins".
Temporary_31337 7 days ago [-]
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
On a more serious note, the only thing that really makes sense would be seconds.
pluto_modadic 7 days ago [-]
wow they make it impressively hard to contact them.
cperciva 7 days ago [-]
me @FreeBSD.org. I figured most people reading this would know who I am.
tpxl 6 days ago [-]
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
No, wait .. maybe that's seconds? milliseconds?
https://handsondataviz.org/images/14-detect/gdp-baseline-mer...
And what is going on with that Y axis? There is no consistent spacing between the marks!
https://imgur.com/HaJmTSU
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.
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.
Does anyone know?
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.
Re-running the comparison with Linux AMIs from 2024 is on my to-do list.
> 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.
https://lwn.net/Articles/299483
If not, which is understandable, is there something specific to stable/14 for interested parties to familiarize themselves with?
The most accessible summary of his work is probably on his Patreon: https://www.patreon.com/c/cperciva/posts. If you go digging there are also some anecdotes on his Twitter too; most recent I can find is https://x.com/cperciva/status/1833735559614988526
There's also a somewhat out of date summary of most of the work on the FreeBSD wiki: https://wiki.freebsd.org/BootTime
On a more serious note, the only thing that really makes sense would be seconds.
I understand you do important work, but some people, me included, do other stuff. And there's a lot of people here.
https://news.ycombinator.com/item?id=35079
(And folks have had since 2007 to top it.)
Funny enough, that started with a "I don't know you" as well:
https://news.ycombinator.com/item?id=35071