Runners seldom hit the proverbial wall—that is, fall dramatically off their original pace toward the end of a race—in races of half-marathon distance and less. But it happens all the time in marathons. Why?
The prevailing belief has been that the wall occurs when a runner depletes his or her very limited reserves of glycogen, a carbohydrate-based fuel source for muscle contractions. The body stores plenty of glycogen to get through shorter races, but not always enough to deliver runners to the finish line of a marathon, especially if their pace is too aggressive.
This general explanation for the phenomenon of the wall in marathon running has stood up fairly well to scientific scrutiny. However, some runners hit the wall earlier than others, and some don’t hit it at all. Also, among those runners who escape the wall, some are able to do some at much faster paces than others. Obviously, then, glycogen depletion is a highly individual matter. Given this reality, what are the specific factors that determine the risk of glycogen depletion in marathons? And how can these factors be used to predict glycogen depletion for the individual runner and thereby help him or her choose a marathon pace that will avoid the dreaded wall?
Benjamin Rapoport of the Massachusetts Institute of Technology asked himself these questions and answered them by creating a mathematical model. He found that the primary factors that determine how fast and how far a runner can run before glycogen depletion occurs are aerobic capacity (or VO2 max), the mass of the runner’s leg musculature relative to the mass of the rest of the body, and the concentration of glycogen stores in the leg muscles and liver.
– The higher an athlete’s aerobic capacity is, the faster he can cover 26.2 miles, provided he has adequate glycogen stores.
– The larger the athlete’s leg muscles are relative to his full body mass, the higher will be the percentage of his VO2 max that he can sustain for 26.2 miles because a lower body mass means a lower energy cost of running and bigger leg muscles mean more room to store glycogen.
– And, obviously, more concentrated glycogen stores in the legs and liver increase the runner’s absolute endurance range. Training greatly increases carbohydrate storage capacity. Carbohydrate loading and tapering enable runners to exploit that full capacity.
The formulas that Rapoport made on the basis of these rules yield some interesting insights. For example, it helps to explain why an even pacing strategy is the best way to avoid the wall and complete a marathon in the shortest time. It turns out you use up your glycogen stores faster if your pace fluctuates above and below a certain average than if your pace holds steady at that average. Another interesting finding is that, theoretically, some runners do not need to carbo-load to avoid the wall in marathons. They are able to store enough glycogen to go the full 26.2 miles at their maximum sustainable speed on any given day. Carbo-loading will only give them extra reserves that they will never use. Rapoport’s model can also be used to determine how much supplemental carbohydrate an individual runner must consume during a marathon to “push back the wall” to the finish line at a desired average pace.
It’s pretty cool stuff. However, it’s unlikely that you will be able to practically benefit from all of this math. For to do so you need to know your VO2 max, leg muscle mass, and leg muscle and liver glycogen concentrations, and my guess is that you don’t know any of these variables, or even where to go to ascertain them.
But there’s an even bigger problem. Rapoport proceeds as if glycogen depletion were the sole limiter of marathon performance; this is clearly not the case. Exercise physiology is incredibly complex. Scores of interdependent factors affect performance capacity. It’s impossible to single out just one physiological factor and treat it as a stand-in for the whole mix.
Consider the fact that individual marathon times can be very accurately predicted from 10K race times. Glycogen depletion does not occur in trained runners of any ability level in a 10K race. But if marathon performance is entirely glycogen dependent, how can it be predicted from performance in a much shorter race that is glycogen independent? It doesn’t make sense.
The only truly global indicator of performance capacity is perceived effort. Perceived effort, or how hard running feels after a certain amount of running at a certain pace, is based on all of the physiological factors that influence our limits, including muscle glycogen depletion, dehydration, core body temperature, blood lactate levels, muscle damage levels, and so forth. For this reason, there will never be a more reliable way to pace a race effort than by feel. It’s not a perfect way, but it becomes more and more reliable with experience and it will always be more reliable than some complicated mathematical formula that focuses too narrowly on one piece of the puzzle.
I’m not saying Rapoport’s model does not make very good predictions. It does. I’m just saying I would never want to use it in place of perceived effort to pace a marathon. There are two reasons for this. First, perceived effort can guide a runner every step of the way throughout a race. But a predicted optimal pace based on Rapoport’s formula is static. It can’t help you deal with any surprises after the gun goes off. Second, perceived effort is what actually makes you slow down when you hit the wall. Bonking occurs at a variety of different muscle glycogen levels. The relationship between muscle glycogen concentration and fatigue is not consistent, which is one sure sign that it is not the only limiter of performance. But the relationship between perceived effort and exercise fatigue is perfectly consistent. When a runner starts to slow down “involuntarily” toward the end of a race, his perceived effort level is always maximal. So doesn’t it make sense to use perceived effort to avoid this situation?
Of course, one might ask why the wall is so common in marathons in the first place if perceived effort is so reliable. That’s a topic for another article.