LOL Why? I suppose you have an ancient android phone? It's a complete waste of time to NOT use my phone. Maps loads instantly and shows store hours immediately when the store is selected, for example. Then if you want to call you just click. Anything on the MCU is extremely tedious, in addition to taking 10-30 seconds to load, assuming the page you're trying to load even works in the MCU, which is probably doesn't. Response time on my phone is in milliseconds.
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
LOL Why? I suppose you have an ancient android phone? It's a complete waste of time to NOT use my phone. Maps loads instantly and shows store hours immediately when the store is selected, for example. Then if you want to call you just click. Anything on the MCU is extremely tedious, in addition to taking 10-30 seconds to load, assuming the page you're trying to load even works in the MCU, which is probably doesn't. Response time on my phone is in milliseconds.
Because my phone doesn't have a 17" display and its usually in my pocket. And since my car isn't going to be anywhere in milliseconds the response time doesn't matter much.
So you're just sitting there in a parked car using the browser? Or you're driving and having to look down at a slowly responding screen?
You know what, we're in an apologist argument here. Whatever floats your boat man if it's fast enough for you so be it. It's slow as s*** for me.
I'll often use the browser if I'm not driving and I'm in the passenger seat. I'm a cheapskate with prepaid cellular data, so I'll take advantage of free data whenever I can. (I bought $15 of prepaid data about 7 months ago and still have half of it left.)
If we're in a hurry, I'll have someone else turn on their hotspot and then use my phone but if we're on a 500 mile road trip and 2 hours from our destination, I just use the built-in browser since there isn't any rush.
I do find it frustrating to have to use the keyboard though. I've been using Swype for 6+ years and am not used to typing one character at a time.
Dstrohl
Member
Did AP1 cars have a separate processor for AP functions? because if not, there may well be an increase in performance on the MCU simply due to offloading all of the AP functions to the new dedicated processor. (It seems like processing the cameras and sensors, etc and tracking cars and other objects could be a pretty significant load on the systems. which happens even if you are not driving).
lunitiks
Cool James & Black Teacher
lunitiks
Cool James & Black Teacher
The AP1.0 camera housing is where the action happens, or to quote Jason Hughes, it:
"contains the MobileEye EyeQ3 chip and handles all of the heavy lifting for Tesla's autopilot."
Autopilot Module Tear Down | wk057's SkieNET
"contains the MobileEye EyeQ3 chip and handles all of the heavy lifting for Tesla's autopilot."
Autopilot Module Tear Down | wk057's SkieNET
Dstrohl
Member
Oh well... I guess it was worth considering... though to be fair, in the post linked, it is talking about the EyeQ video processing system and says that it works in conjunction with the radar ultrasonic, and controls for breaking and steering, however it does not say what system is in charge of combining all of the inputs and turning them into outputs. It doesn't say this isn't it either, it might well be, but it seems reasonable to think that it might use the MCU (or some other central processor) to take the input from all these systems and convert them into driving commands.
I don't know if these commands are being handled by the CANBUS, or by direct connections from something (anyone with a wiring diagram handy?).. that might clear it up if they are being run directly from the MCU today. (Though I suspect they use CANBUS or some other internal network for them, that looks like a CANBUS connector on the end of the PCB in the pictures.) If it is CANBUS, an analyzer might help if it can see the steering commands and see where they are coming from.
Of course, we could just wait and see if the new cars touchscreens "feel" faster or not <grin>.
eyespii
Member
Maybe we should set up a drag race between the P100D doing 0-60mph and the web browser loading www.google.com.
Dstrohl
Member
I also suspect that it is not really worth trying to judge the performance of the system using a javascript test, unless all of the core functions performed (nav, audio, etc) are done using JavaScript,... something that I seriously hope is not the case.
As was mentioned earlier, JavaScript is normally single-threaded (meaning it can only use one processor at a time, even if the system has several (which is normal these days). There are ways of making JavaScript act multi-threaded, using things like HTML5 web workers, but those don't really solve the overall JS performance challenges. In addition, in almost every case, the JavaScript engines in browsers are designed to prevent direct access to many of the core OS functions for security reasons, which means that it can't take advantage of many of the performance enhancing features available to someone writing a native application. These are fine for many apps which don't need it, but if you are trying to test the performance of the underlying system, you need to be able to exercise the system as directly as possible. Otherwise it would be like doing a drag race in an ICE car, with someone else handling the gearshift and clutch... you don't really know if you are in the best gear or not at any given point.
This isn't to say it is worthless doing JavaScript performance tests... it is certainly worth doing for each update anyway to see if they changed the underlying browser, JS engine, settings, etc... and since many web apps do use JS, it can give an idea of the performance of those apps.
When you do an upgrade or a hard reset, can you see any of the startup lines on the console? That will often indicate how much memory and processor size is in the system that is booting up (though it is often hidden behind a logo image).
As was mentioned earlier, JavaScript is normally single-threaded (meaning it can only use one processor at a time, even if the system has several (which is normal these days). There are ways of making JavaScript act multi-threaded, using things like HTML5 web workers, but those don't really solve the overall JS performance challenges. In addition, in almost every case, the JavaScript engines in browsers are designed to prevent direct access to many of the core OS functions for security reasons, which means that it can't take advantage of many of the performance enhancing features available to someone writing a native application. These are fine for many apps which don't need it, but if you are trying to test the performance of the underlying system, you need to be able to exercise the system as directly as possible. Otherwise it would be like doing a drag race in an ICE car, with someone else handling the gearshift and clutch... you don't really know if you are in the best gear or not at any given point.
This isn't to say it is worthless doing JavaScript performance tests... it is certainly worth doing for each update anyway to see if they changed the underlying browser, JS engine, settings, etc... and since many web apps do use JS, it can give an idea of the performance of those apps.
When you do an upgrade or a hard reset, can you see any of the startup lines on the console? That will often indicate how much memory and processor size is in the system that is booting up (though it is often hidden behind a logo image).
I'd bet on the hitting the finish line first. There's been many times where I've waited more than 10 seconds for the browser to even get to the point where I could type in a url, forget about loading the page.
Similar threads
