Dallas’s slashed DUI enforcement = safer roads?

Even though Dallas slashed its DUI enforcement, key DUI-related stats are level or improving. Here’s the numbers:

The fatal DUI crashes uses the right axis. The DUI arrests dotted line is a linear approximation using actual stats from 2009 and 2015.
Fatal DUI crashes uses the right axis. The DUI arrests dotted line is a linear approximation using actual numbers from 2009 and 2015.

Despite a two thirds drop in DUI arrests:

  • Fatal DUI crashes didn’t meaningfully change.
  • All DUI-related crashes have dropped by 23%.

In a sloppy hit piece on Dallas police chief David Brown, WFAA journalist Tanya Eiserer misses this. Instead, she stokes moral panic to drive more enforcement.

Is ineffective enforcement an anomaly? Probably not. My doctoral dissertation was over a closely-related topic. In short, I found that differences in traffic ticketing levels have no effect on crash counts. This echoes research from other areas with similar findings.

Tanya ends her hit piece with this:

Last year, 15 men and women died in Dallas in drunken driving accidents. Tell it to them and their families that drunk driving enforcement isn’t a priority.

Tanya, that’s terrible! Dredging up the deceased in an appeal to emotion fallacy, all to promote something that may be ineffective, why? Shouldn’t we expect better from WFAA? (By the way, if only 15 died, then we’d have record-smashing safe year!)

In cutting DUI enforcement, Chief Brown reduced spending on something that isn’t working. But that doesn’t play into MADD’s neo-prohibitionist agenda, so it has to change, I guess?

(All numbers in this article come either from Tanya’s hit piece or TxDOT’s Texas Motor Vehicle Crash Statistics.)

US Youth Soccer screws over 1/3 of its kids

US Youth Soccer is changing. Soon, all youth soccer leagues will use calendar-based teams.

This is a mistake. In most states, the new system gives around a third of its youth new reasons to quit. It also makes determining age levels more confusing.

First, some background. I am in Texas. We use Sept. 1 for the cutoff for kindergarten. Children start kindergarten if they turn six between September 1 and August 31 of the following year. More than half the states use the same or a close date. (source)

The soccer year starts a month earlier: August 1 through July 31. This creates a small “twilight zone” for August birthdays: they get grouped with prior-grade kids. The fix is easy: August kids can “play up” with same-grade friends.

Here’s an example: I coach a U7 soccer team. U7 means the kids turn 7 this soccer year.

One of my boys has an August birthdate. He’s U6 in soccer despite being in the same grade as most U7 boys. Again, the fix is easy: he plays up into U7 to be with his same-grade friends.

The new, calendar-based system expands this “twilight zone”. It is 300% larger now, affecting 1/3 of my team instead of 1/12. It is also less forgiving. Here’s why.

Starting fall 2016, 1/3 of my team becomes U9, and 2/3 will be U8. This will happen to all existing teams with evenly distributed birthdates.

You can’t “play down” in soccer. That means my team’s older 1/3, who will be U9, cannot stay with their same-grade friends in a U8 team.

The younger 2/3, the U8s, could “play up” into U9. That’s unlikely: I doubt they will be ready.

If that’s not enough, you also have the relative age effect. This effect is where kids who would be the youngest on a team–birthdates towards the end of the selection period–are less likely to participate.

This makes sense: at younger ages, a many-month spread can mean a great deal in readiness for sport, both physical and psychological. This is not a new problem.

In a FAQ, US Youth Soccer downplays the relative age effect. They say calendar-based teams weren’t designed to address it. They omit that the change will make it worse.

Why? Remember the third in the “twilight zone”? They have a double whammy! They are the youngest on their teams. In addition from being separated from 2/3 of their friends, they are also hit with the relative age effect!

Calendar-based teams makes things more confusing for parents. The year used in the calendar-based system is the second year of a season. That is, for the 2016-17 season, 2017 is the year used for age eligibility.

At least in Texas, recreational soccer follows the academic year. Fall ’15 and spring ’16 are one soccer year. The current system, with the August 1 cutoff, complements the academic year. Same-grade kids are generally put in the same soccer age division. I can’t imagine anything easier.

