Whether or not you consider it an important part of insider threat prevention depends on too many other factors (i.e., have you already prevented other, easier avenues of attack) to generalize, but it's not unreasonable to want isolation of jobs even within a single-tenant datacenter. You may also do things like run external code in sandboxes, and you'd like that sandboxing to be safe and effective.
You're going to make someone's life very special by having them deploy to a completely different environment than their secure workstation or build server and telling them that the security mitigations(or lack of) are causing an issue.
Yes, but even internally, separation between departments in a company is extremely important.
Google cannot have a breach between the services running gmail and the services running adwords for example, even if those are running in the same server on an internal cloud that has strict permissions being enforced by software.
This is especially even more relevant in any kind of datacenter application, even if the company is the sole tenant, because they are working with Client Data - which is data that does not belong to Google, but to their customers.
"Google's Borg system is a cluster manager that runs hundreds of thousands of jobs, from many thousands of different applications, across a number of clusters each with up to tens of thousands of machines. It achieves high utilization by combining admission control, efficient task-packing, over-commitment, and machine sharing with process-level performance isolation" [0].
All of their processes run together on the same machines so you wouldn't want to risk one compromised process access data on possibly any other process.
The historical context here is that AMD once had a monopoly inside Google's datacenters and pissed it away by shipping the horribly broken Barcelona followed by the not very broken, but also not very fast, Istanbul. This is a return to form for them, after a decade of poor form. The important thing for an operator like Google or Amazon is pricing power. As long as they can brandish a competing platform under the nose of Intel sales reps, they can get a better deal from Intel regardless of which they really prefer. You may have noted that a few years ago Google was showing a POWER platform at trade shows. That has the same purpose of putting Intel (and AMD) on notice that they have the capability to port their whole world to a different architecture if needed.
Sorry it is just not true that Google was AMD exclusive. During that time Google had a I/A release cycle where every other hardware platform cycled between Intel and AMD. I will give you that AMD had a huge issue launching and I still have my "Argo" bag that I got for helping with the hardware qualification trials, but Google was no way AMD exclusive before that.
You're right. There were also not a lot of AMD boards at first, to the point that services had to prove "Opteron worthiness". Unless your load tests showed improvements of 70% or faster, presumably what the most important products were seeing, you couldn't run on them. Those were the days. The next generation Intel systems weren't a great improvement, but they still ended up being built in large numbers.
> Google had a I/A release cycle where every other hardware platform cycled between Intel and AMD.
Was the I/A cycle intended just to keep Intel and AMD on their toes, knowing that Google's data centers and software seamlessly supported both platforms? Was there any technical benefit, other than ensuring Google's software was portable?
There was a delivery benefit. At the time we were one of the largest server manufactures by volume. Generally we were on the same scale as Dell or HP. Buying from only a single vendor had serious cost implications sure, but there was also a pure volume issues. If Intel can't get us 50k of a given chip fast enough we can fill capacity needs with an AMD platform instead. That was the goal at least.
AMD is not just competitive, it is better than Intel. Thus Google should adopt it and role it out, and faster than any other cloud provider. This will win them customers. I want 256 threads per machine at competitive prices.
Don't forget power consumption. Electricity costs are probably just as big as a factor as Cperformance when it comes to the number of computer Google has.
IBM quoted them as willing to switch to POWER if they could save 10% in energy costs
T3 are intel, newer than the T2, and perform worse than the T2. T3a are AMD and perform on par/slightly better than T3 for less cost. (From my own testing. Not a claim I can backup this is just my observation)
Where did you hear that? We're running a handful of m5a instances with fantastic performance. I figured they were priced lower because they're cheaper to purchase and operate.
Very few developers are prepared to write code that can efficiently use 256 threads / machine. At that level, cache coherency becomes a real and non-trivial problem.
In most cases, I suspect developers will see improved wall-clock times with substantively worse FLOPS/watt. Good for developers, bad for data-centers.
«Very few developers are prepared to write code that can efficiently use 256 threads / machine»
This junk justification has no longer been relevant for years. Most developers don't care because (1) they rely on core applications that are already multi-threaded (web servers, SQL engines, transcoding, etc), or (2) in today's age of containers, VMs, etc, it doesn't matter to them. Now we scale by adding more containers and VMs per physical machine. Bottom line, data centers always need more cores/threads per machine.
Correct, if you partition a 256 core machine into 32 virtual 8-core machines partitioned by their NUMA architecture - you are relatively unaffected by core count (minus the consequence of some scheduling algorithms not tuned for N > 8).
Unsure what the percentage of VM's that use no time sharing or oversubscription is though.
Most devs I know are creating async workloads which don't require cache coherency, as they use parallelism to parallel process separate requests and workloads. I can see things being pretty linear in that sort of space.
They are not linear unless all requests take an identical amount of time OR the system is not oversubscribed (common in many workloads) - and even then, the current linux CFS scheduler has a complexity of `O(log N)`.
When you have variable length requests, you will find cores will not always be balanced, it is simply a statistical reality. And in those cases, the kernel will have to migrate your process to a different core, and if you have 256 cores, that core might be really far away.
Except that they are typically not. The Zen architectures are NUMA and controlling where memory is allocated is key to decent threaded performance. You may even have to do seemingly counterintuitive things like duplicating central data structures across nodes and other tricks from the distributed systems playbook.
Yup everything is equally slow now. Kinda sad, but the original NUMA design was treated as a glass half empty situation instead of AMD letting people maximize performance. This change lets them avoid the bad press and everyone is happier despite the final design being slower than it could have been.
Epyc 2 has different memory latencies within and across NUMA nodes according to the infirmation I have. So it is not equally slow for all memory. Can you point me to a source that says otherwise?
Everything goes through the central crossbar on the I/O die, where Zen1 had memory attached directly to each CPU chiplet which would relay as necessary. On Zen1 if you accessed direct attached memory you wouldn't pay the latency penalty from relaying the data. In Zen2 all data is relayed via the I/O die with the associated delay that entails.
I did some more digging. It seems like the Linux NUMA topology shown in the anandtech article is a deliberate lie. There are different latencies between cores and memory comtrollers on the same socket, but these are deemed to be insignificant enough to not expose them in the reported NUMA topology.
Even with the mesh the number of hops is variable based on which core is requesting and the physical geometry of the chip. The cores right beside the IMC will have the lowest latency. See this diagram: https://en.wikichip.org/wiki/intel/mesh_interconnect_archite...
The main improvement is the max number of hops is log(n) instead N/2.
Epyc 1 was NUMA within the socket while Epyc 2 is officially UMA within the socket (although not really). Unfortunately Epyc memory latency is much higher than Intel so it's fair to call it uniformly slow.
Yeah, I actually was not so happy with the benchmarks because the memory access latency is not all that good... for most of the workloads that I care about, I don't know that the Epyc will be faster than a Xeon.
Must be strange to work on a huge technical project knowing your work will likely never be used and is there primarily to put pressure on someone else to lower their prices.
I guess you get paid, and can think of it like a hobby project for your own technical chops. But still.
"Upper management want us to be able to offload burst capacity to AWS, MS, Google or other public provider, do what you can to make it work but I reckon in-house can beat them on pricing"
Six months later -
"Congrats, good work! We showed them, we're getting a new data centre!"
A lot of people love working on more esoteric technical things and get more satisfaction from the intellectual component than its direct utility (I certainly feel this way about some things, though trans-architectural portability is not one of them). I would imagine this type of person is better-represented in this sort of field.
In addition, this kind of work does indirectly help keep Intel competitors viable, which helps keep Intel in check for everyone. Stuff like that is pretty exciting in its own way.
It’s an interesting concept to me. I do have a lot of “hobby work”, which is still meant to be used eventually. I just don’t apply a timeline, which enables me to focus on correctness.
Then I have my professional work, where the timeline is the primary focus, and correctness can only be pursued where it moves the timeline forward.
These projects you’re talking about are an interesting mixture. There is still a timeline that must be hit, because you need to do your demos, and you need to be ready to shift to a production timeline if negotiations go south. But since there are no customers the business model isn’t changing. And you don’t need to do any polish. So you can stay focused on the raw architectural problems.
It’s like my hobby projects in that you can focus on readiness over completeness, but there still is some timeline pressure.
Interesting to think about. Strange for me, but I guess it’s every day for others!
Tons of neat stuff gets built and then not used for a number of reasons (political, pricing, scaling, etc). It doesn't meant building it isn't worth it though.
Your right about pricing power. I think the net benefit from new competitive AMD chips will be to force Intel to adjust its premium pricing. Personally when I'm looking for personal needs or pricing out a build for use in work (basically not quite "big" data, but data about as big as can be done on a single high-end workstation) I don't really care about brand. I care about cost-performance factors, and component compatibility. I'll happily choose AMD if they're a 20% discount over Intel
The second is important. Customers need to adopt AMD EPYC. To our readers, it is important when you get a quote to at minimum quote an AMD EPYC alternative on every order. More important, follow through and buy ones where Intel is not competitive. If AMD EPYC 7002, with a massive core count, memory bandwidth, PCIe generation and lane count, power consumption, and pricing advantage cannot take significant share, we are basically done. If AMD does not gain enormous share with this much of a lead, and easy compatibility, Intel officially has a monopoly on the market and companies like Ampere and Marvell should shut down their Arm projects. If AMD does not gain significant share, there is no merit to having a wholistically better product than Intel.
As for bettering cost-performance, the full review gives plenty of context that the new Epyc 2's soundly beat out the current Intel Xeon lineup (often by 2X or more), but I think AMD is also doing what they need to do get marketshare (while still raising their ASPs):
When it comes to the top-bin SKUs, the value proposition is simple, just get a higher-end SKU and consolidate more servers to save money. AMD is extracting value for the higher-core count SKUs. For AMD a chip with 64-cores, 256MB L3 cache, 128x PCIe Gen4 lanes at just under $7000 compares favorably when its nearest Intel Xeon competitors are two Intel Xeon Platinum 8280M SKUs (M for the higher-memory capacity) that run just over $13,000 each. AMD at around $7000 is essentially saying Intel needs to start their discounting at 73% to get competitive, and that is not taking into account using fewer servers.
On the AMD EPYC 7702P side, AMD is calling Intel that if it wants to be performance competitive, it needs to discount two Platinum 8280M’s by 83% plus the incremental cost of a dual-socket server versus a single-socket server. This is a big deal.
The Barcelona chips initially had a pretty nasty bug in the TLB. AMD stopped shipments for about 5 months so they could put out a new stepping with the bug fixed. The Istanbul chips arrived a few months after Intel's Nehalem, which is where Intel caught up with features like the on-die memory controller and started roughly a decade of unchallenged performance lead.
The TLB bug (Errata 298, doc 41322 if you really care - while the processor was attempting to set the A/D bits in a page table entry, an L2->L3 eviction of that PTE could occur) was one of a great many things wrong with that chip.
* A number of errata (not just 298) delayed full production, sapped performance, or negatively impacted idle power. Take a look at doc 41322, DR-BA step for many samples.
* It was late and didn't achieve performance targets; it missed clock rate targets and 2 MiB L3 was insufficient.
* Intel delivered a very compelling server part (Nehalem) during the lifecycle of family 10h.
How do you measure performance per watt? FLOPS/watt? I don't think FLOPS is worthy measure of chip performance, since it doesn't take the L1/L2/L3 cache size into account.
Are there performance benchmarks that are designed to measure server application performance?
And it was a hell of a time to be alive. AMD was first to 1GHz, and the Athlon/Operton opening up the x64 (amd64) architecture was awesome. I didn't go back to Intel until the Core2 duo, which was also an amazing cpu.
Zen was originally led by the same person as Opteron/K8/Hammer, Jim Keller... who now works for Intel.
I think the situation is a bit different this time around though as AMD’s bet on TSMC is paying off in a major way while Intel continue to flounder in the fab space.
Going back a bit further, AMD spinning off GlobalFoundries and then shopping around for fabs on the open market is definitely looking like a very good decision with hindsight. GF has also, since then, run into problems rolling out a next-gen node, and eventually cancelled their 7nm. Hard to say how much you can credit AMD for foresight there vs getting lucky, but being manufactured by TSMC vs. in-house has worked out well.
I don't think this was obvious at the time. Some people thought it was a good move (obviously including the decision makers), but a good number of pundits interpreted AMD giving up on a proprietary in-house fab and relying on commercially available facilities as basically AMD throwing in the towel on being able to compete head to head with Intel as an integrated chip designer/manufacturer, relegating them to more the budget space. To be fair, at the time (2009), TSMC processes were behind Intel's, so you would've had to predict TSMC catching up and surpassing Intel.
I don't think the foresight is in a particular manufacturer but in the fact that each successive fab generation was becoming more prohibitively expensive and more dominated by economies of scale.
I kind of want to see an analysis of the minimum viable volume of product to justify a new fab process going back over the years. Today it's just not feasible, compared to Noyce et al who could do it in their lab.
What's fun about this is now Intel's world is on fire from a single source. The only way AMD could have guess that the TSMC process would improve so much is if they guessed that Apple would get into their own chip design (which only became clear in 2011-2012 and showed results in ~2014-2015) and would bankroll TSMC's 10 and 7.
Yeah but AMD should just beg Amazon to remove that instance type. It's hilariously slow. I don't know if Naples was just the beta of Rome or what but if you use it you won't like it.
Everybody seems to gloss over single-threaded performance. AMD is trading cores for clock rate.
I just put together an EPYC (Naples) 3201 (8 cores, no SMT, 2133MHz DDR4) and my circa 2012 Xeon E3-1230v2 (4 cores/8 threads, 1333MHz DDR3) is still faster because of the higher clock rate. More interestingly, the EPYC peaks at 45W at the outlet but the Xeon only hits ~55W. The EPYC advertises a 30W TDP, but IIRC the Xeon advertised a 65W TDP for the chip, so Intel substantially over performs.
I don't regret building the 3201, and I'm looking forward to the next generation of EPYC embedded.[1] But Intel still has superior design skills when it comes to power consumption and clock rates. I'd expect Intel to keep pressing this advantage, especially because at this point it's all they've got left.
[1] Anybody know when it's coming out? Are they gonna wait for Zen 3?
> Everybody seems to gloss over single-threaded performance. AMD is trading cores for clock rate.
No they aren't and no they didn't.
Obviously this review of the ultra high end is not focused on single thread performance because that'd be insane. But in segments where it does matter, like consumer, it was not glossed over at all.
And if you look at the comparison table AMD didn't really trade cores for clocks. Both the Epyc and the Xeons are all in that mid 2ghz base frequency range.
> But Intel still has superior design skills when it comes to power consumption and clock rates.
Except no not really. Clock rate yes, but AMD has an IPC advantage now so it's not entirely clear cut. And you only get that clock rate advantage on the consumer chips anyway.
Power consumption is not at all in Intel's favor, either.
> Obviously this review of the ultra high end is not focused on single thread performance because that'd be insane. But in segments where it does matter, like consumer, it was not glossed over at all.
I principally meant glossed over in discussion in threads like this. The review has a whole section on single-threaded performance, and Xeon comes out ahead:
It doesn't just matter in consumer land. It matters in some high-end workloads as well. I was replying to someone who lamented the poor performance of EC2 EPYC instances. Depending on your workload, they are poor performers.
I was very careful in my statement when I said that Intel has superior skill in designing for lower power or high clock rate. I did not say that that particular skill results in Xeons having a generally better performance, cost/performance, or power/performance profile. What I'm saying is that they can use that skill to anchor themselves at the very low power and very high clock rate niches to slow their decline.
AMD will continue to close the gap even in those respects. If I had put an EPYC 3251 up against my Xeon E3-1230 it would have smoked it at roughly the same power draw because doubling the core count absolutely matters. I'm not disputing that. And Zen 2- or Zen 3-based 3201 probably would out perform the 1230 as well without double the core count, though notably no such CPU exists at the moment. But people are underestimating what Intel still has going for them. Intel's strategy at this point will be to slow their market loss to buy them time to retool and counter, just like when AMD had the lead 15 years ago. Intel has some leverage to slow that loss.
And as some others have pointed out, Intel also has a huge product lineup. Do you know how many systems you can find with an EPYC 3000 series embedded chip? Only two: Supermicro in a miniITX form factor and Congatec on a COM Express Type 7 module. So, basically one as far as most people are concerned. OTOH, Intel has more SKUs in that market space than I can even be bothered to investigate, some of which are equal to or better than the EPYC in power, performance, and cost.[1] It'll take many more years for AMD to begin to displace Intel in those spaces. Again, that gives Intel time, breath spacing, and cash flow.
[1] I chose the EPYC because of Intel's poor security track record, and to support AMD. If the only thing that mattered to me was power, performance, or cost (individually or together) then a Xeon D would have been a smarter choice. EPYC Rome would likely change that, but there is no Zen 2/EPYC Rome embedded yet, nor any hint of one. I'm beginning to think it won't happen until Zen 3/EPYC Milan.
Hard to take seriously and barely rises to the level necessary for rational debate. Is there a workload that is demonstrably 100x slower on AWS or GCE compared to the fully-loaded cost of bare metal?
The TechEmpower benchmarks showed roughly a 10x difference in performance between AWS and bare-metal for basic webserving + DB, across many different languages and frameworks:
OK but that's a comparison of a $3200 machine with 7x more CPU and more than double the memory of the $100/month virtual machine. The operating costs of the metal machine (electricity, repairs) and its lifetime are unstated.
to be fair techempower benchmarks are not really "world comparable".
it's still just a benchmark. I know a lot of people take these benchmarks as their bread and butter, but there are so many "perf" hacks in them and they do not really have a lot in common with real world usage.
The author was largely focused on specific implementations over architecture patterns, so I wouldn’t think they’re operating at a level where TCO is a consideration...
"Well optimized MySQL" sounds a bit like having a really attractive liver cancer. Cloud services expand your options and it's worth pondering them. Don't ask what is the best MySQL, ask for a given amount of items I need to store and recall what is the best server OR SERVICE that could do it? MySQL on bare metal? On virtual machines? RDS? Cloud Spanner?
Do cloud providers increase your ability to choose scale-up instead of scale-out? Instead of your sharded and replicated MySQL that is almost inoperable and never seems to maintain consistency, would you be better served with one gigantic database? Sure it costs $13k/month to rent one from Google but it costs a quarter million to buy one from Dell. These are all aspects of the decision-making process.
MySQL-RDS is the AWS service which I felt gave me the least value for the dollar. (Except for the OpenVPN server which went nuts and did an obscene number of I/Os against EBS which ran up my bill)
I think you are overstating the case that the market will pass this saving through. In reality there is some market-clearing price for a dwelling without a parking space and there's nothing the developer can do to influence it. This is the same reason that it's actually not possible to "build affordable housing" as many people demand. Yes you can build the housing but there's nothing you can do about the price it then commands.
right, my skepticism was about the actual market dynamics and the forces that might compel pass-through savings via competition, not the econ 101 idealization of commodity markets.
In SF as well, but the local government has shown itself unable to resist calls to later add parking entitlements to structures after they are built. For example all "live-work" developments are forbidden by law from participating in residential parking permit zones, but the city council has repeatedly established RPP zones on blocks where the sole residential buildings are all live-work.
1 shared car is shown to replace between 7 and 20 private cars in various deployments. Building new housing with dedicated car-share parking is a great way to go.
Housing may be a little harder to accomplish usefully for the people that would live there for this idea, but business would likely work well. The problem with housing (if it encompasses a large area and not just small subsets of the available area) is that some people functionally need a car for their job or life. Cutting off large amounts of housing from those that commute or those that need to make semi-regular long trips for other reasons (maybe picking up children weekly for a custody agreement, or taking care of a relative that is semi-dependent).
Maybe paid dedicated parking separate from the housing and only allowed to people that live in the area (with an increase in price for a second car for a household) would suffice, as long as it was planned well. But that's the problem, poor planning (or changes over time) could cause problems again.
Car shares are definitely not for driving to work but I fail to see why you can't use them to pick up your kids. Car sharing solves the problem where people can easily journey to work without a car, but they want one for other purposes like shopping.
Provided that the housing wasn’t in some way differentially appealing to families with children (cheap 3BR, good schools, parks nearby, other amenities)
No, but to make sure we are talking about the same thing, a car share is a bit like renting a car by the hour. Uber is a computer-dispatched taxi service. Uber is not "car sharing". It is also not their other bullshit moniker "ride sharing"
I think there’s a fair argument that Uber Pool is pretty close to, or at least has substantial elements of, what one would naturally call ride sharing.
1. I'm not sure why you think this is inconsistent with what I said.
You seem to think it is?
2. I'm not sure what census blocks you are including in your definition?
For a very long time, LA was also very famously anti-pedestrian, both in laws and enforcement. It's trying to change for sure, but I would not say it's there yet.
The cars are the reason the buses are slow. 22% of LA workers travel to work without a car, which isn't great but it's not zero either. Metro LA added a dedicated bus lane on Flower and they are moving more than one bus per minute in that lane. As soon as you remove the cars everything else gets a lot better.
Are they? It's always seemed to me that frequent stops, circuitous routes and long travel distances are the reason the buses are slow relative to cars. After all, cars have to deal with other cars as well. And for comparison, to the south, San Diego has much better traffic than LA, but the buses are still quite slow (e.g. I recently considered taking the bus rather than a 15-minute drive in San Diego, but it would have been over an hour by bus).
Buses have to stop to be useful. Any theoretical bus route will be circuituous for some subset of users.
The solution to these issues is to provide bus signalization, dedicated lanes, and/or queue jumping opportunities. These changes minimally inconvenience cars while significantly speeding up buses. It makes it so that a bus route, while longer, can be time-competitive with driving (or rather, closer enough that it overcomes the inconvenience of walking to/from stops and sometimes having to wait for your bus)
You guys are both right. Removing cars from a bus lane makes the buses go faster.
And having frequent stops makes buses go slower.
Traveling long distances doesn't make the bus any slower; it just limits the frequency you can revisit a stop on the route without increasing the number of buses on that route.
I didn't mean long travel distances make buses go slower, I meant they amplify the disadvantages of buses, and America tends to have a lot of distance between things. If a trip would take one minute and it takes four instead, that's probably fine. If a trip would take 15 minutes and it takes an hour, that's a bigger problem, even though it's the same relative slowdown.
- Motorcycle to work: 15 - 20 minutes door to door (driving generally ~30 minutes, but 40 minutes or so during busy periods)
- Bus to work: > 60 minutes (7 minute walk, 5 minute wait, 45 minute average bus journey, 7 minute walk)
Cycling would, I reckon, take me about 45 - 50 minutes door to door until I got fitter, but that would be fine because I'd be getting loads of exercise, so the trade-off becomes worthwhile even though it takes longer. (The reason I don't cycle is there's no safe route.)
Presumably it just depends on whether the road is congestion. Roads are essentially non-rivalrous (my use of the road doesn't reduce your ability to use the road), until the road is congested.
Presumably most congested roads are used mostly by cars, so I suppose you could say that "cars cause congestion and congestion makes buses slower." But of course, the congestion also makes the cars slower as well.
There are different bottlenecks in buses depending on the situation, and I'm not familiar with LA. However, the places where I've tried using the bus, the latency involved in walking to the bus stop, waiting for the bus, getting off and walking to the transfer bus stop, waiting for the bus, then walking to my destination far exceed the delay added the stops the bus had to make. In many cases it exceeded the total time on the bus altogether. Increasing the frequency that buses run a route has huge impact on travel time, but there is a limit as to how much you can do that without adding a dedicated lane. The small improvement in speed caused by not having to deal with cars is just icing on the top.
I was pleasantly surprised with LAs bus system the last few times I've been. They have both express buses and ones that hit every stop. I also find LA to be very walkable.
Yeah, except no. This is just one of those tropes that motorists use to force cities to subsidize them. Every study on this topic has conclusively shown that parking causes traffic. The construction of parking precedes the worsening of traffic, the amount of parking built is proportional to the amount of traffic observed, and the reverse process is also observed to correct the problem: removing parking alleviates traffic congestion. The case that parking causes traffic congestion is as strong as the case that smoking causes lung cancer.
Hey, do you have anything handy to support this? I can totally do my own research if it's hard for you to recall your sources. Just hoping for a quick lead or two. If you roughly remember the title of the papers or the names of authors or the regions studied, anything at all, it'll help me search faster and I'd be mega grateful.
Construction of parking preceding the worsening of traffic is not the same as parking construction causing traffic congestion. Adding more servers behind a load balancer will also precede congestion on your network. Because you've increased your capacity to service additional throughput, but did not increase your network link to handle that higher throughput. So at some point, it'll start thrashing.
Same with parking. You build parking in areas where you anticipate increased demand or already have unmet demand. By building parking, you increase your capacity to meet that demand.
If you have unmet demand (i.e. not enough spaces for the volume of vehicles that wish to park in an area), you're limiting the economic throughput of that area. Yes, you're reducing traffic congestion in the process, but at a very real economic cost for those whom were being patronized by that now-gone traffic.
Same with anticipating new demand. If you're building in an area, you want to be sure the area has enough parking capacity to absorb the intended volume of people traffic your building will have. If you're building a new skyscraper or mall or big box store, that's likely not true. So you incorporate parking into your project. Once your building (and parking) come online, you'll start attracting a higher volume of individuals to an area. Which, except for the most underutilized or mature transportation networks, will have a corresponding impact on congestion due to the greater throughput of individuals to the area.
If you have mature public transportation, then your transportation network likely has the bandwidth to absorb this throughput increase with a lesser impact on congestion than if you're in an area with immature public transportation options. But mature public transportation tends to be very expensive to build and maintain. Which is only likely to happen after growing to the point of having heavy enough congestion to make such expensive and regionally disruptive changes both politically palatable and economically feasible.
If you want faster buses, evict the cars from the bus travel lanes.
That's hard to do without BRT - we have plenty of dedicated bus lanes (the right lane) around here, but they all allow cars for right-hand turns, so buses still get stuck behind a line of cars.
Without BRT and center-island boarding, it's harder to reserve anything but the far-right lane since the bus needs to get there to pickup/dropoff passengers.
> That's hard to do without BRT - we have plenty of dedicated bus lanes (the right lane) around here, but they all allow cars for right-hand turns, so buses still get stuck behind a line of cars.
Dedicated bus signalization, no right turn on red, and cars perform right turns from the second lane. Dedicated signal phase can be combined with separated bike lanes to improve safety for other road users, as well.
