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

Massive data uploads since 2017.34 2448cfc

This site may earn commission on affiliate links.
Definitely hugely increased traffic. Sitting for an hour in my parking lot it used 400MB or so of mobile hotspot data. Unfortunately I don't have a breakdown of how much was up vs down…. But I've never seen this happen before short of a software update, which doesn't seem to be the case here.
Not plugged in?
I noticed that the car is much more eager about ape shutdown if it's not plugged. Plugged in ape stays up exactly 2 hours since you put it into park.
Unplugged it's mere minutes so when running errands every time you return to the car it would already need to bring ape back up. I imagine if it sees the key it happens a lot too. And then there's the internal waking of the systems based on who knows what (I know updates wakes stuff at times but some other bits are woken more frequently than that).
 
  • Informative
Reactions: Tezlanian
Not plugged in?
I noticed that the car is much more eager about ape shutdown if it's not plugged. Plugged in ape stays up exactly 2 hours since you put it into park.
Unplugged it's mere minutes so when running errands every time you return to the car it would already need to bring ape back up. I imagine if it sees the key it happens a lot too. And then there's the internal waking of the systems based on who knows what (I know updates wakes stuff at times but some other bits are woken more frequently than that).

Not plugged in, indeed. Had actual work to do this morning instead of hunting for free electricity :D
 
Not plugged in?
I noticed that the car is much more eager about ape shutdown if it's not plugged. Plugged in ape stays up exactly 2 hours since you put it into park.
Unplugged it's mere minutes so when running errands every time you return to the car it would already need to bring ape back up. I imagine if it sees the key it happens a lot too. And then there's the internal waking of the systems based on who knows what (I know updates wakes stuff at times but some other bits are woken more frequently than that).

So I was plugged in this afternoon, and noticed that it transferred maybe another 400-600MB… Unfortunately all while tethered to a smartphone without much logging capability.
 
So I was plugged in this afternoon, and noticed that it transferred maybe another 400-600MB… Unfortunately all while tethered to a smartphone without much logging capability.
yeah, that's massively more than what I get:
uploads.png
 
I had 600MB usage before 2017.34 this Tuesday.... only tethered to my car and only when parked....

Another 200MB today!
I wonder if yours actually does complete the crashdumps unlike mine. Another problem appeared is wher eas before the logger would append to the log files, now it seems to truncate the previous log file before starting writes so if the logging is not super excessive to ensure that it rotates over, you get to see nothing from the previous boot.
 
  • Informative
Reactions: Tezlanian
@verygreen

So is the system crashing? -"In computing, a core dump (in Unix parlance), memory dump, or system dump[1] consists of the recorded state of the working memory of a computer program at a specific time, generally when the program has crashed or otherwise terminated abnormally.[2]"

Or

Is it simply uploading to assist in "...in diagnosing and debugging errors in computer programs."?
It's sort of both.
It crashes, but not entirely, just the vision task (there are many other tasks).
And then the crash dump (core dump) is then collected and uploaded to mothership in order to assist in debugging the crash (but since it's likely all the same crash across all cars, likely due to cameras being powered off before vision task is still working so vision task crashes, it's a bit of useless, just one sample should have been enough).
 
  • Informative
Reactions: Tezlanian
And then the crash dump (core dump) is then collected and uploaded to mothership in order to assist in debugging the crash (but since it's likely all the same crash across all cars, likely due to cameras being powered off before vision task is still working so vision task crashes, it's a bit of useless, just one sample should have been enough).
If it's the same crash dump every time it seems awfully wasteful sending that much repeated redundant data. I'd have imagined they wouldn't have made such a big push of the same version if it leads to everyone sending the same cores.
 
So... after some creative equilibristics (you know, they don't make it easy to intercept control early in boot process before the logs are truncated) I managed to obtain a log from the vision task and it is as I just suspected.
Now we just need to get a bigger log sample from somebody who does get them to settle the matter, I guess. Anybody with AP2 car near East TN? ;)

