While I do not have data to back it up, my educated guess is the avg. USB drive can easily have 1/4s (or higher) 99 percentile write latency.
Even if you did have data to back that up, that'd still be 20 times lower than that other guy was suggesting for drive latency...hence why I mentioned your data debunks his claim.
Another important thing to not overlook is that we do not know how Tesla writes to the disk. Not in terms of sequential/random but rather the IO write request size. If I am writing the software that need to put the video on the disk, and consider the (maybe the most) important scenario - a severe crash with possible auto battery power cut off, I would try to buffer minimally and flush any buffers immediately so as to not lose the most important - the moments before the event. That is to say, the data stream from 4 cameras may cause multiple IOPS and at small request size. If someone has a drive that is failing the Tesla needs, I suggest using one of the oldest and simplest free disk benchmark tools - ATTO disk benchmark (see
Download ATTO Disk Benchmark 4.01.0f1). Check the boxes "direct IO" and "bypass write cache", set queue depth at 4, set IO size 512 - 4k and share the 4 readings for disk write speeds. If someone wants to go a bit deeper, I recommend the "gold standard" (at first looks complicated but it is not) which I use all the time at work -
TechNet DiskSpd: A Robust Storage Performance Tool
Here we get into "you can't have it both ways" though
Lastly, your comment that the issue is with different drives and camera versions and firmware. I often see people making the comment that they would reformat the drive and the issue would go away but a few days/week later the issue is back. That if anything proves it is the drives failing.
Not sure how? If the issue as the other guy suggests is just some "when a perfect storm of events happens for just a moment the drives specs are too slow just in that moment" then taking it out, reformatting it, won't magically make it fast
But if it gave the too slow due to poorly written software that had an issue just in that one moment, doing nearly ANYTHING would make the message go away for days/weeks until the bad SW glitched again.
And we ALSO have folks who say they just pull the drive, wait 5 seconds, then put it back in and it works for days/weeks again. No reformatting.
Which would be exactly what I describe- not bad HW. Bad SW.
So would drives (across types and brands) that worked fine before a SW update, but suddenly intermittently gave the "too slow" message after it. Which again is exactly that we saw in later versions of V9.
unless two drives are same age and had the same workload on them in the past they will perform differently.
True- though given the dashcam has only existed for ~1 year, and we know the amounts of data it writes, even someone running the system 24/7/365 wouldn't have used even half the write cycles yet on even the cheapest 128GB storage devices. Probably not even on a 64 given the fewer cameras ran for much of the time the feature existed, and most folks don't run 24/7/365 especially since for a chunk of time Sentry was never on unless you explicitly turned it on and most owners wouldn't have at home.
I've been using a dashcam for a couple years and went through 2 memory cards in that time. The cam manufacturer states memory cards are considered 'consumable.' Is this different for TeslaCam?
No, all flash storage is only "good" for some specific number of write cycles...(how many can vary depending on the type of flash used, but it's ~1000 cycles on the low end consumer stuff... 3-5k on the "decent/good" stuff... and 5-10k on endurance stuff... (and higher on crazy expensive Enterprise grade flash).
The main thing there though is Tesla is only 720p cameras at ~30fps, so they go through storage a lot slower than a similar set of 4k dashcams will. One 'write cycle" is, roughly, "the size of the drive" so it has to write, say, 128GB total, to "use" 1 cycle.
There's a number of posts with more detailed math if you want to see it in the thread.