You are here

Blogs

Planning commission, Tuesday, March 1, 2022

Video, meeting details from Legistar.

Sounds like the start was delayed by technical problems.

Various minor ordinance updates; most interesting to me is the R2A update. Actual vote is postponed till next meeting, in case the meeting start delay prevented any public feedback.

Commissioner Hammerschmidt asked what's left in R2A that's still noncompliant--would further small tweaks eliminate more? Staff wasn't sure, but could come back with an answer.

Longest discussion was probably on a tweak to Marijuana dispensary zoning which I didn't follow.

Commissioner Wyche asked how to get parking maximums on the agenda, and more generally about how Planning Commission gathers, prioritizes, and schedules work.

Planning Commission, Tuesday Feb. 15 2022

Video is here. Micing of in-person participants is inconsistent again, sometime they're barely audible. For some reason Legistar has no details on this meeting right now. (Update: they're there now.)

This was mostly a review of the 3874 Research Park Site Plan: a new office and R&D building. See also https://www.mlive.com/news/ann-arbor/2021/07/ann-arbor-development-expands-plans-for-flex-tech-building.html.

Some of the details (on energy conservation, stormwater management, etc.), are actually pretty interesting, but I skipped most of it for reasons of time. There was a long discussion about the mismatch with A2Zero goals. It's a reminder for me that we just don't yet have the systems we need to solve our climate problems.

At the very end is some more discussion about Planning Comission's role in implementing A2Zero.

Planning Commission, Tuesday Feb. 1 2022

Video of the meeting.

They're planning to consider elimination of parking minimums. Yay!

City-initiated rezoning Petition for State and Eisenhower Area: area north and west of Briarwood would be rezoned to TC1. Wonwoo Lee recused himself. (He works for Oxford Companies, which owns property in the area).... which owns a lot of land in the area). Good overview by Alexis DiLeo. More details in Legistar. (Look at the staff report.)

Kirk Westphal called in a few times mainly to talk about parking maximums: he's worried we'll get some very parking-intensive developments now that we'll be stuck with for decades.

Micing of in-person commissioners is inconsistent; I can barely hear Lisa Disch.

Shannan Gibb-Randall notes there are a lot of sidewalk gaps in the area and now's the time to do it. (Brett Lennart notes that any new development in the area will be required to build sidewalks.)

TC-1 Rezoning passes unanimously. Yay!

R2A updates

Planning Comission has a public hearing on some changes to the R2A zone tonight: Oops, note that's just the notice for a public hearing, the actual hearing is March 1.

Minimum Lot Size in R2A District: Amendment to Section 5.17.3 (Residential Zoning Districts), Table 5-17-2 (Two-Family Residential Zoning District Dimensions) to change the minimum lot size from 8,500 square feet to 5,000 square feet, to change the minimum lot width from 60 feet to 40 feet, and to change the minimum lot area per dwelling unit from 4,250 square feet to 2,500 square feet.

Cities are the most efficient places to live, but they've been getting steadily more expensive to live in, and Ann Arbor is no exception. So, I'm completely in favor of anything that makes it easier to build more housing on a lot.

Also see a map of the R2A zoned parcels, and charts with more details.

My naive questions:

  • Why aren't the new numbers lower? (Why not zero, for that matter? As long as it's safe and up to building code, are these minimums anything anything other than "you must be this rich to live here" rules?)
  • Will we update R2B and R4C as well?
  • How much potential added housing supply do these changes add on their own? (Are there lots that could fit more units under new minimums and, if so, how many?)

