Showing posts with label but. Show all posts
Showing posts with label but. Show all posts

Wednesday, February 18, 2015

Google’s autonomous car gets a ‘B’ in driving test Not great but better than most of us

self driving head
Self-driving cars have come under increased scrutiny in the past week, as newly uncovered documents show that a 2012 road test for one of Google’s self-driving cars resulted in a pass very much without flying colors. The data in question come from government documents acquired through Freedom of Information laws, and show that on its Nevada driving test Google’s car had its share of small problems, and that it was never exposed to some difficult situations like railroad crossings, roundabouts, and school zones. There’s also some question as to whether Google was unfairly involved in designing the test, and that the Google team set the car’s route beforehand and specifically avoided troubling weather conditions. Additionally, at several trouble points the car decided it was incapable of proceeding safely and turned control over to its human occupants — and the irony of that limitation was simply too good for most media outlets to pass up.

Still, this latest “exposé” is not nearly as damning as some are framing it to be. To me, the interesting thing about self-driving cars is not the amount of trust that people are willing to put in self-driven vehicles, but rather the amount of trust that they are willing to put in human-driven vehicles. Most people’s reaction to driving algorithms involves questions such as, “What if there was a bug?” or, “What if you got hacked?” Such questions are best answered with a counter-question: What if your taxi driver had a seizure? What if your bus driver panicked in an unexpected situation? What if the trucker coming from the other direction simply fell asleep at the wheel?



Bear in mind that some maddeningly large portion of human drivers also don’t know how to deal with roundabouts, rail crossings, and similar situations, but that they have too much ego and self-interest to admit this fact and avoid a particular intersection. We accredit these people to drive because, a) the economy must continue to function even if most people are uncoordinated and easily distracted, and b) because we understand that licensing someone to drive is about telling whether or not they are good enough to drive. Every tiny mistake, from a missed shoulder check to an improper turning angle, could easily result in a death, so the point is not whether a driver could hypothetically make a fatal mistake, but how likely such a mistake is to occur.
Autopilot in planes, while less complex, has improved the safety of air travel.
Autopilot in planes, while less complex,
has improved the safety of air travel.

Additionally, most drivers can’t be usefully
trained how to react to things like aquaplaning or brake failure, and even if they have been trained they’ll often panic and take the wrong action. Self-driving vehicles, by contrast, can be given vicarious training on the level of a population — new research on how to handle ice can be distributed and perfectly internalized by every auto-car on the road, regardless of age. I can’t even get my grandpa to yield to buses! There seems to be something deeply welded into the human psyche, an impulse to be less fearful of dangers we understand. I can understand and empathize with my grandpa’s crusty stubbornness with regard to transit vehicles, and thus his dangerous driving is less distressing to me than the exact same behavior unconsciously executed by some faceless software construct.

When people point to the early-stage limitations of self-driving software as an attack on its chance of success, they are also making a second, more strident statement: that self-driving vehicles don’t just have problems, but that those problems are in fact more dangerous than the problems with human drivers. I don’t have to cite a glut of horrifying driving statistics to point out how absurd such an idea is, do I?  The extreme fallibility (and physical limitations) of human drivers are in fact pushing self-driving technology forward, as industry sees a chance to reduce liability; if you don’t trust the public-safety motivations of government overseers, then trust the profit incentives pushing corporations like Walmart away from accident-prone mammalian car-pilots.


A self-driving Prius much like the one that took the Nevada road test.
A self-driving Prius much like the one that took the Nevada road test
Imperfection in a self-driving system is fixable — a self-driving mistake that leads to a fatality can be used to prevent all such mistakes from happening again in the future. As such, bugs in software ought to distress us far less than similar or identical bugs in human ability. The safety of a road with even one human driver is dictated by the worst moment of the worst human driver in the area, while the safety of a totally self-driven roadway is dictated by the pinnacle of human mastery of software and multi-variable kinetics.
This test shows not that self-driving cars are as bad as a middling driver, but that they are as good as one. That’s better than any highway-driving population on Earth could ever hope to collectively deliver. Remember: it’s not about the car being better than you. It’s about you being worse than the car.
Read more »

Monday, February 2, 2015

Got slow download but fast upload speeds over wireless Heres a fix

If you find that your wireless download speeds are abysmal while your uploads speeds are pretty solid, especially with Apple devices, Ive got a possible solution for you. I struggled with this issue for a while and decided to write down my findings in a blog post in case I, or anyone else, runs into this in the future.

tldr: disable WMM QoS in your router settings.

Symptoms

At home, I have the following setup:
  • Linksys E1200 Wireless-N Router
  • Macbook Air: OS X 10.7.1, Intel Core i7 1.8Ghz, 4GB RAM
  • iPhone 4S: iOS 5.0
  • Custom desktop: Windows 7, Intel Core 2 Duo E8400 3.0Ghz, 2GB RAM
  • ISP: Comcast xfinity
