Friday, April 8, 2016
Taking a breather
With the sport's pre-eminent event being such an unreconstructed and largely irredeemable crapshow, we're taking a break.
Saturday, October 3, 2015
Race signups, fairness, and stress reduction
Today sign-ups for two of the most popular mid-distance races in Alaska, the Copper Basin 300 and the Knik 200, opened. Because they are so popular and tend to become oversubscribed there's a crush of entries as soon as they open. Unfortunately there have been technology failures for both races, and mushers don't know whether or not they're in. Copper Basin has responded by providing alternative mechanisms for entering, and the Knik is, so far, sticking with web-based race entry.
We've got a few goals here at Mushing Tech. Among them is that we'd really like to make life easier for volunteers - without them there's no race, and being a race volunteer can be exhausting and stressful. I have very little doubt that the Copper Basin and Knik volunteers handling race entries are extremely stressed right now. Additionally, a number of mushers are questioning the fairness of the entry systems. Towards the bottom of this post I'll discuss the fairness question in more detail (particularly sources of statistical unfairness) but I think the more important question is what can be done to make everybody's lives a little easier, reduce stress levels, and reduce both the likelihood and the impact of technology failures.
I think the number one thing that can be done to improve race registrations would be to move away from the current land rush model, where everybody's trying to get their entry in early. Using this model creates a load on the race registration system that unintentionally increases the likelihood of technology failure. If races were instead to announce that they'd be doing random drawings on a given date, mushers would be able to enter at their leisure by that date, use varying technologies to submit their entry application (email, postal mail, etc.), and would be less likely to feel disadvantaged if they have only very slow or intermittent connectivity. There are some excellent sources of randomness available both on our own computers and online (see, for example, this) which can be used to draw from the pool of entries. Races can set aside some slots for veterans or for people running qualifiers and do random draws for everybody else, etc. The main thing is to remove the pressures associated with getting an entry form in before everybody else.
Copper Basin has responded to their web outage by allowing mushers to enter by phone (voicemail) or email, and then the race organization will rely on timestamps to determine entry order. This has a number of problems with it, including that there's an excellent chance that the clocks on their computers and voicemail are not synchronized. Depending on whether or not the voicemail system is run by the phone company or is a home answering machine, it's possible that there's what's called in computing "head of line" blocking, where a queue is blocked on action on the head of the line, and queue members can only be serviced one at a time, unlike email, which can be received in parallel. Plus, voicemail is slower, both because of connection latency (the phone has to ring and be answered) and because it's just slower to leave a voicemail than it is to send a piece of email. So, we suspect that people who used voicemail to register were statistically disadvantaged relative to people who used email. However, people who live remotely and use satellite internet were disadvantaged relative to people who use DSL or cable for their internet connectivity, since the round-trip latency for satellite is at least 1/2 second (laws of physics!) and typically much higher. However, unlike the voicemail situation we'd be a bit surprised if delay associated with satellite internet had much of an impact on signup order. Similarly, if the issues with the Knik website are failures to establish a TCP connection to the race's web server, those who can retry quickly have an advantage over those with slow or high-latency connectivity.
At any rate, the goal here is to keep everybody happy: volunteers should not be stressed and mushers should feel that they're being treated fairly. We suspect that the current registration model doesn't really lend itself to that goal, and that a deadline model has a number of advantages over a land rush model.
We've got a few goals here at Mushing Tech. Among them is that we'd really like to make life easier for volunteers - without them there's no race, and being a race volunteer can be exhausting and stressful. I have very little doubt that the Copper Basin and Knik volunteers handling race entries are extremely stressed right now. Additionally, a number of mushers are questioning the fairness of the entry systems. Towards the bottom of this post I'll discuss the fairness question in more detail (particularly sources of statistical unfairness) but I think the more important question is what can be done to make everybody's lives a little easier, reduce stress levels, and reduce both the likelihood and the impact of technology failures.
I think the number one thing that can be done to improve race registrations would be to move away from the current land rush model, where everybody's trying to get their entry in early. Using this model creates a load on the race registration system that unintentionally increases the likelihood of technology failure. If races were instead to announce that they'd be doing random drawings on a given date, mushers would be able to enter at their leisure by that date, use varying technologies to submit their entry application (email, postal mail, etc.), and would be less likely to feel disadvantaged if they have only very slow or intermittent connectivity. There are some excellent sources of randomness available both on our own computers and online (see, for example, this) which can be used to draw from the pool of entries. Races can set aside some slots for veterans or for people running qualifiers and do random draws for everybody else, etc. The main thing is to remove the pressures associated with getting an entry form in before everybody else.
Copper Basin has responded to their web outage by allowing mushers to enter by phone (voicemail) or email, and then the race organization will rely on timestamps to determine entry order. This has a number of problems with it, including that there's an excellent chance that the clocks on their computers and voicemail are not synchronized. Depending on whether or not the voicemail system is run by the phone company or is a home answering machine, it's possible that there's what's called in computing "head of line" blocking, where a queue is blocked on action on the head of the line, and queue members can only be serviced one at a time, unlike email, which can be received in parallel. Plus, voicemail is slower, both because of connection latency (the phone has to ring and be answered) and because it's just slower to leave a voicemail than it is to send a piece of email. So, we suspect that people who used voicemail to register were statistically disadvantaged relative to people who used email. However, people who live remotely and use satellite internet were disadvantaged relative to people who use DSL or cable for their internet connectivity, since the round-trip latency for satellite is at least 1/2 second (laws of physics!) and typically much higher. However, unlike the voicemail situation we'd be a bit surprised if delay associated with satellite internet had much of an impact on signup order. Similarly, if the issues with the Knik website are failures to establish a TCP connection to the race's web server, those who can retry quickly have an advantage over those with slow or high-latency connectivity.
At any rate, the goal here is to keep everybody happy: volunteers should not be stressed and mushers should feel that they're being treated fairly. We suspect that the current registration model doesn't really lend itself to that goal, and that a deadline model has a number of advantages over a land rush model.
Thursday, July 30, 2015
How to access (and copy!) race spreadsheets
Hi, all!
I thought it might be useful to produce a video showing how to access race spreadsheets. I know that many of you are curious about what might be shown in data from past races and have questions that you'd like to answer, but haven't had the data to do it. Data acquisition is quite labor-intensive and not very much fun, so not there's not that much data out there, and what there is is often in, well, suboptimal shape. My race spreadsheets are in Google Drive and so are available on the web to anybody who's interested in taking a look at them, making copies, doing their own analyses, and so on.
So, I've made a video showing how to access them and how to make copies for your own use. I haven't figured out how to put clickable links in Youtube videos, but the folder containing the spreadsheets is here.
Have fun with it, let me know if you've got questions, and especially let me know if you find anything interesting! Future videos will show how to do simple calculations with the spreadsheets, easy plots (graphs), and so on.
I thought it might be useful to produce a video showing how to access race spreadsheets. I know that many of you are curious about what might be shown in data from past races and have questions that you'd like to answer, but haven't had the data to do it. Data acquisition is quite labor-intensive and not very much fun, so not there's not that much data out there, and what there is is often in, well, suboptimal shape. My race spreadsheets are in Google Drive and so are available on the web to anybody who's interested in taking a look at them, making copies, doing their own analyses, and so on.
So, I've made a video showing how to access them and how to make copies for your own use. I haven't figured out how to put clickable links in Youtube videos, but the folder containing the spreadsheets is here.
Have fun with it, let me know if you've got questions, and especially let me know if you find anything interesting! Future videos will show how to do simple calculations with the spreadsheets, easy plots (graphs), and so on.
Saturday, July 25, 2015
Doing data
I had big plans for the summer - getting some code written, some analyses written up, and getting the new Mushing Tech website up and running. Well, with one thing and another none of that has happened, but I thought it might be worthwhile to post something about things that people who are interested in a closer look at distance mushing race data can do for themselves.
Very broadly speaking, looking at the data involves two separate but related steps: 1) acquiring the data, and 2) doing the analysis.
Data acquisition and cleaning is a laborious grind. Right now race data tend to be in pretty shabby shape. They are generally available as as web pages, with no two races using the same format (even those using my spreadsheets have tweaked them for their own use, which is great but does increase the effort to take the data apart). Mostly they're available as web pages, which means scraping the data and converting it into a format that you can use with analytical tools. Worse, both major races have some major database errors - Iditarod's archived races have badly broken checkpoint links, and the Yukon Quest's archived races have screwed up bib numbers.
I've been pulling race data into my own spreadsheets using two mechanisms. For races underway, I manually enter data into live spreadsheets that I keep in Google Sheets. I've been bit-by-bit converting old race data by using table scraping tools available as browser extensions (for example, DataMiner for Chrome, and the extremely fabulously wonderful TableTools2 for Firefox). So, I do have a collection of race data available in spreadsheet form, here. Please feel free to use them yourselves, copy them, and so on. They are released under the BSD 3-clause license, so please respect that and provide attribution if you do use them.
Another source of data is the Trackleaders race tracking archive, and this is the really interesting one. For each race and each musher being tracked, the speed/time plot source data is actually embedded in the web page, and you can pull it out if you know where to look. I've got a Python program that does that and calculates rest schedules from it, here. Please feel free to grab a copy and tweak it for your own use (again, it's released under the BSD 3-clause license - it's yours to use as you wish at no cost other than providing attribution).
Okay, so that's the data side of things, but how do you learn how to look at data? Many people I've talked with have questions they want to ask about the data but aren't sure how to go about answering them.
One way is to ask someone with a stats background, but a more Alaskan approach might be to learn to do it yourself. There are a couple of possibilities at low or no cost.
Data science is a booming field right now and the educational resources are really impressive. There are a lot of new books, many of which require minimal technical background. O'Reilly has a remarkable collection in both print and ebook form. For example, Cathy O'Neill's "Doing Data Science" is a terrific book that gives you an overview of the approaches you can take to looking at data, while Joel Grus's "Data Science From Scratch" provides a hands-on introduction to a variety of analytical techniques while providing a grounding in Python programming (if you're already a Python programmer you'll probably want to use an existing data science module, like scikit-learn).
But, if you've got a computer and an internet connection, a better choice might be to take an online course at one of the MOOCs ("Massive Open Online Course"). Data science and introductory statistics courses are everywhere, and they provide an opportunity to learn new skills with as much or as little of a commitment as works for you. You can take one and do all the exercises and take all the quizzes (and earn a certificate), or just watch the lecture videos - it's all up to you.
Coursera features courses prepared by faculty at major universities and the quality is extremely high. As an example, take a look at the courses in the Data Science Specialization offered by Johns Hopkins University. They offer everything from a very high-level overview to a class on regression models. ("Getting and cleaning data" might be a good one for people interested in looking more closely at mushing data!)
Udacity is another popular MOOC site. It's more oriented towards practitioners and classes tend to be less consistent in quality than Coursera, but the are learn-at-your-own-pace with no deadlines for homework or quizzes, and some of the classes were developed by companies like AT&T and Google. They also have a large data science category, with some excellent introductory classes like their Introduction to Descriptive Statistics, as well as classes that might give you some idea about how to approach looking at mushing data, like their "Data Analysis With R" class.
And as I mentioned, I'll be making a few videos showing how to work with Google spreadsheets to look at data, dealing with questions like how to do arithmetic on dates and times, and how to do some simple summary statistics.
But summer passes quickly in interior Alaska. Yukon Quest sign-ups are in a week, and we should be able to start training the dogs regularly in about a month. It's starting to get dark at night and I think we're all looking forward to seeing the aurora again. But, in the meantime, there's summer to enjoy, fish to catch, projects to finish, and friends to visit. Have a great rest of your summer, and watch this space!
Very broadly speaking, looking at the data involves two separate but related steps: 1) acquiring the data, and 2) doing the analysis.
Data acquisition and cleaning is a laborious grind. Right now race data tend to be in pretty shabby shape. They are generally available as as web pages, with no two races using the same format (even those using my spreadsheets have tweaked them for their own use, which is great but does increase the effort to take the data apart). Mostly they're available as web pages, which means scraping the data and converting it into a format that you can use with analytical tools. Worse, both major races have some major database errors - Iditarod's archived races have badly broken checkpoint links, and the Yukon Quest's archived races have screwed up bib numbers.
I've been pulling race data into my own spreadsheets using two mechanisms. For races underway, I manually enter data into live spreadsheets that I keep in Google Sheets. I've been bit-by-bit converting old race data by using table scraping tools available as browser extensions (for example, DataMiner for Chrome, and the extremely fabulously wonderful TableTools2 for Firefox). So, I do have a collection of race data available in spreadsheet form, here. Please feel free to use them yourselves, copy them, and so on. They are released under the BSD 3-clause license, so please respect that and provide attribution if you do use them.
Another source of data is the Trackleaders race tracking archive, and this is the really interesting one. For each race and each musher being tracked, the speed/time plot source data is actually embedded in the web page, and you can pull it out if you know where to look. I've got a Python program that does that and calculates rest schedules from it, here. Please feel free to grab a copy and tweak it for your own use (again, it's released under the BSD 3-clause license - it's yours to use as you wish at no cost other than providing attribution).
Okay, so that's the data side of things, but how do you learn how to look at data? Many people I've talked with have questions they want to ask about the data but aren't sure how to go about answering them.
One way is to ask someone with a stats background, but a more Alaskan approach might be to learn to do it yourself. There are a couple of possibilities at low or no cost.
Data science is a booming field right now and the educational resources are really impressive. There are a lot of new books, many of which require minimal technical background. O'Reilly has a remarkable collection in both print and ebook form. For example, Cathy O'Neill's "Doing Data Science" is a terrific book that gives you an overview of the approaches you can take to looking at data, while Joel Grus's "Data Science From Scratch" provides a hands-on introduction to a variety of analytical techniques while providing a grounding in Python programming (if you're already a Python programmer you'll probably want to use an existing data science module, like scikit-learn).
But, if you've got a computer and an internet connection, a better choice might be to take an online course at one of the MOOCs ("Massive Open Online Course"). Data science and introductory statistics courses are everywhere, and they provide an opportunity to learn new skills with as much or as little of a commitment as works for you. You can take one and do all the exercises and take all the quizzes (and earn a certificate), or just watch the lecture videos - it's all up to you.
Coursera features courses prepared by faculty at major universities and the quality is extremely high. As an example, take a look at the courses in the Data Science Specialization offered by Johns Hopkins University. They offer everything from a very high-level overview to a class on regression models. ("Getting and cleaning data" might be a good one for people interested in looking more closely at mushing data!)
Udacity is another popular MOOC site. It's more oriented towards practitioners and classes tend to be less consistent in quality than Coursera, but the are learn-at-your-own-pace with no deadlines for homework or quizzes, and some of the classes were developed by companies like AT&T and Google. They also have a large data science category, with some excellent introductory classes like their Introduction to Descriptive Statistics, as well as classes that might give you some idea about how to approach looking at mushing data, like their "Data Analysis With R" class.
And as I mentioned, I'll be making a few videos showing how to work with Google spreadsheets to look at data, dealing with questions like how to do arithmetic on dates and times, and how to do some simple summary statistics.
But summer passes quickly in interior Alaska. Yukon Quest sign-ups are in a week, and we should be able to start training the dogs regularly in about a month. It's starting to get dark at night and I think we're all looking forward to seeing the aurora again. But, in the meantime, there's summer to enjoy, fish to catch, projects to finish, and friends to visit. Have a great rest of your summer, and watch this space!
Sunday, March 22, 2015
About that Iditarod post concerning Siberians
Over the years I've been a bit baffled by Iditarod fans being so enthusiastic on the one hand but knowing so little about the sport on the other. This year it finally dawned on me that the likely reasons are: 1) many of the fans are fans of the race, not of distance mushing more generally, and 2) if you rely on Iditarod for most of your information you're going to find yourself in the weeds fairly often. Yesterday's "Eye on the Trail" post on Siberians and Siberian mushers was a pretty stellar example of the latter.
There were a number of smaller problems (misspelling Yvonne's name, identifying Lev as a purebred musher) and some enormous ones. Failure to mention Lisbet Norris, who finished earlier the same day, is the scion of the oldest Siberian Husky kennel in the world and one that's been incredibly influential, and whose grandfather ran the Iditarod with dogs from the same kennel back in the 1980s, is probably the most glaring error in judgment, but a nod absolutely needs to have been given to Isabelle Travadon, who also ran a purebred team and who did a very creditable job when things got difficult under circumstances that led others to scratch.
Also: YES, Rob Cooke became the first Siberian musher to finish both the Quest and the Iditarod in the same year. He did it with substantially the same dogs in both races. Rob is a friend and we are so proud of him we could bust. This is a big deal, and the author of that blog post should have known it. I think it's also worth mentioning that Rob did not have a good Quest, that it started out badly and he worked through it, solved his problems and got his team to the finish. That, I think, is a huge deal and speaks to the kind of dog man he is, which brings me to my real beef with the Iditarod post.
Shortly after I moved up to Two Rivers and before Chris arrived I needed to travel for work, so I boarded my eight (!) (at the time - I'm up to 20) Siberians at a kennel in the neighborhood. The fellow who owned the place was chatting and said "I used to run Siberians," so I said "oh?," curious to see where this was going to go. He went on to say "but Siberians have too much sense of self-preservation. They'll sit down on you. Alaskans will just go until they drop." That was a bit of an exaggeration but not completely. Siberians will leave a little in the tank (okay, sometimes a lot in the tank) when calling a time-out, and it takes a certain kind of musher to successfully run a Siberian team 1000 miles. It is not a coincidence that Mike Ellis in particular but also increasingly Rob Cooke and some other up-and-coming purebred mushers are known for exceptional dog care. The people who successfully run Siberians in 1000-mile races tend to be very fine dog people, in part because they have to be.
At this point it should not be a secret that the two things that what people who don't know better say about Siberians, that they're slow and they're pretty, annoy a lot of Siberian mushers. Siberians have some traits that are highly valued in sled dogs: they have excellent feet, they're easy keepers, and they do extremely well in genuinely frigid conditions. They're tough dogs, but with an enthusiasm a friend describes as "joie de husky." And yes, they're pretty, but focusing on that is a bit like saying "What a pretty face!" or giving someone a Miss Congeniality award. It's a bit condescending and it's failing to acknowledge their qualities specifically as sled dogs. These are great dogs and tricky dogs and they're often being driven by great -- and underappreciated -- mushers.
I think this is a really great time for working Siberians and that it's just getting better, and I'm excited to see more purebred teams running Quest. In the meantime, when you see a purebred team finishing a 1000-mile race looking happy and ready for more, do not say "What pretty dogs." Instead, say "What a fine, fine dog musher. And wow, those dogs are pretty."
There were a number of smaller problems (misspelling Yvonne's name, identifying Lev as a purebred musher) and some enormous ones. Failure to mention Lisbet Norris, who finished earlier the same day, is the scion of the oldest Siberian Husky kennel in the world and one that's been incredibly influential, and whose grandfather ran the Iditarod with dogs from the same kennel back in the 1980s, is probably the most glaring error in judgment, but a nod absolutely needs to have been given to Isabelle Travadon, who also ran a purebred team and who did a very creditable job when things got difficult under circumstances that led others to scratch.
Also: YES, Rob Cooke became the first Siberian musher to finish both the Quest and the Iditarod in the same year. He did it with substantially the same dogs in both races. Rob is a friend and we are so proud of him we could bust. This is a big deal, and the author of that blog post should have known it. I think it's also worth mentioning that Rob did not have a good Quest, that it started out badly and he worked through it, solved his problems and got his team to the finish. That, I think, is a huge deal and speaks to the kind of dog man he is, which brings me to my real beef with the Iditarod post.
Shortly after I moved up to Two Rivers and before Chris arrived I needed to travel for work, so I boarded my eight (!) (at the time - I'm up to 20) Siberians at a kennel in the neighborhood. The fellow who owned the place was chatting and said "I used to run Siberians," so I said "oh?," curious to see where this was going to go. He went on to say "but Siberians have too much sense of self-preservation. They'll sit down on you. Alaskans will just go until they drop." That was a bit of an exaggeration but not completely. Siberians will leave a little in the tank (okay, sometimes a lot in the tank) when calling a time-out, and it takes a certain kind of musher to successfully run a Siberian team 1000 miles. It is not a coincidence that Mike Ellis in particular but also increasingly Rob Cooke and some other up-and-coming purebred mushers are known for exceptional dog care. The people who successfully run Siberians in 1000-mile races tend to be very fine dog people, in part because they have to be.
At this point it should not be a secret that the two things that what people who don't know better say about Siberians, that they're slow and they're pretty, annoy a lot of Siberian mushers. Siberians have some traits that are highly valued in sled dogs: they have excellent feet, they're easy keepers, and they do extremely well in genuinely frigid conditions. They're tough dogs, but with an enthusiasm a friend describes as "joie de husky." And yes, they're pretty, but focusing on that is a bit like saying "What a pretty face!" or giving someone a Miss Congeniality award. It's a bit condescending and it's failing to acknowledge their qualities specifically as sled dogs. These are great dogs and tricky dogs and they're often being driven by great -- and underappreciated -- mushers.
I think this is a really great time for working Siberians and that it's just getting better, and I'm excited to see more purebred teams running Quest. In the meantime, when you see a purebred team finishing a 1000-mile race looking happy and ready for more, do not say "What pretty dogs." Instead, say "What a fine, fine dog musher. And wow, those dogs are pretty."
Thursday, March 19, 2015
On Iditarod, justice, and "two-way communication" devices
As I wrote on my Facebook page, I haven't been saying much about Brent's disqualification because I am nauseated by it. I haven't wanted to participate in some of the technical nitpicking that's been going on because I think the real issue is justice. Whether or not there's a network available is irrelevant - nobody, including the race judges, think that Brent had any intention to cheat or had taken any actions that would give him an unfair advantage. At the same time they acknowledge that there are other mushers on the trail with similar devices and they're not going to seek those people out for punishment. So, unjust rule unfairly applied.
That said, I do think it's worth talking about the technology a little bit, because another problem is that the rule is very, very poorly specified and I suspect a competent lawyer with some technical expertise or who had access to expert technical witnesses could have a field day. The real question from where I sit isn't whether or not there's a network that a musher could access, but rather what constitutes a two-way communication device.
By way of context, one of the things I do to earn my dogs' kibble is develop internet protocol specifications, as a participant in and chair of several working groups in the Internet Engineering Task Force. We develop the core protocols that are used on the internet, including things like routing, security, transport, and so on. We are an organization of fuss-budgets, and our work consists of specifying protocol and device behavior to a level of detail that would make most people comatose. So, I feel pretty comfortable looking at something like the Iditarod's rule 35 and trying to figure out whether or not it makes sense.
The bottom line is that I think it probably does not, for several reasons. The primary reason is that it's overly broad and would exclude devices like Bluetooth headsets, which perform a (two-way!) negotiation with another device in order to pair. It excludes special-purpose radio/wi-fi devices which cannot be used for anything but the purpose for which they were developed (for example, Nikon cameras speak PTP/IP over 802.11, with the camera acting as the access point/hotspot - completely useless for anything but camera control and transferring images/video). They also incorrectly identify a SPOT and other trackers as a one-way communication device. Technically, they are two-way - they receive radio from satellites and uplink back to the satellites. They only uplink if they "know" they're in contact with the satellites. A DeLorme InReach Satellite Communicator, which falls generally within the same category as SPOT devices, allows the person with the device to send arbitrary messages. And what about a Fitbit? Technically, those are two-way communication devices, since they swap messages with your computer, tablet, etc.
And then there's the more general problem of keeping up as technology changes and develops. For example, what about the Apple watch and other "smart watches?"
This probably sounds like nitpicking, and it is. There are a lot of two-way communication devices that don't provide general communication facilities. You can't send and receive email with a Bluetooth headset and you can't browse the web with a Nikon camera (yet, as far as I know). The problem is that this is the rule under which Brent was disqualified, and the rule is a mess as far as the specification of communication capabilities. Because this is the rule that was used and because the penalty was so severe, its technical correctness matters a lot. As I said I think a competent attorney (and likely even an incompetent one) could have a field day with it.
The Iditarod organization has repeatedly demonstrated itself to be technically unsophisticated. Usually this comes out in the form of making bad decisions about writing their own tracking system, having their social media people provide technical support (badly), and so on, but here's a case where their lack of ability to describe what it is that they'd like to prevent has caused material damage to someone who even the race judges who made the disqualification decision agreed wasn't cheating.
Given that the problem that they're trying to solve isn't really a technical one, although it could be instantiated using technology, I think they are probably much better off trying to define disqualifying behavior rather than disqualifying devices. Their technical incompetence has led to considerable injustice against someone who did nothing wrong,
That said, I do think it's worth talking about the technology a little bit, because another problem is that the rule is very, very poorly specified and I suspect a competent lawyer with some technical expertise or who had access to expert technical witnesses could have a field day. The real question from where I sit isn't whether or not there's a network that a musher could access, but rather what constitutes a two-way communication device.
By way of context, one of the things I do to earn my dogs' kibble is develop internet protocol specifications, as a participant in and chair of several working groups in the Internet Engineering Task Force. We develop the core protocols that are used on the internet, including things like routing, security, transport, and so on. We are an organization of fuss-budgets, and our work consists of specifying protocol and device behavior to a level of detail that would make most people comatose. So, I feel pretty comfortable looking at something like the Iditarod's rule 35 and trying to figure out whether or not it makes sense.
The bottom line is that I think it probably does not, for several reasons. The primary reason is that it's overly broad and would exclude devices like Bluetooth headsets, which perform a (two-way!) negotiation with another device in order to pair. It excludes special-purpose radio/wi-fi devices which cannot be used for anything but the purpose for which they were developed (for example, Nikon cameras speak PTP/IP over 802.11, with the camera acting as the access point/hotspot - completely useless for anything but camera control and transferring images/video). They also incorrectly identify a SPOT and other trackers as a one-way communication device. Technically, they are two-way - they receive radio from satellites and uplink back to the satellites. They only uplink if they "know" they're in contact with the satellites. A DeLorme InReach Satellite Communicator, which falls generally within the same category as SPOT devices, allows the person with the device to send arbitrary messages. And what about a Fitbit? Technically, those are two-way communication devices, since they swap messages with your computer, tablet, etc.
And then there's the more general problem of keeping up as technology changes and develops. For example, what about the Apple watch and other "smart watches?"
This probably sounds like nitpicking, and it is. There are a lot of two-way communication devices that don't provide general communication facilities. You can't send and receive email with a Bluetooth headset and you can't browse the web with a Nikon camera (yet, as far as I know). The problem is that this is the rule under which Brent was disqualified, and the rule is a mess as far as the specification of communication capabilities. Because this is the rule that was used and because the penalty was so severe, its technical correctness matters a lot. As I said I think a competent attorney (and likely even an incompetent one) could have a field day with it.
The Iditarod organization has repeatedly demonstrated itself to be technically unsophisticated. Usually this comes out in the form of making bad decisions about writing their own tracking system, having their social media people provide technical support (badly), and so on, but here's a case where their lack of ability to describe what it is that they'd like to prevent has caused material damage to someone who even the race judges who made the disqualification decision agreed wasn't cheating.
Given that the problem that they're trying to solve isn't really a technical one, although it could be instantiated using technology, I think they are probably much better off trying to define disqualifying behavior rather than disqualifying devices. Their technical incompetence has led to considerable injustice against someone who did nothing wrong,
Thursday, February 5, 2015
The Yukon Quest on GPS or Google Earth
Last year, we provided some Iditarod track files for quite a large number of software applications. This year, for the Quest, I've prepared copies of the most popular file types:
 |
| KMZ file loaded into Google Earth |
The files contain the same information: checkpoint (and dog drop etc) locations as well as the race trail for odd years. I condensed this data from a variety of sources and hand-cleaned it, but obviously it will only be approximate, and the trail will vary from year to year. Also, because the trail is made up of points that are about half a mile distant, the total distance is being underestimated (it comes out to 911 miles according to this track). So please take this (ENTIRELY UNOFFICIAL) file with a good pinch of salt! If it is helpful or useful, I'd be glad.
Subscribe to:
Posts (Atom)