Currently, the x in Ux stands for the age your kid turns during the soccer year. In the calendar-based  system, Ux is arbitrary and hard to figure out. Suppose a child has a November birthdate. When he enters soccer in the fall, his age division is based on the age he turns in two Novembers!

Suppose Little Sammy was born in November 2008. When you sign Sammy up for soccer in August 2016, Sammy will be seven years old. However, the age chart shows that Little Sammy will end up in U9 soccer! In other words, when Sammy signs up in August 2016, his age division is based on the age he turns in November 2017!

Why is US Youth Soccer doing this? Two reasons.

First, the “new calendar year system makes soccer easier”. (source) Except it doesn’t!

Second, it “makes it much easier for us to scout for the National Teams and find players ready to compete internationally.” (source) Wait, we’re increasing confusion, creating a new disincentive for a third of youth players, butchering teams, and making life hard for coaches, all for something that is a concern for vanishingly few players?

I’m not clear who’s best interest is in mind here. It’s not the families, the players, the teams, or the coaches!

(A note: US Youth Soccer is also switching to small-sided games. I support that change.)

Moto X Pure Edition (2015) + Sprint = no roam?

I have the Motorola Moto X Pure Edition (2105). It’s a great value, it’s unlocked, and it works on all major cell networks.

The phone worked great until this weekend. I went to Dinosaur Valley State Park near Glen Rose, TX for a campout with my Cub Scout pack. (I am Cubmaster.)

Glen Rose is in the middle of a large Sprint coverage gap, but at least there’s voice roaming:
Sprint in Glen Rose, TX
(from Sprint’s Coverage Check page)

And here’s the data coverage, which is “off-network roaming”:
Sprint data in Glen Rose, TX(from Sprint’s Coverage Check page)

The data roaming is only in theory. When I crossed into the roaming zone (westbound US 67 east of Glen Rose), I only had voice, no data.

Later that night, perplexed at the lack of data, I reviewed my phone’s roam settings. In the settings, I hit More under Wireless & networks, then Cellular networks. Here’s the dialog (notice the empty signal indicator to the left of the battery indicator):
Moto X cellular network settings

Below is what you see when tapping on System select:
Moto X system select

I changed this from the default Automatic to Home only. Predictably, the roam network disappeared. Changing back to Automatic, the roam network was still gone! Power cycling the phone had no effect.


The Preferred network type dialog had no effect. Here’s its default setting:
Moto X preferred network type

None of the other settings had any effect. I also tried toggling the Data roaming slider, but it had no effect. That makes sense because the phone detected no network anyway.

Somehow I got this alternate settings screen. I do not remember how I got that. Regardless, it had no effect. Here it is:
Moto X available networks

Sometimes I got a version of this that had two Extended Network selections:
Moto X available networks (two Extended Network selections)

Clicking on any Extended Network selection on either version of this settings screen had the same effect. You first see this for a while:
Moto X registering on extended network

Then you see this:
Moto X cannot connect

I also explored the Search networks and Choose automatically settings, but neither had any effect. The presence of Extended Network at the bottom makes it look like the phone in fact saw a network.

Ultimately, I got no cell access for the weekend. When we went home, I got an avalanche of text messages between Glen Rose and Cleburne. (They were alerts from an unprecedented IT outage at my employer.)

Did I need to update my phone’s preferred roaming list (PRL). I think no. First, if my PRL was bad, I wouldn’t have gotten any roaming as I traveled to Glen Rose. With the current PRL, I should have at least had voice the entire weekend. Second, I activated this phone just 13 days prior to the trip. Since the phone is unlocked and carrier agnostic, it would have to update its PRL upon activation. Even if an old PRL was buried in the phone, the lack of Sprint access at Glen Rose is not new, so a very old PRL ought to work fine.

What do I do? Is the Moto X unable to reliably roam if Sprint is my network? Have Motorola or Sprint acknowledged a bug?

OneDrive and 0x80270113 error

Error 0x80270113 is yet another mysterious Windows error that Microsoft doesn’t explain well. First, some background:

