-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Agree it's frustrating and shouldn't be this difficult. But the drive I posted a couple pages back that has worked perfectly for me was a whopping $9.49. My point being - just try a few of the cheap recommendations, not the pricey ones.
Knightshade
Well-Known Member
Yeah, I mean, why bring facts into a discussion right? Some nerve I've got!
Same deal for the other guy- while I've presented sources and data and real world examples, anytime I asked him to cite any he just shrugged and said he wasn't interested in discussing further.
Wonder why.
https://smile.amazon.com/gp/product/B072PT89ZJ/ref=ppx_yo_dt_b_asin_title_o01_s00?ie=UTF8&th=1
This combo has worked for me so far with no issues and you can read on the reviews that it has worked for a lot of Tesla drivers. Dirt cheap too. It took me one minute to reformat it to FAT32 on my Mac, super easy...
This combo has worked for me so far with no issues and you can read on the reviews that it has worked for a lot of Tesla drivers. Dirt cheap too. It took me one minute to reformat it to FAT32 on my Mac, super easy...
Knightshade
Well-Known Member
it's...kinda really not.
For example under longevity it says
Your link said:
That's incorrect...(and not just due to adding the rear recently- that's never been true...) it stores 1.8 GB per camera (60 1 minute clips of ~30MB each). So 5.4GB per hour when it was 3 cameras, 7.2 GB now with 4.
The cycle life chart under that is...just weird... since it's based entirely on a guy who never does anything but drive exactly 60 mph. It also list a "cycle life" column with no info or context on where those numbers come from or what relation they have to any specific hardware.
Then under write speed it gets even more hilarious wrong, where it says:
Your link said:
Basic math fail- 30MB file for 1 minute, 4 cameras... 120MB/min... or 2 MB/s. Which is 8 times less than the # they came up with (hell, even the double-that number Tesla wants is 4 times less than they claim you need).
Guess they didn't read that guys website
Seriously though, check out the link I posted earlier with benchmarks on well over 600 USB drives. Everything 64GB and larger was WELL above 4MB/s sustained write speed... (like 2-3 times faster than that on the low end).
Certainly whatever someone gets I'd suggest they run some basic benchmarking before installing, it'd prevent issues like that one guy earlier who got a Samsung key that most have no issue with but when he tested on a PC he was getting like 1/20th the speed he should have- clearly a defective drive that should've been returned.
Checked on this thread again and see that we still have the vocal minority not wanting to ingest well explained information.
One can arguably reduce to 3 the main specs that define a storage drive. How often it can perform an operation (IOPS), how long before it performs the operation (latency) and at what rate the data is retrieved/stored (speed). Average IO size x IOPS = throughput speed. We don’t know how Tesla chose to write to the USB drives (buffer the entire file for each camera and write it at once or write unbuffered i.e. I/O size is unknown) and what thresholds they have set for the latency (if flushing the buffer cannot complete in X ms, deem drive unfit). The argument that a drive can be "failed" by Tesla for something else besides speed (i.e. saying it can’t be the USB drive fault since even a slow drive can write X times faster than what the 4 cameras need) was made by me here long ago. Info was provided about features such as TLER and why latency matters and how an otherwise top of the line consumer HDD can get "dropped/deemed unfit" by a RAID controller because a drive takes too long to do housekeeping (i.e. multiple re-reads before doing a bad sector relocation and such).
There was a request for a "citation" by one of the vocal members on how inconsistent flash storage is (latency wise in that case). Please note, the controller on even the lowest SSD is very likely superior to what you find in an average USB stick. Links below are for a 1TB sized recent SSD drive (KC2000) that is more than twice as fast overall as a SATA and entry-level NVMe drive so not with a bottom of the barrel controller. Further almost any flash drive that is mostly full or has been in use for a while has less headroom for housekeeping, or when it is reaching its thermal headroom, those high latency scenarios will be more frequent.
Will not go into explaining difference between average and 99th percentile, will just leave the numbers to speak for themselves. Suffice to say, one in 100 operations takes ~30 times longer than average. Instead of microseconds (359 us), the metric goes into milliseconds (10.5 ms).
https://images.anandtech.com/graphs/graph14601/destroyer-latency.png
https://images.anandtech.com/graphs/graph14601/destroyer-99-latency.png
Original source and context at The Kingston KC2000 SSD Review: Bringing BiCS4 To Retail
Similarly, IOPs are very inconsistent on flash media. This is a somewhat exaggerated example (QD32) on an older drive (4 years old) but since they don't do this test on modern drives it will make do. This drive may actually perform quite similar to current USB3 drives.
Takes 4 minutes to go from ~15000 to ~500 IOPS
https://images.anandtech.com/doci/9756/bx200_480_pc1_575px.png
I leave 20% drive capacity unpartitioned, do not use same drive for music (adding read to the write operations) and park in the shade.
One can arguably reduce to 3 the main specs that define a storage drive. How often it can perform an operation (IOPS), how long before it performs the operation (latency) and at what rate the data is retrieved/stored (speed). Average IO size x IOPS = throughput speed. We don’t know how Tesla chose to write to the USB drives (buffer the entire file for each camera and write it at once or write unbuffered i.e. I/O size is unknown) and what thresholds they have set for the latency (if flushing the buffer cannot complete in X ms, deem drive unfit). The argument that a drive can be "failed" by Tesla for something else besides speed (i.e. saying it can’t be the USB drive fault since even a slow drive can write X times faster than what the 4 cameras need) was made by me here long ago. Info was provided about features such as TLER and why latency matters and how an otherwise top of the line consumer HDD can get "dropped/deemed unfit" by a RAID controller because a drive takes too long to do housekeeping (i.e. multiple re-reads before doing a bad sector relocation and such).
There was a request for a "citation" by one of the vocal members on how inconsistent flash storage is (latency wise in that case). Please note, the controller on even the lowest SSD is very likely superior to what you find in an average USB stick. Links below are for a 1TB sized recent SSD drive (KC2000) that is more than twice as fast overall as a SATA and entry-level NVMe drive so not with a bottom of the barrel controller. Further almost any flash drive that is mostly full or has been in use for a while has less headroom for housekeeping, or when it is reaching its thermal headroom, those high latency scenarios will be more frequent.
Will not go into explaining difference between average and 99th percentile, will just leave the numbers to speak for themselves. Suffice to say, one in 100 operations takes ~30 times longer than average. Instead of microseconds (359 us), the metric goes into milliseconds (10.5 ms).
https://images.anandtech.com/graphs/graph14601/destroyer-latency.png
https://images.anandtech.com/graphs/graph14601/destroyer-99-latency.png
Original source and context at The Kingston KC2000 SSD Review: Bringing BiCS4 To Retail
Similarly, IOPs are very inconsistent on flash media. This is a somewhat exaggerated example (QD32) on an older drive (4 years old) but since they don't do this test on modern drives it will make do. This drive may actually perform quite similar to current USB3 drives.
Takes 4 minutes to go from ~15000 to ~500 IOPS
https://images.anandtech.com/doci/9756/bx200_480_pc1_575px.png
I leave 20% drive capacity unpartitioned, do not use same drive for music (adding read to the write operations) and park in the shade
.
Correlation does not imply causation.
I could say "There has been a notable surge of this issue as the weather has gotten colder" (much like the pattern with posts/threads about range and regen issues).
Do we have any data from V10 in July? I believe not.
My statement can from the number of people who reported not having issues before V10 and having them after upgrading. Yes, people had issues before V10, but this iteration seems to have been exacerbated this round.
And of course there is no data on V10 from July considering it came out in late September.
Hey, just wondering how you have your Fit Plus configured. Are you using it strictly for TeslaCam or do you have a music partition as well?
Yeah, I mean, why bring facts into a discussion right? Some nerve I've got!
Same deal for the other guy- while I've presented sources and data and real world examples, anytime I asked him to cite any he just shrugged and said he wasn't interested in discussing further.
Wonder why.
Because, to be bunt, the "other guy" has better things to do than listen to your blathering nonsense. You present opinions as facts and nonsense as opinions. You confuse simple terms like "serialize" and conflate them with concepts you dont understand (the serial nature of the USB signaling protocol vs the serial nature of cheap flash controllers), and continue to bleat on about sustained transfer rate when it clearly has NOTHING to do with the issue. You have no concept of the huge overheads associated with flash drive cascaded block remapping and erasure (especially on full drives, which almost by definition the car has to deal with all the time). You seem to think that the error message given by the car is connected in some way to sustained rate when in fact it has nothing to do with it whatsoever (despite the wording of the error). Your arguments about moving and copying files are so confused as to be meaningless. You do not understand the relevance of peak bitrate in the compressed video stream. You think latencies need to be seconds long to disrupt the drive operation (they do not). You blindly cut+paste things from google searches you dont understand (dont think I didn't notice that when you pretended you knew what "thread starvation" was). I could go on, but why bother? You will just post some random meaningless nonsense about how you are right even when you clearly are not and think you have somehow scored "points". Why does the phrase "Dunning Kruger" keep popping into my head?
So let's deal with some facts, shall we? Last night I sat down and wrote a simple test fixture, and ran it under reasonably controlled conditions .. not rigorous enough to eliminate all possible variables, but good enough for a "quick and dirty". I grabbed a couple of cheap flash drives (one Sandisk, one off-brand Kinstone) and measured their sustained write speeds after pre-conditioning them. The Sandisk measured about 30MB/sec, the Kinstone about 10-12MB/sec. YOU would argue that both drives should work fine, whereas *I* would argue that the Kinstone is unfit for purpose, as per my point about peak compression bitrate, buffer overflow, and latencies.
(My sincere apologies to others reading this thread. I realize this has deteriorated into a pointless shouting match, however I dislike having my integrity called into question and felt one (and only one) reply was warranted.)
Checked on this thread again and see that we still have the vocal minority not wanting to ingest well explained information.
https://images.anandtech.com/graphs/graph14601/destroyer-latency.png
https://images.anandtech.com/graphs/graph14601/destroyer-99-latency.png
Original source and context at The Kingston KC2000 SSD Review: Bringing BiCS4 To Retail
Similarly, IOPs are very inconsistent on flash media. This is a somewhat exaggerated example (QD32) on an older drive (4 years old) but since they don't do this test on modern drives it will make do. This drive may actually perform quite similar to current USB3 drives.
Takes 4 minutes to go from ~15000 to ~500 IOPS
https://images.anandtech.com/doci/9756/bx200_480_pc1_575px.png
I leave 20% drive capacity unpartitioned, do not use same drive for music (adding read to the write operations) and park in the shade
Good sources and points, thanks. The more people post here the more my instincts (and it is purely that at present) lean toward a perfect storm scenario; several things aligning at the same time. My guess is the following all conflate to cause a buffer overflow, which the Tesla interprets to mean "drive not fast enough" (which, after all, at that moment it isn't):
-- Significant housekeeping internal to the drive (block erase, remapping, wear leveling re-allocation).
-- OS file system metadata updates (flushing OS metadata as video flips from one set of tiles to the next), causing more stress on housekeeping.
-- Thermal stress on the drive causing delays as the controller throttles back (especially in the confined space in the car storage).
-- A period of poor video compression raising the data rate significantly.
-- Resource starvation in the OS (much trickier to quantify).
I'm thinking about some kind of simulator to try to replicate the data conditions in a controlled way, then see if I can reproduce some of the failures in a controlled environment. Though there are a lot of variables to deal with.
Knightshade
Well-Known Member
So when I mentioned latency on flash is incredibly small to the point it would never delay a write by entire seconds I was correct. By a pretty large margin.
Thanks for sourcing what I said was accurate and the other guys claims-
of a drive pausing for seconds at a time was nonsense.
Also worth noting of course is those numbers are running their destroyed test putting INSANELY heavy demand on the drive for both sequential and random reads of all kinds of sizes including over 1/4 of them being 4k (far smaller files than Teslacam is handling, and much harder on the drive).
So real world numbers for this application which is basically just 4 sequential writes of (for flash block size purposes) relatively large files, will be much better and more consistent.
And even then latency never gets remotely high enough to be an issue for anything.
That one is entirely random 4k writes- the worst case scenario for flash media, and nothing remotely like what the dashcam is doing.... (unless the software is written by a drunk guy who doesn't actually know how to write software I guess?)
In most cases random 4k writes will be 10-100 times slower than larger files and sequential writes on flash media...(you can see this in the #s from the 600+ USB device benchmarks I linked to earlier.
Still- thanks for being someone else who actually brought some sources into the discussion.
Also totally agree with using a dedicated drive for the camera to avoid asking it to do different IO tasks- that's what I do as well. The camera drive is only for the camera, and on its own USB port in the car.
You have time to write multi-page rants without sourced facts- but not to actually back up a single claim you make in the rant?
Weird.
I deleted the rest of the next bit of the rant since, once again, it was just you spouting nonsense without anything to support the claims.... then weirdly you try and support them with some "test" you claim you did, but then don't actually manage to support anything at all....
That's certainly be a nice change for you! Let's see how it goes!
Damn, got my hopes up and everything.
You claim you did "testing", then provided no results files, just your own claim of "about" what they measured, and only for sustained writes, all of which were much faster than Tesla requires and which you claimed did not even matter...
You provided no data on any other metric. Including all the ones you insist DO matter.
Then claimed the second drive is "unfit" for use....because... REASONS!
(reasons you continue to be unable and unwilling to support with any hard evidence- like say testing those factors you insist would make the 2nd drive unfit)
One 128GB FAT32 partition, used for dashcam/sentry only. I have a separate 256GB Samsung BAR drive for music (as I've got a couple hundred gigs of lossless music stored).
The camera drive is in its own port- the music drive is in a USB hub along with 2 phone charging cables going to the factory phone dock plugs.
Every 2-3 months I pull the Fit plus drive out, swap in a cheap 32GB kingston data traveller I have sitting around, clear off all the old sentry footage I don't need, then swap the drives back the next day. I don't think the drive has ever been more than maybe 60-70% full in that time between cleanings.
0 "too slow" errors, ever, including on V10. On either drive- but the 32GB one is just too small to trust more than a few days of use a year long term.
Quite a few versions ago on V9 I did have the issue lots of folks did with sometimes 1 of the repeaters would create 0 byte files... and there was the same freak out about OMG IT IS HARDWARE EVERYONE NEEDS SSDs... (despite even folks with SSDs reporting the same problems)
And, shockingly, those folks were wrong then too- Tesla eventually made their software suck less and the problem vanished.
Same will likely happen here.
Last edited:
In my experience, a Blackvue or Thinkware 1080P unit will destroy a new non-endurance microSD card in a week or two. I have had Samsung, Sandisk and Transcend endurance microSD cards last well over a year in these units. While TeslaCam is arguably less demanding in one way (lower resolution video), it is more demanding in other ways (4 feeds vs 2 and a backend system not optimised to be a dashcam).
Since pretty much all cards/sticks are "fast enough", it is evident that it is something other than rated speed that causes the duty cycle problems, namely, the inability to handle continuous read/write plus housekeeping operations in non-ideal environments. It may also be that Tesla allows easy removal of a drive without properly unmounting it.
I've seen very few, if any, people using microSD cards rated for continuous video operation having TeslaCam errors or mangled/distorted or zero byte file video complaints.
SSD's certainly seem an option for some Model 3 users, but may not be the best choice for Model S, as the USB ports cannot supply enough power for many drives (I had to use a power/data split cable pulling power from the 12V outlet to get reliable operation for an SSD drive with only music on it in my S).
For the small price difference between an endurance rated microSD card and adapter and a non-rated card/stick, I do not understand the reluctance to buying a card rated for the purpose or the insistence that "any" moderately fast USB card/drive will work reliably in a continous duty cycle.
Any Tesla "bug" would surface for all users, not just a hapless few. There may well be issues with how Tesla has built TeslaCam, but the only variable right now across users is the storage medium as we all have the same hardware and software.
Since pretty much all cards/sticks are "fast enough", it is evident that it is something other than rated speed that causes the duty cycle problems, namely, the inability to handle continuous read/write plus housekeeping operations in non-ideal environments. It may also be that Tesla allows easy removal of a drive without properly unmounting it.
I've seen very few, if any, people using microSD cards rated for continuous video operation having TeslaCam errors or mangled/distorted or zero byte file video complaints.
SSD's certainly seem an option for some Model 3 users, but may not be the best choice for Model S, as the USB ports cannot supply enough power for many drives (I had to use a power/data split cable pulling power from the 12V outlet to get reliable operation for an SSD drive with only music on it in my S).
For the small price difference between an endurance rated microSD card and adapter and a non-rated card/stick, I do not understand the reluctance to buying a card rated for the purpose or the insistence that "any" moderately fast USB card/drive will work reliably in a continous duty cycle.
Any Tesla "bug" would surface for all users, not just a hapless few. There may well be issues with how Tesla has built TeslaCam, but the only variable right now across users is the storage medium as we all have the same hardware and software.
Last edited:
Watch out buddy Knightshade will be after you with his facts soon (I personally agree with ur recommendation).
*How to unmount storage device for dash cam*
In case some of us don’t know this. I am not sure if it is a new function from v10 but here is a way to properly unmount dash cam device.
Press and hold the dash cam icon for 2-3 seconds. U will see a sort of glow effect around and icon (or ur finger as the icon is blocked by ur finger). Remove ur finger. Sometimes it is instantaneously sometimes it took a second or two, the red dot will disappear while the icon still present. Now u can safely remove the device. After the device is removed, the icon will disappear as well.
When u replug the device, after the icon shows up, it won’t automatically return to recording. U need to repeat the process above till the red dot comes back.
I do it every time, never had a corrupted file.
In case some of us don’t know this. I am not sure if it is a new function from v10 but here is a way to properly unmount dash cam device.
Press and hold the dash cam icon for 2-3 seconds. U will see a sort of glow effect around and icon (or ur finger as the icon is blocked by ur finger). Remove ur finger. Sometimes it is instantaneously sometimes it took a second or two, the red dot will disappear while the icon still present. Now u can safely remove the device. After the device is removed, the icon will disappear as well.
When u replug the device, after the icon shows up, it won’t automatically return to recording. U need to repeat the process above till the red dot comes back.
I do it every time, never had a corrupted file.
I used the same 128GB Samsung Fit Plus drive for months without issues but I've got a music partition on mine as well as the TeslaCam partition and I listen to music constantly off the drive. Maybe the fourth camera along with music playback pushed it over the edge because the too slow messages started showing regularly after the v10 update.
I switched to the SanDisk 128GB high endurance microSD plus SanDisk USB adapter about a month ago and configured it the same way and haven't seen an error since. Like you say though, who knows how long that'll last. I didn't want to take a chance of my old setup failing when I needed it most though.
Knightshade
Well-Known Member
Weird because there's been tons of threads over the last year with every type of storage, even SSDs, let alone SDcards having such problems.
Most of them eventually went away, with no HW change, just through software updates.
Almost like the software was the problem all along or something.
Probably because the math shows that it's true?
The amount of write cycles the Tesla is doing (even with 4 cameras) gives you an expected duty cycle of 5-10 years in typical use for average quality flash storage 128GB in size... double that for 256GB storage. "Endurance" memory will be 2-3 times more than that....but does anyone care if their dashcam video lasts 10 years or 20 years?
I do wonder a bit at your claim of wearing out regular flash in "a week or two" with a single 1080P stream though, unless it was a tiny card.
Let's use say a 128GB stick (which is probably as small as you ought go on the Tesla with 4 cams anyway)
Blackvue at 1080P, single cam, is only writing 1.5MB/s. Or 90 MB a minute. 5.4 GB per hour. 129.6 GB a day of writes...or 1.01 full write cycles per day.
Let's say you don't have a garage and always park in unsecured areas, so you run it 24/7/365. That's 368.7 full write cycles used in a year.
The crapiest type of flash used on the cheapest consumer storage these days is QLC, rated for ~1000 write cycles.
Or 2.7 years before it's used up.
Even if you only used a 16GB storage device for some reason (meaning you'd be losing video from overwriting ~every 3 hours) you should still get ~123 days of use before burning through it's rated duty cycle of writes.
Now... newer 4k dashcams are writing at much higher amounts of data... and often from multiple 4k cameras... so absolutely I'd go with an endurance card and nothing else there.
But Teslas system simply isn't writing that much data.
See again all the folks who are not using "endurance" storage over a year later and not finding the drive is worn out....let alone after a week or two as you suggest (since the tesla IS writing more than one "only 1080P" blackvue writes)
There's no "harm" in using one if you want to of course, and if you find a nice sale where it's just as cheap as "regular" stuff, go for it. But unless you plan to hand the dashcam footage down to kids not yet born when they graduate college it's not gonna do much for you.
....uh, no.
Go talk to anybody in IT support and ask them "Does every bug happen the same to everyone?"
Then wait till they stop laughing at the question. It'll be a while.
Also no.
We don't all have the same of either... some owners are on AP2 (S/X guys anyway), some on 2.5, some on 3... some with a hub or other device between the car and the storage (which impacts BOTH the data transfer potentially AND the amount of power available to devices connected that way).... some folks with music and cam on the same drive and some not... and folks are on LOTS of different versions of the car software at any given time.
What we do know is problems that do happen seem to happen around software updates...as do most solutions... most of the 0 byte file problems have gone away with newer versions, even on the same storage.... the "too slow" message only shows up (on otherwise working fine) devices in late builds of V9 (before cam 4 even got added, though it shows more often in V10).
Similar threads