(Response from Brett Lennart: "The minimums are proposed to be lowered to be more consistent with the R1D zoning district. We don't anticipate
immediate review of the R2B or R4C lot sizes, but these could be evaluated in the future.")

Ann Arbor Home Occupation Regulations, continued

The Ann Arbor home occupation regulations ordinance revision came before planning commission again on May 18; for video of the discussion see:

https://youtu.be/3tRQGp5D_h4?t=796

See legistar for new ordinance language and staff report describing the changes.

The main change since the previous proposal is to remove the lists of specific prohibited or allowed occupations. In particular, the prohibitions of "recording studios" and "Machine shop/metal working", are gone. Those prohibitions were the targets of lots of complaints in public commentary.

Other changes were also in the direction of liberalizing the rules somewhat; see the staff report linked from legistar, above.

There was no more public comment at this meeting.

I believe the next step will be two readings at city council, but I don't see it on their schedule yet.

Ann Arbor Home Occupation Regulations

What kind of businesses are you allowed to run out of your Ann Arbor home?

Part of the answer is in section 5.16.6.H.1 of Ann Arbor's zoning ordinances; see p. 51 of this document, or these home occupation guidelines.

The ordinance is old, and it seems a good time to revisit it now that so many of us are working at home; so planning staff has proposed some revisions; they'll be discussed at the next planning commission meeting April 20, at 7pm.

Follow the link for agenda item 8-b, then the "related files" link to get to the most interesting stuff:

In particular, the new text says "the following uses are not permitted as home occupations":

  • Medical/dental office
  • Motor vehicle and engine repair
  • Furniture refinishing
  • Gymnastic facilities
  • Recording studios
  • Outdoor recreation activities
  • Medical/cosmetic facilities for animals, including animal care or boarding facilities
  • Machine shop/metal working
  • Retail sales
  • Commercial food preparation
  • Mortuaries
  • Medical procedures
  • Body piercing and/or painting, tattoos, or any type of physical therapy

This affects uses in residential zones. So, if you're wondering what would be allowed at a given property, you can look up the address on the city zoning map; residential zones begin with "R" (R1a, R2, etc.).

Planning commission will discuss this, then either turn it down or recommend it to city council. Then before it becomes law it will need to have a first and second reading at city council. It will probably change between now and then. Ways you can express your opinion:

  • Email planning staff at planning@a2gov.org and also request that they pass along your message to planning commission.
  • Email city council at CityCouncil@a2gov.org.
  • Email your specific council people; see here for ward map and list of council people.

You can also call in to speak at any of these meetings. Some planning ahead is required, especially for council. You get three minutes. It may also be worth coordinating with other people to make sure that all your points are covered even if not everyone is able to speak.

Though this wasn't on the agenda for Monday's special meeting of the planning commission, several people called in mainly to object to the "Machine Shop/metal working" prohibition; see the meeting video.

I haven't looked at it closely yet, and I'm not expert on any of this, but here's my knee-jerk reaction: some of the changes actually look OK, but I don't like the list of prohibited occupations. I object to several individual items on that list, but I'm also skeptical of the need for such a list at all. The prohibition against music studios, for example, is probably based on the potential for noise; but the ordinance already requires of home occupations that "No generation of dust, odors, noise, vibration, or electrical interference or fluctuation shall be perceptible beyond the property line." Why not leave it at that?

I'm also curious about some of those "performance standards". Do we really need the floor area limitation? "Electronically amplified sounds shall not be audible from adjacent properties or public streets": why isn't this already covered by the "no generation of dust, odors, noise, vibration..." rule above? And is it really reasonable to require absolutely *no* noise ever? Why is that "Cottage Foods Occupations must be located in principal residence", and not an ADU?

Under "prohibited home occupations" there's a catch-all "Any other use not allowed in accordance with 5.16.6.H.5 Performance Standards". Why not also allow any home occupation that isn't specifically enumerated, but that meets the performance standards?

The new language is more liberal in some ways, too, which I think are good; allowable visits are increased by a couple a day, and parking requirements removed (though with a new limit on the number of simultaneous visitors).

I hope the end result is to make things better for people working at home. I think that's staff's intention, despite some of the problems.

Talking to some people that have tried a variety of home occupations might be useful.

Also of possible interest:

Traffic! Traffic! Traffic!

We often hear that about 80,000 people commute into Ann Arbor for work. How do we know that? Where does that kind of number come from?

One source is the Census Bureau's OnTheMap site.

You can look up numbers there; to get the following chart, I searched for Ann Arbor city, chose "Perform Analysis on Selection Area", then "Inflow/Outflow" and "Primary Jobs" from the following dialog. This shows that about 86,000 work in Ann Arbor and live outside, 24,000 both live and work in Ann Arbor, and 19,000 live in Ann Arbor and work elsewhere:

You can also ask for multiple years:

The data is assembled from a number of sources; see the documentation at the OnTheMap site for details.

Semcog's Commuting Patterns site is another convenient source. They report that 72,552 people worked in Ann Arbor and lived elsewhere in 2016, and report 63,420 for 2010. So, their numbers are in the same ballpark as the OnTheMap numbers, and show the same trend, but it would be interesting to understand why they're different. The estimate of number of people working in Ann Arbor is very close (comparing the 2016 numbers--111,290 for OnTheMap, 112,878 for semcog), but their estimate of number of people both living and working in Ann Arbor is very different (24,230 for OnTheMap, 40,326 for SemCog).

Semcog's source appears to be CTTP, specifically I think it's mainly question 31 from the American Community Survey (ACS): "At what location did this person work LAST WEEK? If this person worked at more than one location, print where he or she worked most last week."

OnTheMap/LODES appears to be based mainly on unemployment insurance and (for federal employees), the Office of Personnel Management. Anecdotally, there's some skepticism about whether they get employer locations correct, and I also wonder whether they might be counting as in-commuters some students who list their parents' addresses on employment records but actually live in town. The LODES data may still be useful at least for comparisons across time, though.

We also have forty-thousand-some students who need to get between home and campus daily. Jonathan Levine points out SCIP, which has some useful data. They report 95% of student residences as in the "Ann Arbor area". Unfortunately they define "Ann Arbor area" using zip codes that extend out into the townships, so it's not directly comparable to the above data. They also have some interesting-looking information about commute modes and employees.

Of course, all this is based on data about where people live and where they work. It would also be interesting to compare with data about traffic; this county road commission site looks like one good starting point.

Other stuff to follow up on:

Making my home NFS server go faster for $22

It was time to replace my home file server, but first I needed to figure out how to solve a performance problem:

NFS is generally pretty good at reading and writing big files. If you're just copying a big file to an NFS partition, usually all you need to know is the bandwidth your network and your drives are capable of, and that will tell you how long the transfer will take.

So people are sometimes surprised when they need to do something that *isn't* just reading or writing a big file, and suddenly get much worse performance.

For example, let's extract an archive of the Linux kernel source. It's 176M. My client is connected to my server by gigabit ethernet, and the exported filesystem is striped across a couple of hard drives. It takes a couple seconds to copy the archive over, but a simple "tar -xzf ~/linux-5.9.tar.gz" onto the NFS filesystem takes nearly 2 hours.

The problem isn't the 176M; the problem is that it's trying to create about 75,000 files. Each file create requires a round trip to the server. Worse, the NFS protocol forbids the server from replying until it has guaranteed that the file is safely on disk. (The reasons for this are a bit subtle, but it's basically a consequence of the NFS protocol's guarantee to provide correct behavior even if the server crashes and comes back up while you're using it.)

Hard drives have RAM caches which allow them to respond quickly to writes, but those RAM caches are lost on power failure, so the NFS server code waits for the file to create to actually reach disk, an operation which takes the typical hard drive 10ms or more.

And "tar" isn't smart enough to use any paralellism--it's literally just creating a file, then setting some attributes, then writing the data, then closing it, then moving onto the next file. Do that 75,000 times, with several 10ms+ waits at each step, and it adds up.

So, you need faster storage. In particular, storage that's faster at committing data to "stable storage". (By which we mean, storage that will survive a power failure.) The traditional solution is a big fancy disk array with a RAM cache that's backed by battery, but those turn out to be expensive, and not something I want in my basement.

SSDs are fast, right? Well, yes, they're faster at most stuff, but it turns out that at this particular thing--committing data to stable storage--they're not necessarily much faster than hard drives.

The exception is "enterprise SSDs"--look for a feature that's usually called something like "enhanced power loss protection". These drives have big capacitors that work like batteries, so when the power dies unexpectedly, they have enough energy to get the data in their cache to stable storage before they shut down. They're a lot cheaper than big drive arrays. (And also much less annoying to have running in your basement 24/7.) But they're still kind of expensive.

But these days it turns out there's another option for cheapskates: this Intel 16GB Optane Memory. You can use it with Windows to do some special tricks if you have the right kind of motherboard, but it also works as a perfectly standard M.2 NVMe SSD. It's small, but it's only $22, and it turns out it's pretty fast at this one particular thing we need it to do--it can commit a write to stable storage in a fraction of a millisecond instead of needing 10ms or more.

Also, recent Linux kernels have a feature called dm-writecache that allows you to use a fast SSD as a write cache in front of slower drives. In my case I set up striping across two hard drives and the write cache on the Optane device with:


pvcreate /dev/sdb
pvcreate /dev/sdc
vgcreate export /dev/sdb /dev/sdc;
lvcreate -i 2 -l 100%VG stripehds
vgextend export /dev/nvme0n1
lvcreate -n optane -l 100%FREE export /dev/nvme0n1
lvchange -a n /dev/export/optane
lvconvert --type writecache --cachevol optane export

Then I NFS-exported /dev/export/stripehds.

All those file creates then go to the Otpane, which responds very quickly, and then they get flushed out to the hard drives over time.

The result is that the "tar -xzf linux-5.9.tar.gz" is down to 4-5 minutes. Still not great (it takes about 12s to a local disk on my machine), but a major improvement over 2 hours.

There's another way to do this, by the way: ext4 and xfs both allow you to put the journal onto a separate device from the device that hosts the rest of the filesystem. If you put the journal on the right kind of SSD (either an Optane, or an SSD with power loss protection), then you'll get a similar boost, though I find dm-writecache is doing better.

(Also, the 5.10 kernel I was using had a bug which limited performance; thanks to Mikulas Patocka for figuring it out. Hopefully the patch fixing the bug should be available in any kernel you'd use by the time you read this.)

There are still ways we could do better:

  • A high-end enterprise NVMe drive would probably be faster. I was going for cheap.
  • programs like tar could be rewritten to use parallelism.
  • If the Linux NFS server supported write delegations, that might help.
  • We've also considered adding support for write directory delegations to the protocol, which would allow the client to create files without waiting for the server. But that's a complicated project that would take a long time.

Planning Commission, Dec. 15 2020

Agenda and more here.

Not a complete agenda, just stuff I was mildly interested in:

Next meeting is January 5, 2021.

etrakit links

Have you ever wanted to link to a particular project or search result in etrakit? You can!

OK, this is the sort of thing that probably interests, like, 3 people. But maybe YOU are one of the lucky 3!

Some examples:

Pages

Subscribe to RSS - blogs