We’re about to test our a Mark II with a 4GB Raspberry Pi. Love the modularity that makes choices like swapping out the Pi possible. 
We’ll share our results, and are very interested to hear how it runs with an 8GB if you do set that up on yours.
tested 4GB and the free SSD and it does not boot at all
I juts get a spinning disk of doom - note I left it for at least 5 hours
That is very frustrating. IME if a drive doesn’t start booting within 2 minutes, it’s not going to.
Can you possibly email me a photo of the drive so I can track which batch it was from? I’ll send a replacement, and if you’d like to try re-imaging the drive that might work. We’ve found that because the space taken by the OS is so small compared to the size of the drive, if there is a small bad area in the drive there may still be plenty of space. clary@neon.ai
Yeah I tried reimaging the drive and also tried other OS and the same issue
I’m away from home at the moment but I’ll be sure to send a photo of the drive when I get home
hi @NeonClary
I have been doing some analysis on the device using the recent v2.0 build, and I have uncovered a few things.
The resource load on CPU is very high in certain circumstances:
Green Lines indicate action points - From Left to Right:
- Voice Command Soma FM - nothing happens
- Manual Command Soma FM - screen locks up
- Audio starts playing - Soma FM
As you can see the initiation of a radio channel pushes the CPU through the roof and on occasion, dependent on button bashing, it never recovers.
In all it takes about 15-20mins for te device to fully load and push the clock to the screen - that’s a long time IMHO
What I have done is use the telemetry to asses which PIDs were creating the high usage and you have about 9 neon services that are contributing to the overload on CPU.
Based on my analysis I have now limited the cpu quota for those offending the services to test and see what that does - ill update as and when I have any more results.
Additionally here is the Memory overview when running the system on the 4GB Pi4 - as you can see its topping out, so the 2GB Pi that everyone has is not fit for purpose:
Update:
fixing the CPU quota to services is harmful to the system, so I have reverted back.
The latency between pressing screen buttons and actually getting a response is very poor at the moment, but as this is v2.0 potentially there will be improvements along the way:
Image - timeline 15mins
Left to Right Green Lines:
- Pressed bottom of screen and selected Audio
- Pressed Skills button
- Pressed Soma FM
- Pressed Secret Agent
- Got bored so started button bashing the play
- Music start playing
After a while it does settle but we still see spikes every 10 seconds:
Image - timeline 1min
the assessment is that the following neon services are the culprits:
IMPORTANT: dont do anything else during any wait times or you’ll just end up flatlining the CPU:
3 Likes
Thank you @oneofthemany, appreciate the input! If you have time to look at more cases, I wonder if you could do a similar dig into the system data in two different situations -
Alternate Case 1: Using a different skill, such as playing music from freemusicarchive.org. Soma FM isn’t actually on our “official” skills list yet, because it’s maintained outside our org, and isn’t quite running smoothly on the Neon OS yet. You may have just provided some insight into why
Alternate Case 2: Using the latest beta / alpha version, because there are some fixes in it based on feedback we got on Element and I wonder if it fixed the issues you are seeing.
Thank you for helping us improve!
1 Like
Hey @NeonClary
Updated to latest version and it’s still the same
There is a high amount of latency from pressing the screen to getting anything working when it comes skills
I really don’t have enough bandwidth to be testing anymore but I’ll keep my eyes peeled for any future developments
I also think you’ve got a memory leak!
You may want to check your code
Also why are you running Debian for the build - would fedora not give you better development roadmap?
1 Like
Did you update to the latest version by updating, or by reflashing?
1 Like
I updated using the updating skill
I’m inclined to blame an interaction between the GUI and that Soma skill. It’s the same GUI as on OVOS, but Neon has iterated on it.
I think we might need @NeonDaniel to evaluate with confidence whether the problem is in their version of the GUI or in the OVOS framework under the skill.
We are aware of a problem that meets this basic description with certain streams and the GUI player. OVOS flagged it wontfix because one of the components involved is slated for a handoff or rewrite, and because it only seems to affect certain streams, and only with the GUI player.
However, that will affect Neon powerusers more than anyone else. Furthermore, if you were able to use that skill on OVOS without this problem, it takes on a new and interesting dimension. Neon’s GUI is customized, but it’s fundamentally the same GUI.
1 Like
If you haven’t already, you’ll need to reflash once with the new 2.0 version to get everything “under the hood” fully updated. Thanks for sharing your results.
To be clear
I updated by means of flash and then updated to the most recent version using the skill
I’ve got a python script that will dump proc northbound
I’ll give it go at the weekend to see if I can find any offending pids
1 Like
I appreciate it. Just for the sake of laying our bets, the GUI is gonna spike as soon as you try to invoke Soma.
1 Like