|
This article was provided by Don Mitchell, owner and operator of RunTime Services. It was written in February 2001, and provides the best description we've found of the complexities of race timing. Some of the difficulties described here (multiple finish chutes, etc.) are nullified by the use of Chip Timing which is becoming more popular these days. Getting accurate results is not an easy task and this article will tell you how it's done by the best in the business.
See also our article on Chip Timing.
Race Timing - How It Works
by Don Mitchell
Runtime Services
Introduction
We in the finish line community - the people who manage the finish lines and do the timing and scoring - are never sure how much the runners understand about what's happening to them at a finish line. So in this document I've taken the approach that runners have very little knowledge about how finish lines and scoring work. And, by the way, I also think that's appropriate - the runner's job is to run the race, not to understand how it all works, which is our job. Still, our job is made much easier when runners understand why we need them to do certain things. Why, for example, is there always somebody yelling at you to hurry through the chute? Why do officials get so annoyed at bandits? Why should you make sure you're wearing the right number, and never, never wear someone else's number? Why might the time you recorded for yourself not match the posted time?
This document (February, 2001) is the revised version. I'm hoping that runners will e mail their questions to me (runtime@wzrd.com) and that I can use the answers to those questions to fine tune the explanation so that it's as useful as possible.
Background
To understand how our system works, you have to understand the problems it solves. There's nothing mysterious here, though there are many subtleties. You only have to take what you've observed as a racer and think about it a little bit. Most runners have raced in both large and small races. And surely everyone has noticed that at some races the finish line is very elaborate, with multiple chutes and even multiple finish lines; cones, people and orange tape are everywhere. And we've all been to those wonderful little low-key races where the finish line has been little more than a couple of workers and some cones. Why are they so different? Understanding that is the key to understanding how you get your time and place.
Time and Identification
You need some way to get both a time and an identification for every finisher. That's the basic information you need. That's the trick, whether it's a track meet, a small road race, or a huge one. The time comes from some sort of timing device right at the finish line, and the ID comes from the runner's number, or something attached to it (like a barcode).
Imagine a very small race, something like a sprint event on a track. Every runner has an assigned lane, and for every lane there is a person whose job it is to time the runner in that lane. The gun goes, the runners run, and after it's over the timers report in. "I got lane 1 at 10.32," "I got lane 2 at 10.28," and so on. The scorer looks for the fastest time, and it's done.
Or imagine the world's smallest marathon, like the "Last Chance" marathon held in Delaware Park in 1981, where, as I remember, there were twelve finishers. (I was the fourth.) As each finisher finished a single person easily recorded a time and an ID for him or her.
At a very small race you can do both tasks simultaneously - get the time, and figure out who it is. At a large race you cannot, unless you are using the new "chip" system, of which more later. At a large race there are too many finishers too close together, and no person could possibly record both a time and an ID for every finisher.
Splitting Up the Tasks
This is the key concept - dividing what at a track meet can be a single task (getting both time and ID) into two tasks -
(1) get the time, and
(2) get the ID.
This concept isn't new at all, and implementing it doesn't necessarily require any sophisticated equipment. After all, large and small road races were successfully scored long before computers and electronic timers came into common use. It's been used for decades. Even today, with amazing computing power at our disposal, we still use the same basic concept.
You put a timing device at the finish line and you record a finish time (FT) for every person who crosses the line. You don't pay any attention to who the person is, at all. You produce a list of the times at which human bodies crossed the finish line. Somewhere beyond the finish line you ID the finisher, producing a second list. This list is the runner ID's, in order of finish.
For example, your FT list might look like this:
1 14:31 (The first time recorded by the timer)
2 14:33
3 14:45
4 15:01
....
101 21:32
102 21:32 (The 102nd time recorded by the timer)
And your ID list might look like this:
1 23 (The first ID - the runner's number)
2 142
3 135
4 68
....
101 204
102 200 (The 102nd ID)
The FT could come from a stopwatch and be listed on a "tick sheet," as it was in the old days and still sometimes is, or it could come from a printing timer that spits out something that looks like adding machine tape, with every FT printed on it, or it could be transmitted electronically to a computer. It doesn't matter how it's done, because in each case the result is the same: a list of times.
The ID could come from a sheet of paper on which the runner numbers were written down, again as was done in the old days, or it could come from a pull-tag taken from the runner's number and stapled onto a board, or it could come from a spindle of barcodes pulled from the runners' numbers. Again, in principle it doesn't matter how it's done, so long as the list represents the ID's of all finishers in the order in which they finished.
The next task is to stitch the two lists together. In a perfect world it's easy. The first runner's performance is entirely described by the FT (14:31) and the ID (23). We know that runner #23 won the race (because his or her ID was in first place) and we know that the winning time was 14:31 (because that was the first time taken). Similarly, we know that finisher number 102 (who was runner #200) finished in 21:32, because 21:32 is the 102nd time taken by the timer.
In a perfect world, indeed. In the real world it's never that easy. In the perfect world we know that #200 finished in 102nd place in a time of 21:32, but in the real world there may be (and note well - that's may be) some uncertainty about #200's time and place.
Why? To understand why your time and place are sometimes not what you think they should be, and to better understand the sometimes staggering problems of finish lines and scoring in a real world, you need to understand something about the scale of things.
Finishing Density
What's the scale involved here? Well, at the 100th Anniversary 1995 Delaware YMCA JY Cameron Turkey Trot 8k (hereafter "Turkey Trot") in Buffalo, we had a peak finishing rate of 270 per minute (in minute 43). In other words, between 43:01 and 44:00 in the race, 270 runners crossed the finish line. That's about 4.5 runners per second. Between 39 minutes and 48 minutes there were well over 200 runners finishing every minute. At the 1999 Pittsburgh Race for the Cure we had a peak density of 377 runners per minute, which is about 6.3 runners per second.
The 1997 Ford Buffalo Marathon finished about 470 runners, but the peak density never went over 10. The People, Inc. Rat Race 5k in 1997 finished about 530, and the peak density there was about 60. The reason for the differences in these peak densities is obvious, isn't it?
The Ford Buffalo Marathon was 26.2 miles long, and the People, Inc. Rat Race only 3.1 miles. So even though the number of finishers was about the same, the densities were very different. This is because the finishers were much more spread out in the Marathon. At the 1999 Pittsburgh Race for the Cure more people finished in two minutes than finished in three hours at the Marathon. This difference is completely normal and expected.
Runner Control
You must have noticed that even though the finish line itself might be fifteen or twenty feet wide, you soon find yourself in a chute that's only a little wider than you are. There may be one chute or as many as six or even eight. The point is that even though you may cross the finish line in a pack, or even side by side with someone else, you are quickly gotten into line and moved down that chute with other runners. In a chute the runners are always in single file. In that perfect world, the runner (and thus the ID) order in that single file line in that chute exactly reflects the order in which the runners crossed the finish line. All scoring is built on the assumption that the order in the chute accurately reflects the order across the line.
And of course we know that this assumption is not always valid. Have you seen runners ducking under the ropes and leaving the chute? Have you seen runners passing each other - perhaps accidentally, perhaps on purpose - in the chutes? Have you seen runners jumping from one chute to another? Of course you have. But what you might not have realized is that these actions, which might seem to the runner to be of little consequence, destroy the order of finish and confuse the scoring. The guy who jumps chutes isn't just ruining his time and place - he's ruining yours, too, unless what he did can be detected and corrected.
And what about "bandits," people who ran the race and actually went through the finish line system? Apart from the fact that they're ripping the race off, they also confuse the scoring. If they stay in the chute once they cross the line, they don't disturb the order of finish itself, but they have already disturbed the timing. You can't expect the timer to figure out who's in the race and who's not. So when a bandit crosses the line there's going to be a time (FT), but there will be no ID since the bandit hasn't entered the race. If the error isn't detected and corrected, every single runner who finishes after the bandit will be given a time that's too fast. For example, suppose that a bandit finishes one place ahead of you, at 24:57, and that you finish at 24:59. Since there's no ID for him, but there is one for you, you get his time, which is wrong by two seconds. Maybe you don't care about two seconds. But if the bandit does his thing either at the beginning of the race or at the end, where successive times may be many seconds apart, you'll get a time that may be badly wrong. And if you're like most runners, you'll think that the finish line people made the error - but they didn't. It was the bandit who caused it.
So the bandit doesn't just rip off the race, he or she rips you off, too. You paid your fee, expecting to get an accurate time and place. The bandit steals that time and place from you.
ID
Runners can be ID'd in several ways, but we use barcode tags. These are the plastic tags stapled to your number. You'll notice that they have a barcode on them, an arrangement of lines that resembles the UPC code you see on products. (We use a code called "interleaved 2-of-5," in case you're interested.) The tag has to be pulled off at the end of the chute. It's put onto a spindle, which preserves its place in the finish order. Later on, inside, we scan those tags in the order in which they're on the spindle, and this gives us the order of finish.
Chute Arithmetic
The best tag pullers can process about 30 runners per minute - they need about 2 seconds to pull your tag, spindle it, and get you on your way. Of course they need less time if you've helped by already having pulled your own tag, and they need more time if you've got your number covered up, or have lost your tag (in which case they have to write out a new one for you) or have pinned it to your shirt. This is why you'll often hear workers exhorting the people in the chutes to pull their own tags - it speeds things up enormously if they do.
Why do we want to speed things up? It's easy. Once the density rises past about 30 finishers per minute, the tag pullers can't pull the tags as fast as the runners are finishing, which means that they can't clear the runners out as fast as they're coming in, and so the chute will begin to fill.
What on earth do you do if you have, say, 120 finishers per minute coming in, and can only clear them out at 30 per minute?
Think of a bucket with a hole in it, and now think about that bucket being filled by a hose. So long as the water coming in can get out, the bucket doesn't fill. But now increase the flow from the hose. The bucket fills, and overflows.
The analogue of an overflowing bucket is a finish line that "backs up." When there's no place to put the runners coming in, they can't get through the chutes and can't even get past the finish line, and the whole thing clogs up. It's a horrifying sight - the finish line people's worst nightmare. If you can't get people past the line, then obviously you can't even time them and you can't keep them in order, and the whole scoring effort is ruined.
Back to the bucket. How about punching more holes in the bottom? If you increased the water flow 4 times but also punched 3 more holes, making 4 in all, you'd be OK.
The same idea works at a finish line. If you have 120 runners per minute arriving, but you can put them into 4 chutes, you can handle the load. Each chute will clear 30 per minute. The first one fills - backs up towards the line - so you shift the finishing runners into the second chute. It begins to fill up, and when it does you shift to the third chute, and so on. By the time that the fourth chute has filled, you expect the first one to be empty, so you can use it again. And by the time it has filled, the second one should be empty, and so on.
When you design the finish line for a particular race, you have to figure out what the peak density is going to be, and then construct enough chutes to handle that time. It's interesting, when you think about it. You have to design for the peak, which might last only two or three minutes. Before that time, and after it, you don't need all those workers and chutes, but if you don't have them available for that peak time your finish line will fail. The runners are like a stream of water from a hose where you can't get to the faucet and control the flow.
Now think for a moment about your own behavior in the chute. Have you ever stopped walking in the chute because you were tired or felt sick? Somebody probably yelled at you to keep moving, or maybe even grabbed you and pushed you along or, if you were really out of it, pulled your tag, gave it to another runner to turn in, and hustled you out of the chute.
Do you see why? If you stop moving, the chute immediately begins to back up behind you. If you stop moving right after you enter the chute, the effective length of the chute shortens tremendously, which means that it cannot hold the number of people it's been calculated to hold before it fills. And that means that the chute directors will have to switch away from it before they want to, putting a greater load on the other chutes. And if they're in trouble too, the whole line can fail because even though the chute capacity was correctly calculated, the runners have made it unworkable because they haven't kept moving.
In a big, dense race a chute may fill in 15 seconds - yes, that's right, in fifteen seconds. So every fifteen seconds, at the peak, the chute directors have to figure out how to make a switch. The runners just have to help them do their job.
Basic Summary
Now you see that the basic idea is. You split up timing and ID collection. You construct a system to maintain runner order no matter how densely they finish. You try to generate a list of times and a list of ID's that are in the correct order, and you then match them up, assigning the times to the ID's.
And of course unless you're a complete idiot you know that there will be errors. So you design your scoring system to detect and correct them. This is very hard to do when working by hand, but with a well-designed computerized timing and scoring system most common errors can be detected and corrected so that the list of times and ID's matches what "really" happened out there very closely.
Fixing It Up
The most important key to correcting errors is what's called "select times." (We abbreviate them as ST.) An ST is a time that's taken for a particular ("selected") runner, and represents the actual time that that very runner finished. Of course it's done at the finish line itself. All modern timing devices have a keypad on which a runner number can be typed. A second person (or, often, a pair of people) select a particular runner every few seconds, type in the runner's number, and then hit a key to record the time. (Remember, the other timing person is recording a time for everybody, regardless.)
In a race of ordinary density we expect select times for about 40% of all finishers. In a race with light density we expect that 90% or more of the runners will have select times, and in a very dense race the percentage drops to around 20%.
Select times are crucially important in untangling errors. You can think of them as "check times," or "fixed points." Suppose we have this situation:
ID place ID list FT Place FT list ST list
123 144 123 27:49 144 seen at 27:49
124 256 124 27:51 256 seen at 27:51
125 567 125 27:59 567 seen at 28:10
126 888 126 28:10 888 seen at 28:14
127 204 127 28:14
Our initial stitching together is going to look like this, based on the procedure that the nth ID goes with the nth FT, that is, the 123rd ID gets the 123rd FT, and so on.
Place Runner Time Select Time
123 144 27:49 27:49 (Match)
124 256 27:51 27:51 (Match)
125 567 27:59 28:10 (Mismatch)
126 888 28:10 28:14 (Mismatch)
127 204 28:14
We are sure we know what happened at places 123 and 124, because we have two times for both these runners.
But at place 125 we have a mismatch. The next time in the FT list is 27:59, and so because #567 is the next ID in the ID list we provisionally assign 27:59 to #567. If we didn't have an ST for #567, we would have no evidence that anything is wrong here. But since we do, we immediately see that something is wrong. #567 was actually seen to cross the line at 28:10, so we have to assume that #567's true time was indeed 28:10. We also notice that #888 is being assigned 28:10, which doesn't match #888's select time of 28:14.
Can you see what's happened here? There's an extra time - 27:59. If we removed 27:59 entirely, then everything would match up. #567 would get 28:10, #204 would get 28:14, and so on. So the computer operator removes 27:59 and everything is OK.
How do you get extra times? Three ways.
One is timer error. No timing person can expect to time hundreds or thousands of runners without pushing the button too many or too few times. At the peak of a race the FT timer is bound to miss a few people or click too many times, but during the less dense periods this error will be a rare one.
The second reason is more common - bandits. Remember that the FT person cannot possibly decide whether a finisher is a bandit or not. He or she must record a time for every person who crosses the line, bandit or not. So that extra time at 27:59 made every single time past it wrong, thank you very much Mr. or Ms. Bandit.
The third reason is because a legal runner crossed the line but left the chute before he or she was ID'd. This has exactly the same effect on the scoring as a bandit does. There's no ID for that time, and unless the scoring system finds that error, all times beyond the thoughtless runner who left the chute will be wrong.
Now, as I've said, a well-designed and implemented computer scoring system can find these errors and correct them - but only if there are select times.
Of course, select times themselves are sometimes in error. No one can type runner numbers for an entire race without any typos, so sometimes we see wildly incorrect select times because the number was typed in wrong.
Select times can help untangle two other errors.
One of them is sometimes easy to fix but sometimes it can be hard. Consider this situation:
Place ID FT ST
445 246 40:19 40:21
446 642 40:21 40:19
It's easy to see what happened here. The actual order at the finish line must have been #642 before #246, according to the ST's. The fact that the ID's came in as #246 before #642 is best explained by inversion - that #246 passed #642 in the chute, so that #246's tag was pulled before #642's was. The tag pullers cannot be expected to know who actually finished first, since they're probably more than 100 feet from the finish line, and it's not their job anyway. They must assume that the order of finish at the time the runners get to them was the order of finish at the finish line.
Fixing a simple inversion is easy. But some inversions are more complicated. Consider this one:
Place ID FT ST
445 246 40:19 40:21
446 123 40:19
447 234 40:20
448 642 40:21 40:19
OK, now what happened?
It might be that #246 and #642 swapped places but #123 and #234 didn't, so that if we invert #246 and #642 we'll be all right.
But it might be that the whole block of four needs to be inverted. It might be that between the finish line and the beginning of the chute, the four runners who really did finish 642-234-123-246 got themselves mixed up and then entered the chute in the wrong order. It might be that the tag pullers were under pressure and "staged" a handful of tags rather than putting them on the spindle one by one, and that when they put the 4 tags on the spindle they dropped them on in inverted order. It could be that when the tags were read by the barcode readers, they were scanned in the wrong order. All of these errors can and do happen in the real world, though the last two are relatively rare.
I would clean up this situation differently depending on when in the race it occurred. If it was at the peak I'd most likely invert the whole section, because small-block inversions are common at the peak. If it was at the beginning or end, during low-density times, I would swap only the two runners with ST's, and leave the other two alone. In both cases I would recognize that I might be wrong, because I would be playing the odds based on what's likely to have happened out there at the finish line, based on my experience. With just the evidence I have, I couldn't possibly know what "really" happened out there.
The second situation that ST's can untangle is an error that the finish line people make. Did you think that the finish line people never mess up (or that the computer people never do)? They do it rarely, but it does happen.
Remember all that chute changing that has to happen? Each time a chute is opened, there has to be some ID for the chute-full of people, as well as ID's for the runners themselves. Each holder of barcode tags must itself be identified, otherwise how would we know which "batch," as we call them, was which?
We use large plastic "batch tags" marked 1,2,3, and so on. The winner is the first barcode tag on the spindle marked with batch tag 1. All the tags from the time the winner enters the first chute until the time the first chute is closed (and the second one opened) are in batch #1. The second chute-full is put on a holder marked as batch #2, the third on #3, and so on.
It can happen that the batch tags are handed out incorrectly. It might happen that the person responsible for handing them out grabs #16 when he should have grabbed #15, and then gives #15 when he should have used #16, which has already gone.
Back at the scanning site we cannot possibly know that this has happened until after the tags have been scanned. The software assembles the list of ID's in the assumed order of the batch tags. In this case, the list will initially have all the tags in declared batch #15 placed ahead of the tags in declared batch #16, because in the absence of evidence to the contrary we always assume that the order of batch tags represents the order in which the chutes were filled.
If we had no select times we could not detect that entire groups of runners had been placed in the wrong order and given wrong times, at least not until the runners themselves noticed and started to make their complaints, which would take the form: "I finished ahead to so-and-so but he's ahead of me in the results."
However since we do have select times, I would immediately notice that all the select times in declared batch #15 point downwards (later in time) and that all the select times in declared batch #16 point upwards (earlier in time). This is the "signature" of batch inversion. So I would then use my batch inverting procedures, swapping batch 15 and batch 16, which are just fine internally, but are themselves in the wrong order. Once I've done that, the order of finish will reflect what really happened out there, and the only errors left will be the runner ID - select time errors already mentioned.
Other errors
By now you can see how things can go wrong and how they can be fixed. Of course there are many sources of error, but fortunately most of them are small errors that are easily fixed. A missing time can be as easily fixed as an extra time, but of course since it's missing you don't know what its value is. At the peak of a race the time you generate to replace the missing one is almost certain to be accurate, but at the beginning and end when many seconds may elapse between times, it might well be wrong. There's no way around that without further information, which can only come from the runner.
Divide and Conquer I -- Multiple Finish Lines
Earlier I mentioned multiple finish lines. If you do chute arithmetic without worrying about practicalities, you might figure that you could handle a big race with, say, twelve or sixteen chutes. Sounds good until you remember that twelve or sixteen chutes presents you with a very wide area. You might have runners finishing across a width of thirty or forty feet, and you have to somehow move them all into one chute. It's very difficult - it's impossible, in fact. There are too many chutes to manage (remember about handing out those batch tags, for example) and you have to move the runners too far left and right. It's hard to manage those 250 runners per minute, very hard.
So you split the job up even further. Instead of one finish line with 16 chutes, you make two finish lines with 8 chutes each, and set them up side by side. Each finish line operates independently, with its own set of timers, tag pullers, and managers. The manager has to only manage 8 chutes, which is difficult but not impossible, and even at the peak would have to handle only half the runners. A well designed and managed multiple finish line system is "transparent" to the runner -- you don't need to know anything about which line you're using - you just use the one in front of you, depending on where you are on the road. In this area we identify the lines by colors: blue, red, green, yellow. So we have "blue tags" and "blue times," "red tags," and "red times," and so on. At the computer we process each line independently, and then merge them into a single list.
The 1995 Turkey Trot, with its 260 density, was handled with three finish lines. In 2000 we had a 5k with 21,200 finishers (Pittsburgh Race for the Cure) for which we used five finish lines. The peak density rose to well over 300 per minute (in some minutes nearly 400) and stayed there for 15 minutes.
Divide and Conquer II -- "Toll Booths"
During 2000, Runtime and WNY Finish Line Services began using what's called the "toll booth" system. In principle this is a multiple-finish line system, but instead of having a small number of finish lines, each with multiple chutes (as just described), a toll booth line has many single-chute finish lines. During 2000 we used 3 and 4 toll booth lines at St Gregory, Subaru, Nickel City, and Linda Yalem -- all good-sized, dense, short events.
It's like "parallel processing," really. If you have a single line you can have only one chute actively accepting runners at a time (the others may be busy, but they won't be accepting runners). So if you have two or three finish lines, the way we have in the past, you can have two or three chutes open at once -- even though you might have 6 or 8 chutes set up and ready to use. You still only can use one at a time, per line. But with toll booths you use them all simultaneously.
There are least two great advantages to the toll booth system. One is that there is no rope handling in front of the line -- there's usually no need to direct runners into any particular chute (as there always is in a multi-chute setup). Each runner finishes into the toll booth right in front of him or her. Second, the batch-tag management is much simpler. There's no need for a "tag manager" or for "tag runners" because all the tags for a toll booth are at the back of the line.
The drawbacks of the system are that considerably more processing is required (all the lines have to be merged into a single order of finish), and the physical/electronic timing setup is more complex. You need to have a FT button for each toll booth; the WNYFLS select timers have demonstrated that they can handle at least 4 toll booths from a single Time Machine. And of course once you get over 4 or 5 lines it's hard to find enough colors to go around, so we've had to scrap the line codes Blue, Red, Green, Yellow, and Orange and substitute boring old A, B, C, D, and so on. I guess that gives an upper limit of 26 toll booths!
So far, it seems like an excellent system and we plan to keep using it during 2001. At the Pittsburgh Race for the Cure, where we're expecting about 25,000 finishers (at 5k!) we'll use 12 toll booths plus another 4 configured into a toll-booth regular finish line combination.
You're Just A Number
Sorry to be the one to tell you this, but throughout most of these steps you are indeed just a number. It's only at the very last stage, when the age group or overall results are printed, that any names are attached to all these numbers. Up until then everybody is just a number. Sometimes runners don't realize what this means.
We cannot possibly know who is really wearing which number. We only know who is supposed to be wearing that number. If you wear someone else's number and run across the finish line wearing it, then that person's name (and age and sex) are going to appear in the scoring, not yours. How could it be otherwise? Everything in the computer system has linked the person's name to that number.
So much trouble is caused when people wear other people's numbers! Often we find that the "first woman" was really a man - that is, some guy wore a woman's number and ran faster than the first real woman. Since he carried a number assigned to a woman across the finish line first, that woman would be computed as the first woman because, again, we have no way to know that someone else wore her number. It's more common to find a person wearing a number of someone in a different age group, and running fast enough with it to win an age group award for the absent runner. Who's harmed? Well, the legitimate age group winner who was pushed out of the awards, for one thing, and might have gone home before the awards ceremony was harmed. The organizers don't like it because the runners think the organizers have made an error, and they haven't.
It's so easy to avoid doing this. Just tell the computer people that you're going to be wearing someone else's number. Any computer system that has any business out there scoring races can make a change like that in an instant. There's nothing to it, and I guarantee that no one is going to yell at you. They'll all be thankful that you were thoughtful enough to keep everybody from suffering needlessly. So go and have that edit made!
Step Up And Complain!
If you've been reading carefully you've seen that there are some errors that can't be detected without help from the runners. I always want to hear from runners who think that there may be something wrong with the scoring. In truth there rarely is anything wrong, but there might be. And if it's an undetectible error and you're the person with the missing evidence you'll be doing all the other runners a favor by finding where the computer people are, and telling them.
The Time On The Wall Doesn't Match The Time On My Watch
This is a common complaint. Most runners do not know that USA Track & Field has a rule defining how road racing times will be presented. It goes like this: we are supposed to record times to a hundredth of a second (for example, 14:25.43) but to report those times as the next higher full second, unless the decimal fraction is .00. In other words, there is no rounding as the term is commonly used. For example,
observed time listed time
14:25.00 14:25
14:25.01 14:26
14:25.43 14:26
14:25.99 14:26
The time you see on your watch will almost surely be one second faster than your time on the results.
The big digital clock is usually set fairly casually, incidentally, and so you cannot rely on it. It could easily be a second off from the time running on the timing machines, which in turn means that it could easily be showing a time that is two seconds away from your time in the results. And if you happen to look at the clock just as its digits are changing, you can easily see the wrong number.
I have to say that the complaint I pay the least attention to is - my finish time on the digital clock doesn't match the results. I never expect that it should, and I never adjust the times from my timers to match the digital clock.
Nerd Talk
Some runners want to know what software and hardware we use.
All our software is proprietary. Philip Meyfarth and I have written it all. We began developing the routines in 1981. They run under Digital Equipment Corporation's (now Compaq's) OpenVMS operating system (64-bit), one of the most widely-used multi-user operating systems in the world. Our system is easily scalable, that is, can be expanded and contracted to suit the job at hand. For example, we can run from 1 to 6 barcode scanning stations, as many as 6 on-line timing devices, and from 1 to 4 concurrently operating printers. We can interface with ChampionChip systems, too.
The heart of our system is Digital's 64-bit Alpha AXP processor, a member of the fastest RISC processor family on the planet. We've replaced the faithful old AlphaServer 300 4/266 with a 600 Mhz AlphaServer DS-10 (which is much, much faster than a 32-bit 600 Mhz Pentium) with 256 megabytes of main memory and up to 40 serial ports via 90-L terminal servers, to run the timing and barcoding peripherals.
p>We do use a few PC's, mostly laptops networked to the Alpha, involved in controlling the barcode reading software, for file transfer, and of course for Internet work, where the OpenVMS system isn't much use. We use Computer Identics barcode readers (6), Time Machine timers (5), and both Hewlett-Packard and Lexmark laser printers. If we scale the printing up for a large race we can print out 4,800 finishers a minute, ready for posting.
| 
