Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

MCU1 performance improvement & browser improvement. Simple trick by Thomas The Tesla Tuner..

This site may earn commission on affiliate links.
So is it bandwidth constrained in getting the traffic update data over 3G/LTE, or CPU/GPU constrained in rendering?

The Tegra processor wasn’t great in 2012 and performs like a 1987 Yugo with a blown head gasket by modern standards.

License some A12 Bionic chips from Apple and Bob’s your uncle. Make a feature-frozen stable final build (make take a year) for existing cars and allow all cars to upgrade to the new HW with pro-rated discounts.
 
Tesla does the display design and software in house, refuses to play licensing fees for Android auto, Apple CarPlay, and they pay the minimum to XM radio. Let’s be honest. It’s integrated with the CAN bus and SSRs to control car functions and integrated with the GPS, cellular and radio. It’s not a bad design, just done by a small team and overseen by minimalist minded UI leaders.

Kinda like the Jony Ive vs Tony Fadel skew morphing about icons on a phone. And also an argument of Android vs Apple ecosystem locked vs open. Tesla’s UI is more restrictive than that of Apple. Who here wouldn’t love a few options to customize the layout, and have the ability to see XM data feeds and also be allows to reorganize favorite?
 
Neat trick; definitely speeds up the browser. Answer me this though: with html5test cached and hitting the refresh button it takes7 seconds to render with traffic off, and with traffic on it takes 18 seconds to refresh, but in both cases the score is 320. Should it not score lower with a longer time?
 
  • Informative
Reactions: FlatSix911
Interesting tip. I hadn't thought about the effect of having traffic conditions left turned on even if you're not using the nav. Is there any noticeable difference in MCU1 browser performance using this tip vs obscuring the entire map by bringing up the easter egg sketchpad? That sketchpad trick also improves the browser speed in v9.

When sketchpad is up, the red nav location pointer no longer updates in the background even if you drive for a distance. Later once you close the sketchpad it then takes several seconds for the nav to find your correct location. So it seems the sketchpad similarly stops the nav from updating and consuming cpu resources
 
  • Like
Reactions: Accelev
I tried also to check the temperature at passive cooler installed at Tegra3. It is worth to notice, that during a warm day, Tegra is throttling at once at level 1 (about 30% performance loss) because of poor gravitational air convection. In winter (cold interior) it would throttle after 5-15 minutes.
I will install active cooling for the MCU1 processor board next week, so we will see results. It may be very fundamental to achieve better performance. I publish videos with teardown and active cooling installation on my channel later.
 
Also, with V9 , you can see map wasting resources along all edges, it is first rendering a fullscreen map, then overlaying it with media.
This design can be summarized as:
-very inefficient
-very wasteful of resources
-the programmers have not done a decent job using CPU power where needed, while a user interact with media/browser/playlists, it is a complete waste to refresh maps at a high rate.
-The simple traffic overlay , (could be stored as a bunch of vectors) - is insanely badly programmed.
 
it is first rendering a fullscreen map, then overlaying it with media.

You've hit the nail on the head. That illogical overlays design doubts me too.

BTW, I think with proper active cooling there would be no throttling so performance could be even better. I would also root it and try overclocking to 1,7 GHz - hopefully no throttling with that speed with a copper cooling device.

I hope Mr Musk won't be angry ;)
 

Great Thomas. Looks like you are adding another workaround to make the browser a bit more usable. It's now the time to see this fiasco fixed by Tesla. It so dispiriting to disable features A, B, C, and D in order to be able to barely use the feature E of this expensive car. It appears more efficient coding by the Tesla software developers would improve the browser performance without the availability of any possible future hardware upgrades.
 
Tesla could just implement a browser mode where it makes browser full screen and reduces CPU time for background tasks, this should be fairly simple.
... or they could simply GET RID OF the omnipresent map which is there at top and around edges of screen and consuming precious resources even when you don't need it - i.e. how things worked pre-v9. BTW v8 and prior you also could make the browser full screen (less the top icon bar), no more in v9
 
This seems similar to another workaround which has been mentioned on the forums: bringing up the sketchpad easter egg app will cover the map and keep it from rendering, improving the performance of other functions. Wonder if it's possible to bring up the sketch app and then put the browser on top of it to achieve the same level of performance? Not that anyone should ever have to do that, of course.

The writing has been on the wall for some time: new software and new features will never require less computing resources, which means updates will perform best on cars with current hardware.
 
yes as mentioned above, bringing up the sketchpad to cover the map and then opening the browser definitely improves v9 browser performance - though I haven't compared to Accelev's method. I recall someone else on TMC also mentioning the Mars easter egg does the same, so the key seems to be hiding the map/traffic.

the dumb(er) thing about the sketchpad workaround is that the sketchpad seems to disappear on its own when you park the car for a while, you can't leave it there permanently. So you have to redo the workaround every time you want to use the browser. I guess that might give a slight advantage to the OP's trick, I assume you don't always need to redo the map and traffic setting?
 
Ok, I'm inside (Mr Elon, please do not send an assassin ;) - The whole problem is not a lack of memory. It is caused by refresh function for traffic info, with passes processing to the main routine. It seems that somebody interpreted value of delay of a refresh to be in seconds (120, = 2 minutes), but it is in milliseconds. It eats 30% of spare MCU1 time. It tries to re-render it 6-7 times per second, with no new information (refresh period of traffic info via communication channel is set correctly).
My assumption - two differently skilled programmers did that.
Please, Tesla, correct this. Just add three zeros (120 -> 120000), recompile and send to us. And all will be ok.
Thomas
PS: Loading Tegra3 with this one passive cooler over 60% of load causes throttling. Who was a developer? Even ventilation holes, developed by engineers are covered from the bottom by shelf under the screen. No air circulation then.
 
Ok, I'm inside (Mr Elon, please do not send an assassin ;) - The whole problem is not a lack of memory. It is caused by refresh function for traffic info, with passes processing to the main routine. It seems that somebody interpreted value of delay of a refresh to be in seconds (120, = 2 minutes), but it is in milliseconds. It eats 30% of spare MCU1 time. It tries to re-render it 6-7 times per second, with no new information (refresh period of traffic info via communication channel is set correctly).
OMG. no wonder v9 sucks

My assumption - two differently skilled programmers did that.
that's putting it very kindly