Code:
2017-09-09_xxx-0700 W0909 xxx  3438 signal_handler.cpp:128] RAW: Signaling task termination upon receiving signal 15
2017-09-09_xxx-0700 F0909 xxx  3332 syncedmem.cpp:27] Check failed: error == cudaSuccess (29 vs. 0)  driver shutting down
2017-09-09_xxx-0700 *** Check failure stack trace: ***
2017-09-09_xxx-0700     @       0x7f780561d4  google::LogMessage::Fail()
2017-09-09_xxx-0700     @       0x7f78057c24  google::LogMessage::SendToLog()
2017-09-09_xxx-0700     @       0x7f78055fe8  google::LogMessage::Flush()
2017-09-09_xxx-0700     @       0x7f780573a8  google::LogMessageFatal::~LogMessageFatal()
2017-09-09_xxx-0700     @           0x555194  (unknown)
2017-09-09_xxx-0700     @           0x540504  (unknown)
2017-09-09_xxx-0700     @           0x5486ac  (unknown)
2017-09-09_xxx-0700     @           0x5484e8  (unknown)
2017-09-09_xxx-0700     @       0x7f77acf13c  __run_exit_handlers
 
So... after some creative equilibristics (you know, they don't make it easy to intercept control early in boot process before the logs are truncated) I managed to obtain a log from the vision task and it is as I just suspected.
Now we just need to get a bigger log sample from somebody who does get them to settle the matter, I guess. Anybody with AP2 car near East TN? ;)

Code:
2017-09-09_xxx-0700 W0909 xxx  3438 signal_handler.cpp:128] RAW: Signaling task termination upon receiving signal 15
2017-09-09_xxx-0700 F0909 xxx  3332 syncedmem.cpp:27] Check failed: error == cudaSuccess (29 vs. 0)  driver shutting down
2017-09-09_xxx-0700 *** Check failure stack trace: ***
2017-09-09_xxx-0700     @       0x7f780561d4  google::LogMessage::Fail()
2017-09-09_xxx-0700     @       0x7f78057c24  google::LogMessage::SendToLog()
2017-09-09_xxx-0700     @       0x7f78055fe8  google::LogMessage::Flush()
2017-09-09_xxx-0700     @       0x7f780573a8  google::LogMessageFatal::~LogMessageFatal()
2017-09-09_xxx-0700     @           0x555194  (unknown)
2017-09-09_xxx-0700     @           0x540504  (unknown)
2017-09-09_xxx-0700     @           0x5486ac  (unknown)
2017-09-09_xxx-0700     @           0x5484e8  (unknown)
2017-09-09_xxx-0700     @       0x7f77acf13c  __run_exit_handlers
I can easily recreate situations with lots of autosteer spontaneously aborting (see my test video for .34) , is that when it generates cores or something else?
 
I can easily recreate situations with lots of autosteer spontaneously aborting (see my test video for .34) , is that when it generates cores or something else?
For me it seems to be generating cores when ape shuts down. Seems to be the same at least for chillaban when the car uploads a bunch of data while parked (note that's when it shutdowns,but then periodically wakes up and shuts down again).

I don't really know why you are seeing spontaneous aborts, might be a myriad of different reasons.
 
I don't really know why you are seeing spontaneous aborts, might be a myriad of different reasons.
Oh that's actually pretty clear to me - I drive in situations where the software is singularly unable to handle and make a decision about what to do by getting into situations where it can no longer distinguish the direction and markings of the road. I have a route that I use to test AS on which reliably makes it abort quite a few times which I am using to track progress (or otherwise) of EAP and have posted it in another thread.
See:
 
  • Helpful
Reactions: rabar10
you still need to open up the dash to gain access to in-car network. then connect to the updater and tell it to download the file with the firmware you have obtained by other means.

Thanks for the help!

Do I need the port behind the IC or I the 4-pin connector on the cable sufficient?

Are the firmware images checked for validity, or is it possible to brick the car with a corrupt file or a wrong version?

Are downgrades possible?