(Topic ID: 210691)

What CPU do you use to run Mission Pinball Framework?

By Time

6 years ago



Topic Stats

  • 6 posts
  • 4 Pinsiders participating
  • Latest reply 6 years ago by Time
  • Topic is favorited by 7 Pinsiders

You

Linked Games

No games have been linked to this topic.

    #1 6 years ago

    Hi Guys,

    Just curious what CPUs you guys are using to run MPF on your home brews? I'm running a UDOO X86 Basic with Ubuntu and its fine but it doesn't seem really the pro way of doing things. Boot right now is around 30-40 seconds and seems kinda clunky. How are the manufactures pulling off 3-5 second boot times and has anyone replicated that with Mission Pinball Framework code?

    Thanks,
    - Jayson

    #2 6 years ago

    Hi Jayson,

    I'm running an Intel NuC i3 (7 gen) with SSD and 8GB RAM. It boots LUbuntu in about 3-4s. MPF (0.50/dev) takes another 2-3s. However, the hardware is clearly overpowered (300 bucks also) but I would recommend that during development (see: http://docs.missionpinball.org/en/dev/hardware/computer/index.html).

    Latest MPF versions (0.50-dev > dev-60) start much faster thanks to config caching (yaml parsing is slow). I will improve that further since there is still a lot low hanging fruit. We will add a production flag which will omit cache freshness checking and we will get asset files to improve performance on slow IO devices auch as SD cards (or any non-SSD device).

    Furthermore, LUbuntu is not a good embedded operating system. With a dedicated distribution (buildroot based or OpenEmbedded) you could easily boot my Intel NuC in less than 1s. Your board probably below 5s. This is something which I really would only do very late on since development on the system will become harder. Jimmy is maintaining such a distribution and can probably talk about it.

    Storage is critical to startup. SD cards are cheap but slow. Systems such as Spike 1 are taking quite long to boot because of they boot from a SD card (they masquerade that by showing stuff on the DMD early). Others such as TNA use faster storage. TNA uses eMMC which is more like a SSD.

    Short: With latest MPF and a dedicated distribution you should be able to achieve decent boot times. SSD also help if you can afford that.

    Jan

    #3 6 years ago

    I use a Raspberry Pi 3 but I don’t have any need for video.

    #4 6 years ago

    Raspberry Pi is probably on the lower end for MPF. Boot time is already decent with Raspbian or similar optimized debian flavours. MPF takes a while to boot because of slow storage. I would guess that you could hardly get boot time below 5s (including the game). Probably more like 10-15s depending on how many assets you need on start. MPF will certainly work on the RPi3 but MPF-MC is a bit tricky with all the OpenGL stuff. You can get it work for a production machine but it is not so much fun during development.

    #5 6 years ago

    Hey Jayson,

    I do most of the production operating system design implementations to-date for Spooky, American Pinball, Multimorphic and Valley-Dynamo. All of these companies have varying production needs for their systems, but in the end, the core is mostly the same.

    As others here have stated, it really depends on your game needs. Every game designer I've worked with has had to make tweaks to optimize their code for production, which often means choosing which assets to stream from disk (like video) versus which to preload into memory. Often times we're working with anywhere from 512mb to 2gb of ram (up to 8 in certain manufacturers cases), so they have to ration it. If you're going to use an SSD, you can stream things from disk all day long and the game will likely keep up. If you're using an SD card, that might be a tad difficult, so you'll want to preload more. If you're using eMMC, there will typically be a balance between the two, but the I/O is a bit faster. We use several tricks to get around this.

    Most of those developers, like yourself, first used Lubuntu because it was quick to develop on. I agree with this choice. Get off the ground quickly!

    Using something like a UDOO is actually not a bad idea as its a single board computer and you can compile a custom linux kernel for it. If you're wondering how we achieve 3-5 or even 10 second boot times, its generally because its running a custom linux distribution targeting the hardware its running on, and as such, it ONLY loads what it needs. For example, on a RPi3, on raspbian you're looking at 40-60 seconds even before the game starts to load. On Pinix (our custom operating system setup), its about 3 seconds from the time you power on to the time the OS starts loading the game.

    So, in summary, a few things to note:
    1. Using single board computers is a great idea if you can get the horsepower out of them. They're easy to compile custom linux kernels for
    2. eMMC is great if you can get it
    3. Using a custom distribution of linux also makes it easy to lock your file systems down to read-only mode to prevent drive corruption on power off
    4. Choose a SBC with good SDL2/OpenGL/OpenGLES support as thats typically the most painful part for machines that need video functionality

    -- Jimmy

    #6 6 years ago
    Quoted from jabdoa:

    Latest MPF versions (0.50-dev > dev-60) start much faster thanks to config caching

    Good to know. I hadn't experimented with dev releases yet. I've only been running the .33 listed as latest. Will give this a shot.

    Quoted from jabdoa:

    LUbuntu is not a good embedded operating system

    I'll give compiling on a different distro a try. Mainly want something that will have a clean boot. I thought about trying out Arch Linux.

    Quoted from jabdoa:

    SD cards are cheap but slow

    I'm using SSD for the OS but loading game code off SD. Was thinking SD wouldn't be a bottle neck since code is so small but I can test loading everything from the disk.

    Quoted from jabdoa:

    With latest MPF and a dedicated distribution you should be able to achieve decent boot times. SSD also help if you can afford that.

    Thank you, will experiment some more.

    Quoted from Compy:

    optimize their code for production, which often means choosing which assets to stream from disk (like video) versus which to preload into memory

    Good advice, I'll play with this. I haven't added in video assets yet but know that's coming.

    Quoted from Compy:

    Most of those developers, like yourself, first used Lubuntu because it was quick to develop on

    So far code has been developed on a Mac book air. Major development is still needed so nowhere near finalized. Just preparing and testing a solution for actual hardware.

    Quoted from Compy:

    eMMC is great if you can get it

    I ordered a second UDOO board with 4 cores, eMMC, and 4gb ram. Was initial thinking this would be overkill but maybe that eMMC will make a big difference.

    Quoted from Compy:

    lock your file systems down to read-only mode to prevent drive corruption on power off

    I figured I'd need to have a read-only OS at some point. I really need to do some research into this as I've never setup a machine to work that way. Right now I have game code reading off read-only SD card. I didn't want MPF saving log files there and I haven't searched the docs yet for a flag to turn those off. Its a hack solution I'm sure there are proper ways.

    Thanks for your advice everyone!

    - Jayson

    Reply

    Wanna join the discussion? Please sign in to reply to this topic.

    Hey there! Welcome to Pinside!

    Donate to Pinside

    Great to see you're enjoying Pinside! Did you know Pinside is able to run without any 3rd-party banners or ads, thanks to the support from our visitors? Please consider a donation to Pinside and get anext to your username to show for it! Or better yet, subscribe to Pinside+!


    This page was printed from https://pinside.com/pinball/forum/topic/what-cpu-do-you-use-to-run-mission-pinball-framework and we tried optimising it for printing. Some page elements may have been deliberately hidden.

    Scan the QR code on the left to jump to the URL this document was printed from.