OneDrive for Windows 8.1 supports online-only files. It’s a great idea: these files look normal, but they take up almost no space. That’s because they actually only exist in Microsoft’s cloud and are not on your hard drive.

If you right-click on an online-only file and select Properties, you’ll see that the Size on disk field is just a few bytes. It’s only a stub file. If you open the stub file, OneDrive transparently downloads the full copy.

In theory, online-only files are a great way to share files across multiple devices that may not have enough drive space to copy all of them locally. Strangely, Microsoft is ditching online-only files for Windows 10.

Error 0x80270113 happens when Windows doesn’t know how to open a OneDrive stub file. Here’s how it happened to me:

I am quitting OneDrive because it’s slow. I have several gigabytes of files in OneDrive. I need to move them out of OneDrive.

Normally, moving files is a fast cut and paste operation. Normally, the file itself isn’t moved. Rather, a few bytes of filesystem data is tweaked to tell Windows that the file is in a new folder.

This is like adjusting highway signs to tell people a new route to a city. The city is still in the same place; all that changed was the route you take to get to the city.

Moving files out of OneDrive is like moving the whole city! Even if you aren’t using online-only files, moving files in or out of your computer’s OneDrive folder is a pokey copy-and-delete operation. With this, a copy of the file is made in the destination location, then the file is deleted from its source location. This is exponentially slower than a move.

As I have many gigabytes of files to move, I got impatient on the long wait. I stopped the move, shut down OneDrive, and used PowerShell’s Move-Item command to do a classic file move operation.

Oops! Move-Item isn’t aware of OneDrive, so it happily moved the file stubs without downloading them first. Only when I tried to open the OneDrive stub files when they were outside of the OneDrive directory did I get the 0x80270113 error! The error probably means is that you have a stub file outside of its OneDrive directory, and Windows doesn’t know how to deal with it.

To make things worse, after I moved all these files out of OneDrive, the OneDrive agent synchronized my now empty OneDrive folder, which caused all the online copies of the files to be deleted. (That is actually correct behavior: if you get rid of a file locally, it should also be removed from the online drive.) This means I was left with only stub files on my hard drive and an empty OneDrive. Is my data gone?

Luckily, OneDrive has an online Recycle Bin. I restored everything from the online Recycle Bin back into OneDrive. My local OneDrive agent then set up online-only stubs of all these files. Now I can use the Windows Explorer’s cut and paste feature to move these files out of OneDrive. I’m pasting them in the same location where I moved the files using Move-Item. With this operation, I am telling Windows Explorer to overwrite the stub files in the destination. This overwrites the tiny stubs with actual data.

At this point, you may ask, “Why did you move your files using Move-Item if you had set them to be online-only?” Answer: I never set any files to be online-only on this PC! I don’t know why that happened. All I can guess is one of:

  • OneDrive does this intentionally for some files.
  • OneDrive bug.
  • I had the OneDrive client running on two other PCs, and on both those other PCs, I set them to use online-only file copies. Perhaps OneDrive somehow carried that setting over to my main computer?

Regardless of why, this is a pain to deal with. I’m very fortunate that OneDrive’s Recycle Bin actually works!

OneDrive is throttled and slow

OneDrive has a low speed cap for new files. Uploading new files is slow.

To test, I uploaded several GB of data with Google Drive and OneDrive. I used NetBalancer to monitor upload speeds. Over 10 minutes, I averaged these upload speeds:

  • Google Drive (googledrive.exe): 2.3 MB/s
  • OneDrive (skydrive.exe): 0.2 MB/s

That’s right, OneDrive’s upload speed is about one tenth of Google Drive’s! This test was done over an 802.11n wifi connection to an unthrottled corporate network that has at least a 1.5 Gb/s upload speed to the internet. Yes, there was upload activity the entire time, although OneDrive paused uploads between files or batches of files.

Others experience slow uploads.

Also, moving files into your OneDrive folder is slow. Instead of a move, it does a copy-and-delete operation. This is painful on spinning media, especially with a lot of files.

OneDrive isn’t good. It’s slow.