If *anyone* knows of a location that was fixed by the maps update, we can all check if we have it.
That's funny.
I can imagine the conversation with the police officers now.
You can install our site as a web app on your iOS device by utilizing the Add to Home Screen feature in Safari. Please see this thread for more details on this.
Note: This feature may not be available in some browsers.
If *anyone* knows of a location that was fixed by the maps update, we can all check if we have it.
I got a maps update last night. This after exchanging emails with servicehelpna@ a couple weeks ago and them insisting that I had the latest maps and calling into question the reliability of report(er)s here in TMC of new map updates. They said that maps were always distributed along with firmware updates, which is known to be false. (My map update came without a firmware update for the record.)
Aw heck, one more picture. This is the output from my Cacti installation at home, which showed a traffic "spike" last night of around 10Mbps for a little less than two hours. If the transfer were exactly two hours long, that'd be 2*3600*10/8/1024=8.8GB, so if you figure it was a little shorter and maybe with a slightly lower traffic volume, that'd be in the ballpark of the 5GB that was quoted upthread. The assumption of course was that this was the dominant traffic source at that time of the night, and that the traffic spike did indeed correspond to the map update. I don't have any more detailed statistics than that (maybe I need to re-set up NetFlow exports on my firewall or get the car onto its own SSID / VLAN).
View attachment 112172
I am running netflow. I was trying to figure out why my garage was pushing more traffic than usual this evening. I found that there is a lot of action on port 22 from an amazon compute instance. For the life of me I don't know why they would be pushing a map update through an ssh port but I can't think of another reason why my car would receive so many GBs otherwise. This is much more than a patch and way more than I would expect for typical firmware/os updates.
Cool! What NetFlow collector are you using?Sadly I think I disrupted the download as I was mucking about with the AP :-(. Coming over port 22 makes me fear a relatively fragile, human oriented, maps update process. I really hope they are using rsync or some variant to resume downloads. I would hate to see the BW bill to update thousands of cars repeatedly.
Here it is in cacti to compare with yours (pretty far upstream from the car).
View attachment 112218
And from my netflow collector (this graph only monitors the car)
View attachment 112219
That's pretty interesting. So just to confirm, not through the VPN?
Cool! What NetFlow collector are you using?
OK now this is kind of weird (or stupid or both). The Cacti graph I posted before was from the wired port of one of my wireless access points, and showed a more-or-less constant stream of about 10Mbps. Here's the WAN port from my firewall:
View attachment 112221
The plateau on the left is the supposed maps download. Same timeframe but the reported throughput is roughly half of what the access point measured. I'm unable to account for this difference. (Same measurement intervals for both, as far as I know.) Unfortunately Cacti polling of my firewall's interfaces is inexplicably broken so I can't compare against say a Cacti graph of the firewall's WAN interface. Guess I have some other debugging to do. But anyway if you believe my firewall's version of events, it'd be roughly half of what you get from the access point's numbers. (The firewall is running pfSense based on FreeBSD, the access point is an old Apple Airport Extreme, at this point I'm inclined to believe the firewall but there's no real evidence in either direction.)
Once again I whine ...
Tesla needs to add a polling icon to check for updates (either firmware or maps).
Here is what I saw on an older log where they are indeed using rsync to fetch the map updates:
{"url":"rsync://filesync.vn.teslamotors.com/mapdata/NA-Q413-5942e0a4/","target_version":"NA-Q413-5942e0a4","size":3627361703,"max_wifi_kbps":10000,"max_cell_kbps":0}
As you can see this also explains the 10 meg bandwidth.
There are lies, damn lies, and interface statistics . In your case the first lie is likely that they are both reporting at an equivalent packet depth. Some systems will include mac headers and some won't. There are probably a number of other differences but I don't poll apple or pfsense so I don't have any particular experience. If I really wanted to know I would grab iperf and run some tests. Don't get me started on 32bit vs. 64 bit counters.
Haha, I didn't know the part about MAC-layer headers.
iperf has some other weirdness in that it only knows how to compute bandwidth and throughput at the application layer, not taking into account TCP, UDP, or IP header overheads. (I "maintain" iperf3 as part of my day job, for small values of "maintain", and people sometimes forget things like this when trying to correlate iperf3 data with interface counters.)
To get marginally back on topic: My turn-by-turn arrows are blue now after the update, but I thought they'd always been blue. One of those crazy things where you stare at a screen and just thinking about it causes you to question your recollection of what it was like before.