What matklad said as a footnote deserves a little more attention!
A huge benefit is having to think and be explicit about the limits up front. To take your example of arbitrary sized JSON and flip it around: how would you do it normally?
Maybe, you'd allocate a buffer to hold your entire object when it comes in - but now you'll end up crashing when you get a large document that exceeds your available memory.
Maybe you can do things in a fixed amount of memory, using streaming or chunking - which would be pretty simple to turn to static allocation!
Static allocation forces understanding of those limits upfront.
We use them heavily for test boxes and running experiments. Standard off-the-shelf machines are provisioned almost instantly, and never had any problems.
More custom stuff (eg 100Gb/s NICs) takes a bit longer, but they've always been super responsive and quick to sort out any issues!
The price / performance you get from something like their AX162 is just crazy, although unfortunately with the whole RAM / NVMe shortage the setup fee has gone up quite a lot.
Actual SIGSEGVs are pretty rare, even during development. There was a pretty interesting one that affected our fuzzing infra a little bit ago: https://ziggit.dev/t/stack-probe-puzzle/10291
Almost all of the time we hit either asserts or panics or other things which trigger core dumps intentionally!
That's the opposite of my experience. Depending on the decoder, lower resolutions may be more efficiently handled by the CPU instead of the hardware decoder (which is a decent chunk of silicon and takes extra power to use). But once you hit a certain resolution, the hardware decoder is pretty much always way more efficient than a software CPU decoder. Some well-implemented hardware decoders even handle low resolutions more efficiently.
My experience is largely focused on battery-powered mobile devices (Android/iOS), though.
To give a concrete example, VAAPI Haswell integrated graphics, peak CPU usage:
mpv hardware H.264 1080p60: 3% CPU usage
mpv software H.264 1080p60: 20% CPU usage
mpv hardware H.264 4K60: 96% CPU usage
mpv software H.264 4K60: 80% CPU usage
There comes a point of diminishing (or in this case, negative) returns. A bit more subjectively, the H.264 software rendering at 4K60 also felt smoother.
I'm using H.264 as it is hardware accelerated on this platform.
I don't think all Haswell chips support 4k H.264. That's one downside of hardware decoders: they have limits on what they support. I suspect the decoder is actually falling back to a software implementation to handle the bitstream since the hardware can't.
I have desktop product that among other things decodes 4K60P using MMF. The decoding part either decodes straight into DirectX texture if hardware based video decoding is supported or does it in software otherwise.
Software based path causes significant CPU load. Using hardware path keeps CPU at about 0%. Since hardware video decoding supported nearly on any modern Laptop, Desktop I would say 4K60 is handled very efficiently.
> We've seen at least one person slightly tweak TigerBeetle to run on FreeBSD already through the darwin code paths.
I'm part of that sample set! Was quite surprised how easy it was to get it up and running on FreeBSD. Benchmarking on tmpfs on both, it even had a ~10% lead on Linux.
(Of course, that's not exactly the intended use case, so don't pay too much attention to that number!)
I too was initially put off by those requirements. Now we run our Nomad server on a single t3.medium instance that sits at a 0.1 15 minute load average and has ~500MB of RAM used.
This manages about 100 client nodes. No need for a cluster since we don't need high availability on our control plane, and there's no actual state stored there that isn't created from our CI pipeline.
Glad you went for it despite our poor documentation cb22! That sounds like a great setup. I think the only defensible way to describe our "Requirements" page is that we wanted to make the safest suggestion for the widest range of users. Obviously it's wildly inaccurate for a wide range use cases, and we should fix that.
Nomad servers could start with 300mhz, 100mb of memory, and eMMC storage and run a RaspberryPI cluster just fine. Our most important resource guidance is all the way over in our Monitoring docs!
> Nomad servers' memory, CPU, disk, and network usage all scales linearly with cluster size and scheduling throughput.
Any cluster can start with 300mhz and 100mb as long as they monitor usage and scale appropriately.
We're going to try to update our Requirements docs to add this nuance and guidance on how to calculate requirements based on projected load. We recently spent some time improving our heartbeat docs, and I think the approach we took there will serve us well for system requirements: https://developer.hashicorp.com/nomad/docs/configuration/ser...
Thank you for the follow up! This makes it much more likely that I’ll remember to give it a shot when the next applicable project comes up… Because I’ll probably have forgotten these comments and gone to check the docs again :-)
See this is the sort of information that they should have posted on the requirements page. Not some arbitrary sized high water mark needing gigs of disk and memory. I'll have to give using Nomad (and Consul) another go next time, and test it on physical hardware to see.
Thanks for the info! and for doing what Hashicorp seemed too busy to do themselves.
Can't speak for the online side of things, but it's possible to use most Garmin watches fully offline.
I'm not talking about a reduced functionality style offline mode either; the watch computes all metrics locally, you can load OSM for navigation, copy MP3 files to it and copy GPX traces off of it.
Android (and BlackBerry before that) have had something similar to this for a while.
On a BlackBerry, it would shut down the radio and give you a "Battery too low for radio use" message, but you could trick it into turning the radios back on by dialing 911 and then hanging up really quickly.
Various Android manufacturers do their own version of this, Sony had Ultra STAMINA mode and Samsung have an option to do a whole bunch of power optimizations as well as limit apps to those explicitly specified.
For me, the main critical purpose of my phone is to communicate with others in realtime which happens using things like WhatsApp, Slack or Email (maybe the odd call). If I can't use those, then it might as well be dead!
> I’d rather just put a normal Linux distro there, however, I’m not feeling like waiting 8 seconds every time I turn in my car.
I've been working on a Pi Zero W based carputer (really, it's headless and just interfaces with my phone over Bluetooth / the existing radio head unit and steering wheel menu and controls).
Boot time is probably around ~8 second mark currently (fully booted with buildroot / systemd, it's powered from 12V switched by the key) and it already feels fast enough. I normally start my car, put on my seat belt and look around. By the time I've finished doing that it has connected to my phone.
Of course, it would be possible to do even smarter things. Hook up a low power micro that can interface with the CAN bus and a MOSFET, and you can instead power it from the battery and turn it on when the car is unlocked and off after a timeout based on the engine going off.
To give some numbers to the comment I made previously in this thread, with an XPS 7390 2-in-1:
Single core turbo 3.9GHz, maintains indefinitely, temperature hovers around ~75 degrees, fans around 5000RPM
All core turbo: Keeps 3.4GHz and ~45W TDP for around 10 seconds, before dropping to 2.7GHz and ~25W TDP indefinitely. Temps still around ~75, with the fans around 8000 RPM.
That's without any undervolting, but with the processor set for 25W TDP (like the Windows "Ultra Performance" mode). Adding in some undervolting gets the all core turbo up to 2.9GHz.
Can you tell me what you did to set it to 25watt? I swear I've tried this a few times going through Throttlestop tutorials with different usb-c chargers (from the stock 67w up to 97w) and either that option was greyed out or I never got it to actually do 25w.
A huge benefit is having to think and be explicit about the limits up front. To take your example of arbitrary sized JSON and flip it around: how would you do it normally?
Maybe, you'd allocate a buffer to hold your entire object when it comes in - but now you'll end up crashing when you get a large document that exceeds your available memory.
Maybe you can do things in a fixed amount of memory, using streaming or chunking - which would be pretty simple to turn to static allocation!
Static allocation forces understanding of those limits upfront.