PDF
Letters
To submit a letter, e-mail us at [email protected]
RFID Revisited
I enjoyed Roy Want’s article, “The Magic of RFID” (October 2004). It clearly outlined the technical and social problems associated with RFID (radio frequency identification) systems. I definitely do not want my personal info stored in someone’s database with my purchase data from RFID tags, so the kill switch is a good idea. Unfortunately, it does not solve the problem of retailers collecting detailed information on the buying habits of their customers and then selling or losing this data. It was a really great article. Please have more of the same.
Tim Eure, Port Orchard, Washington
Queueing Up Priority Queueing
In response to Vijay Gill’s article, “Lack of Priority Queuing Considered Harmful” (November 2004), I think using priority queuing against DoS (denial of service) is a waste. There is a lot of overhead involved in creating and maintaining extra queues, especially when DoS results in lost messages. Instead of having two half-size queues, it’s better to have one queue with a threshold to shed messages. Retryable and old messages can be dumped with appropriate logging when adding and removing. Minimal extra work is done with the same result. Dropping old messages provides an extra benefit when DoS starts using the priority messages in the attack.
This is just the KISS (keep it simple, stupid) principle, addressing the inevitable result. Why do more processing when messages will be lost, anyway?
Ben Kuehlhorn, Schaumberg, Illinois
VIJAY GILL RESPONDS: The priority queuing by itself will not be able to help. The ability to quickly discriminate between good and bad traffic and then place good traffic on a higher-priority queue is what is important. Maintaining state as to what messages you have seen sounds good unless you’re talking about several hundred thousand messages per second. Some of them are valid; the majority of them are not. The cost in CPU and bandwidth to keep enough state for that many messages is higher than just being able to discriminate and place them on the priority queue leading to the RP (route processor) of the router. I fail to see how you are shedding messages when the arrival rate is faster than what the RP CPU can keep up with, and/or the rate of arrival of messages overwhelms the control plane bus leading from the line cards to the RP.
Guru Code Overload
I know exactly where the so-called “guru code” you mention in From the Editors (November 2004) comes from. Before NT’s blue screen of death came the Amiga’s guru code, that black screen with the red letters that you saw on your cable TV. I think that the message originally said “guru meditation,” not “guru code.”
James Synge, Concord, MassachusettsIn reference to your November From the Editors, guru meditation errors are abend (abnormal end) messages from the Amiga operating system. As the system went down, it flashed a relevant guru meditation code and gave you an opportunity to save your files (nice touch—Microsoft should implement something like it any day now).
Amigas could process NTSC (National Television System Committee) video signals and were used in many cable TV operations. Quite likely, your entire cable system, not just the channel that you noted, is run by Amiga(s). Name another application that is run on a day-to-day basis by 18-year-old personal computers.
Edward Weir, Newton, Pennsylvania
QUEUE EDITORS RESPOND: Who knew that this bizarre error message comes from none other than the legendary Amiga? Well, apparently many of our readers, who flooded our inbox with information and anecdotes about these famous error messages.
Our favorite tidbit? The name guru meditation, as James Synge and others told us, stems from a game the Amiga’s developers played on a unique controller called a Joyboard, which in conjunction with a feedback program “tested how mellow you were by how still you sat” (for more information, see http://www.heartbone.com/comphist/Commodore.htm).
We edit letters for content, style, and length.
Originally published in Queue vol. 3, no. 1—
Comment on this article in the ACM Digital Library
© ACM, Inc. All Rights Reserved.