FSD Beta 10.12

[drtimhill]

I am pretty sure that Tesla's plan remains as bolded in your post in order to provide redundancy. However during this intense development phase it helps them to run additional software on the second computer and so they have opted to do so. When the major development phase is over this additional software will no longer be required and they can return to the redundant set up.

I don't think anyone at this stage knows if this will be true (including Tesla), since the final CPU/NN load is still unknown. Additionally, this kind of redundancy isnt particularly useful, since errors in something like FSD city streets or NoA are far likely to be related to the software stack rather then CPU hardware errors (which typically crash the CPU rather than generate erroneous results). If both CPUs run the same software stack then they will both generate the same (software) errors, which will "pass" any redundancy arbitration tests.

True software redundancy, which is very expensive to develop, requires two (or more) distinct software stacks, typically developed by independent teams, that generate the same results for the same input via different code paths. Even defining "same" here is problematic, since most of the logic is fuzzy NNs, which would generate "similar" but different valid results (e.g. turning steering wheel by slightly different amounts to get same effect). Arbitrating these differences to generate alarms is itself complex and, of course, this part of the code is not redundant and is subject to the same programming errors as the stacks its supposed to be checking.

 

[EVNow]

I don't think anyone at this stage knows if this will be true (including Tesla), since the final CPU/NN load is still unknown. Additionally, this kind of redundancy isnt particularly useful, since errors in something like FSD city streets or NoA are far likely to be related to the software stack rather then CPU hardware errors (which typically crash the CPU rather than generate erroneous results). If both CPUs run the same software stack then they will both generate the same (software) errors, which will "pass" any redundancy arbitration tests.

True software redundancy, which is very expensive to develop, requires two (or more) distinct software stacks, typically developed by independent teams, that generate the same results for the same input via different code paths. Even defining "same" here is problematic, since most of the logic is fuzzy NNs, which would generate "similar" but different valid results (e.g. turning steering wheel by slightly different amounts to get same effect). Arbitrating these differences to generate alarms is itself complex and, of course, this part of the code is not redundant and is subject to the same programming errors as the stacks its supposed to be checking.

Compute redundancy was really more for h/w redundancy than s/w. Tesla designed redundancy in multiple H/W components when they thought they would have robotaxi ready in no time. Now that they are actually developing a new robotaxi - may be it will have true h/w redundancy.

 

[Phlier]

So, in your busy round abouts, FSD waiting for cars coming from the left to pass before entering the roundabout ... and then didn't stop for any other vehicle ?

In my case (1) - is not consistent. It stops at the roundabout and waits ... but doesn't always enter the roundabout correctly. Once in a while it will enter when a car is coming from the left - unlike in URT where it will definitely wait. #2 is mostly ok - but I've had occasions when the car stops because of a car on the right. Happened just a couple of days back again.

All of your roundabout related posts match up with my results just about exactly, with one little twist... we have some really poorly designed roundabouts that have lanes merge while in the roundabout and other bizarre design decisions. These things are a problem for *human* drivers, let alone poor FSD.

 

[momoz74]

I only had one real drive today but will do more tonight/tomorrow. I can say my worst morning drive is so much better. It is a 30mph street with many stop signs and light intersections. IT would constantly do the "phantom braking" going from 32 to 28 in like 10 spots. Today was flawless!

Now.. the regression:
4 way stop signs are bad. I have to take over because people are honking at me. It creeps way too slow after the car in front goes.. then pauses way too long and does what someone else here said, 4mph all the way through then floors it. Very unnatural. I'm trying to get a 4-way where no one else is there to see how it does as it usually handled that smooth.

 

[thewishmaster]

Even wider push now, with 730 installs pending on Teslafi. Mine's downloading finally

 

[JohnnyEnglish]

I don't think anyone at this stage knows if this will be true (including Tesla), since the final CPU/NN load is still unknown. Additionally, this kind of redundancy isnt particularly useful, since errors in something like FSD city streets or NoA are far likely to be related to the software stack rather then CPU hardware errors (which typically crash the CPU rather than generate erroneous results). If both CPUs run the same software stack then they will both generate the same (software) errors, which will "pass" any redundancy arbitration tests.

True software redundancy, which is very expensive to develop, requires two (or more) distinct software stacks, typically developed by independent teams, that generate the same results for the same input via different code paths. Even defining "same" here is problematic, since most of the logic is fuzzy NNs, which would generate "similar" but different valid results (e.g. turning steering wheel by slightly different amounts to get same effect). Arbitrating these differences to generate alarms is itself complex and, of course, this part of the code is not redundant and is subject to the same programming errors as the stacks its supposed to be checking.

As stated by @EVNow, Tesla's stated intent was hardware redundancy.

Not sure if you are referring to fuzzy logic in the second part of your response, but it would be incorrect to imply that at the inference stage an NN will generate different results from the same inputs.

 

[aspekt]

just received mine as well

 

[jeremymc7]

I figure we're on full wide release to everyone that had a prior beta. It's just coming out in chunks.

 

[mhan00]

Yep, just got my update notification too. Looks like it’s going wide.

 

[FSDtester#1]

It auto downloaded without me doing anything... just had to click install

 

[Battouttahe77]

Even wider push now, with 730 installs pending on Teslafi. Mine's downloading finally

I'm sure I'll get my update in 2 weeks.

 

[follow.johnny]

Just got the update and installing right now!

 

[everydaychris]

shill youtuber here still waiting but ready to post my it drove itself without touching the wheel video

 

[JulienW]

It auto downloaded without me doing anything... just had to click install

That is the ONLY way it works and there is NOTHING you can do anyway.

 

[Mardak]

I figure we're on full wide release to everyone that had a prior beta. It's just coming out in chunks.

So far not quite all existing testers yet. Last week, the rollout was roughly 5%, and yesterday/this morning it expanded by roughly 10% to 15%, and now it increased another 25% to 40% rollout. So majority of existing testers are still waiting.

Also curious that so many are waiting WiFi for this FSD Beta update?

 

[JulienW]

So far not quite all existing testers yet. Last week, the rollout was roughly 5%, and yesterday/this morning it expanded by roughly 10% to 15%, and now it increased another 25% to 40% rollout. So majority of existing testers are still waiting.

Yea, I'm on iPhone/App checking. Hit me with a Notification to install Tesla.

 

[FSDtester#1]

That is the ONLY way it works and there is NOTHING you can do anyway.

Does the install take the full 50 minutes??

 

[j0shm1lls]

Does the install take the full 50 minutes??

48 minutes for me.

 

[JulienW]

Does the install take the full 50 minutes??

Usually about an ½ hour or so. You can check the progress on your App, although it will be kinda like a file download progress bar, only a relative indicator.

 

[drtimhill]

As stated by @EVNow, Tesla's stated intent was hardware redundancy.

Not sure if you are referring to fuzzy logic in the second part of your response, but it would be incorrect to imply that at the inference stage an NN will generate different results from the same inputs.

Agreed, but I was referring to different (as in, independently trained) NNs generating different results from the same inputs, which is what would be required for independently developed dual FSD stacks (to offer software redundancy).