Whenever I used my laptop or phone, the Wi-Fi connection felt incredibly slow. Youtube videos took forever to load, Google Maps tiles filled in slowly, and even gmail felt unresponsive. On the other hand, my desktop, which was connected to the router via an ethernet cable, worked just fine. 

Numbers

To confirm my observations, I decided to take some bandwidth measurements using bandwidthplace.com, speakeasy.net, and speedtest.net for the laptop and the Speed Test app for the iPhone. The results were pretty consistent across all app and device pairs and looked something like this:

Desktop
  • Download: 24 Mbps
  • Upload: 4.5 Mbps
Laptop
  • Download: 0.65 Mbps
  • Upload: 4.5 Mbps
iPhone
  • Download: 0.58 Mbps
  • Upload: 4.4 Mbps

Yikes! My laptop and iPhone download speed were more than 30 times slower than my desktops download speed! On the other hand, the upload speed was roughly the same on all devices. What the hell was going on?

Failed attempts

After googling for solutions, I tried a number of tweaks commonly suggested around the web:
  • Change DNS hosts
  • Change wireless channel
  • Change the wireless channel width
  • Use a different security mode (WPA2 personal)
  • Shut off firewalls
  • Enable or disable IPv6 settings
  • Reboot the router
None of these worked. 

The solution

Out of desperation, I started tweaking random settings on my router and stumbled across one that finally worked. The directions for other routers may be a little different, but heres what I did:
  1. Go to http://192.168.1.1 and login to your router. If youve never done this, look for instructions that came with your router or do a google search to find the default username and password.
  2. Find a page that has QoS settings. For the E1200, you need to click on "Applications & Gaming" and select the "QoS" sub-menu.
  3. Disable WMM Support
  4. Click save.
Thats it. The second I disabled WMM support, the download speeds for my laptop and iPhone both jumped to 24 Mbps, perfectly matching my desktop. 

What the hell is WMM?

WMM is apparently an 802.11e feature that provides higher priority for "time-dependent" traffic, such as video or voice. In theory, this should make things like VoIP calls and video chat (e.g. Skype) perform better. In practice, having it enabled destroyed my Wi-Fi download speeds. Since I disabled it, my Wi-Fi is blazing fast and Ive seen no negative side-effects.

If anyone has more information as to why this would be the case, please share it here.

Update (April, 2014): firmware upgrades

A couple years after writing this blog post, I hit the inverse of the original problem: I suddenly had fast download but slow upload speeds. While looking for a fix, I found out that the WMM/QoS issue mentioned above may have been fixed in newer firmware versions for my router! I once again wrote a blog post to capture all the details: Got fast download but slow upload speeds? Heres a fix.

Update (Sept, 2013): some nitty-gritty details

In the last year, this post has had over 100k views and helped many people fix their download speeds. Im happy I was able to help people. Other folks have been eager to share advice too: I got an email from a Russ Washington in Atlanta who did some impressive investigative work to uncover a potential underlying cause. In case it helps others, here is his email:
Yevgeniy: I ran into your blog post "Got slow download but fast upload speeds over wireless? Heres a fix." I have some info you may find useful. 
This happened to me too when I moved to Comcast - but I had DSL running in parallel. The Comcast traffic had this problem but the DSL did not. Also, it affected my Linksys router when it had stock firmware *and* after switching to DD-WRT. Clearly the traffic itself was at issue, so I broke out the packet sniffer. 
*All* inbound Comcast traffic (Internet --> client) was tagged with a DSCP value of 8 (Class Selector 1). The DSL traffic had a DSCP value of 0. So Comcast is tagging all traffic to be treated a certain way by QoS: "Priority," which sounds good but is actually the second-*lowest* possible. 
WMM, itself a QoS technique, apparently de-prioritizes (drops?) based on the Comcast-supplied value. Turning off WMM worked around it - but since WMM is part of the 802.11n spec, I wanted root cause. Judiciously replacing that set-by-Comcast DSCP value does the trick. 
So between my Linksys router and both ISPs, I had a Netscreen firewall. It lets me set DSCP values by policy - so I told it to match the DSL (DSCP 0). This yielded great improvement. However, I was still not getting full speed so even a zero value was not the best for > DSL rates. I set the DSCP value to 46 (Expedited Forwarding) and bingo, up to 20Mbps, almost full provisioned speed (25Mbps). 
Why only download issues? Because the only Comcast-tagged packets are the inbound ones: Internet --> you, including those big data packets. When uploading, yes, you get sent ACK packets and such - but they are tiny connection-control packets. I imagine WWM weirds out on them too, but you (usually) wouldnt notice when doing multi-Mbps speed tests. 
I am still trying to udnerstand WMM, but this was a big find, and I was lucky to have a firewall that let me packet-tweak. Hope you find the info useful. 
Russ Washington
Atlanta, GA

Update (Sept, 2014): more nitty-gritty details

Russ has found even more info about this issue: it turns out its not just a Comcast DSCP bug, but also poor handling of this bug by the firmware of many routers. More details here: Critical DSCP bug Affecting WiFi Download Speeds on Comcast. 
Read more »