Slashdot Mirror
Using Sound To Test Internet Connections
sifi writes "An article in the New Scientist claims that by converting the frequencies of a 'ping' to sound it is possible to hear the reliability and strength of an internet connection.
They then go on to claim that all this is going to make telesurgery safe.
I quite frankly think that this is a case of the media printing something becuase it sounds (pun intended) cool. I'm convinced that there's nothing here that couldn't be done with a suitably clever piece of software - unless I'm missing something."
The Machine that goes "Ping!"
Diplomacy is the art of saying "nice doggie" whilst looking for a rock
That's always a good way to hear how good your connection is.
Doesn't that sound like Slashdot?
The difference, in this case is, that sound will relate a linear interpretation, end-to-end, where software will simply return a snap shot of any given element.
OBSTETRICIAN: Yes. More apparatus, please, nurse: the E.E.G., the B.P. monitor, and the A.V.V.
NURSE #1: Yes. Certainly, Doctor.
DOCTOR SPENSER: And, uh, get the machine that goes 'ping'.
Malike Bamiyi wanted my assistance.
Anything over TCP/IP is Digital... there is no frequency beside on and off.
The article says "Chafe wondered if variations in jitter [they defined as the deviations in the ping] could be converted into a musical form."
Fine convert the jitter to music... but how is that going to help you beyond what a numeric display would tell you?
I have a feeling none of these people have a clue about what they are babbling about.
'He was a dreamer, a thinker, a speculative philosopher... or, as his wife would have it, an idiot.' - Douglas Adams
Well... Technically if you take the lag between the different bits of the reception of the ping, you could get the "sound" of your modem/broadband.
... and it's hoping the usage of the different nodes are constant and have enough bandwidth to support the steam in the first place.
Other way, if you send 3000 1-byte pings and convert the lag of the pings to a sample, you should have a pretty good approximation of the discrepencies of your connection.
Now as to say where does these discrepencies come from, it's another matter altogether. To have a totally reliable solution, you should receive samples from every part of the traceroute and make sure that traceroute is kept for your "telesurgery".
I don't see it as baloney, it's certainly a novel approach. But as for an useful application, I'm less than sure. In a few years, maybe.
Mike
The last three main stories:
"I'm convinced that there's nothing here that couldn't be done with a suitably clever piece of software"
"Interesting story, no real information though"
"It's not a very substantive piece, but a good discussion starter"
I would hate to see the submitted storys that are rejected!
"wa#$tson, co@(me h@#ere! I nee#(d y@($u!!" Ping done. Reliability: 1
The article mentions that you could use this technique to monitor if the line is OK just before a critical operation. But will testing the quality of the line now give enough assurance that this quality will still be met in the middle of the operation, when there is no turning back?
I think that for these critical applications any simple test like this will never suffice, and you will need some way of guaranteeing that a minimal level of signal quality will be there, regardless of changing circumstances.
The human ear (and the corresponding piece of driver code in the brain) is very sensitive to regularities and irregularities in sounds. If you convert something to sound and get used to it, you can very easily spot how it "sounds wrong" when something changes.
Seismographists used to convert earthquake vibration patterns to human-audible sounds; this way it became very easy for a trained ear to distinguish between natural quakes and Soviet nuclear tests. On a screen, both looked like a jumble of lines.
Of course, a clever piece of software can do this too - but you already have this clever piece of software installed for free in your brain.
(Unfortunately it is free-beer, as the source is not available. Hmmmm, I guess rms should target God as the largest producer of closed-source software in the Universe?)
If you don't want to figure out how to insert a literal ^G, you can try this simple example:
testing a network in this way is near enough to useless to make no difference.
The concept is that of "continuity". We are surrounded by it, we are so used to it that we don't perceive it as such anymore: objects do not simply appear out of thin air, or disappear with/without a puff of smoke. Objects do have edges, but they are well-defined and predictable. For example: my table stops *there* [stares at table], right at the edge, and will continue to do so until further notice. If at some point it no longer stops *there*, e.g. because someone moved it, or it broke, then I probably will be able to tell why. In addition, I can judge the permenance of objects in the physical word with a good degree of certainty: I can tell the difference between a good, solid table, and a wonky one.
Networks are different: they go down for no apparent reason, suddenly, and without warning. They can be more or less robust, but I will not be able to tell how robust a network is with a couple a pings.
The physical-world analogy of that which is being proposed in this article is the following:
A surgeon knows from experience that her hands occasionally just disappear, and then reappear again a while later. She personally doesn't know why this is, but has gotten used to it. During surgery, it is bad for her hands to disappear. So, before performing surgery, she waves her hands about, shakes them, wrings them, and it they're still there, it'll probably be okay.
Great. The point is that what the surgeon needs to know about the network (or in the analogy, her hands), is *why* it disappears, and under what circumstances. Only then will surgery be able to be performed with a calculable degree of risk. So: build a dedicated network, with guaranteed ping times, zero jitter, et cetera. Then, once you have gained some faith that your network is reliable, by all means test it before using it, but do not rely on some arcane hand-waving to judge if it's good enough or not. If there is any reason that any parameters of a network may change during tele-surgery - like some PFY firing up Kazaa - then it's simply not good enough for the task.
yes, we have no bananas
"It's pretty simple, really," says Straub. "We just set up a couple standard gaming stations: one in the operating theatre with the patient, and one by the chief surgeon. They play against each other and report whenever they've been fragged. By tracking the frag rate, we can get a surprisingly accurate picture of the quality of the connection."
Because the gaming and surgical computers use entirely different protocols, there is no way for the two signals to get confused.
Straub admits that there is one thing that needs to be overcome before his method sees widespread use. "We've had a couple complaints from the surgeons about distractions from the gamer. And I can see their point. When you're chest-deep in someone half a continent away, you don't really want someone yelling '34t h0t l34d, suxx0rZ!' in your ear."
"But we're thinking of maybe removing the larynx of gamers for this. It's probably the simplest solution."
Open-source figurehead and programming guru Richard Stallman was unavailable for comment at press time. "He's having a gall-bladder operation right now," said a source close to the FSF founder. "He's going to be a few weeks recovering from the plasma burns."
Carousel is a lie!
http://www.tuxedo.org/~esr/jargon/jargon.html#ping
This was done years ago according to the jargon file.
Cynicism is the natural defence of the romantic.
I don't think the poster quite got the article. Regardless of whether this can be implemented in software or would require new hardware (don't know myself) this is a novel idea.
When you ping a machine from the command line, you get a list of ping times, which scroll by at a rate of about 2 per second or so. This doesn't show you the truly short-term behaviour of the connection. If I have understood correctly (and with the science writer "guitar string" crap removed), the idea here is to ping continually whilst playing a sound whose period (1/frequency) is the same as the ping time.
This has two advantages I can think of. The first and most important is that the ear is much better at picking up on a change in frequency than the eye is at picking out a couple of unusually high or low numbers in a scrolling list. This means that you can carry out a much larger number of "useful" pings (ie. ones whose results can be understood and used by an operator) per second. The second is that most networking applications (including telesurgery) don't make any use of sound, so the output of the pings is made continuously available to the user in a way that doesn't interfere with the task he/she is carrying out.
I don't know a thing about telesurgery, but if the very short term behaviour of the connection is important, this sounds like an ingenious way of keeping the user continuously updated.
"The Milliard Gargantubrain? A mere abacus - mention it not."
How about transforming each http request to the webserver to sound? It would be something like this:
g .i ngp ingi ii [blue smoke from webserver] piiiiiiiiiHONK... HONK[fire alarm going off]
ping........ping........ping....[slashdot story posted]....ping..ping...ping.ping..ping..ping.pin
ping.pingpingpingpingpingpingpingpingpingpingp
pipipipipipipipiipiipipipipipiiiiiiiiiiiiiii
"I'd rather have a full bottle in front of me than a full frontal lobotomy"
Hey, there's no 'ping' button on ie's taskbar, how can the average user know that command exists ?
'Ping' is a duck. I learned this in first grade.
(But check out This Amazon review (scroll down) by : John E. Fracisco. (No, the link doesn't give me referer bonuses or whatever.))
Opinions on the Twiddler2 hand-held keyboard?
When I was younger, I had a vacation job in an iron foundry (please don't ask why, the pay was shitty too) and I worked for a while in quality control. There was this old man there who used a hammer to test the newly casted pieces: he just hit them, and based on the sound he could tell if the casting had air pockets in it, or if the iron quality was sub-standard. The electronics which were purchased also for quality control were gathering dust in a corner. ... the old man was always right, even if the electronics weren't.
This idea of using sound to check connections may be less absurd than it sounds
---
"The chances of a demonic possession spreading are remote -- relax."
Pick up an cockpit and convert every signal into numbers in displays. Less than five seconds the pilot will search for the parachute...
In fact we are some sort of weird generation. Some sort of generation X that forgot that there are other means of information rather than listings falling into syslogs, icons shinning and popup windows. Back in the early 70's, when I saw the first computer (a beast called IBM/360), computers had beeps, shinning buttons, switches that turned automatically. Most of it have gone. Only the irritating beep on Linux command line, when you make some mistake, reminds me that once that was one of the main warning signals. Today's audible signals turned into a misture of music or small sounds that follows GUI actions in many details. However, this signalling is by 80% superfluous. You don't get anything from listening *woops* and *pops* while you're working. As you hear it coutless times, you get so used to it, that you may ignore any serious warning sound. It's just entertainement, nothing else.
The case of creating a audible ping is something that depends on two factors. Is this signalling important? Probably yes. With this you may get a control of network problems that may happen when you're doing something else. But the second problem might kill it. Is this signalling discrete and unique? Probably no. On my experience, I have seen lots of networks where ping timings bounce like crazy, in one moment you get 200us and right after that 2000us, then you fall into 10us and jump up to 1000us. Now, pick up this "audio-ping" and listen for a while. What will you get? Yes, MacBrains with cheesy ears. No information, no usefulness.
However, there are lots of chances to create a useful ping. Note that audio is just an abstraction, something that compresses the real data into a more compact form of information that is more perceptive than the original (btw ping itself is quite an abstract entity to evaluate network status). So if one picks the right signalling with the right timings and the right transmission, such audio-ping may turn into something very useful. But, this can only be seen after someone cooks the thing. Until then we can only speculate.
When I listen to shoutcasts if it buffers too frequently then I know the connection is not good.
[alk]
After reading that article, I have a picture in my head of a doctor in surgery garb holding a pair of defibrillator paddles on a Cisco router and yelling "Clear!"
When waiting for Gentoo to compile (zzzzzz) my mate and I were messing around with pipes, listening to the linux kernel source code, and other such exciting things ;-)
:-)
Anyway, we piped a ping through to the speakers and noticed a big difference between local pings and Internet pings, as well as Internet pings to UK sites and US sites. Probably the best use though was just to see if the machine was connected, and also to figure out which patch cable was the one belonging to the particular computer (start it pinging, then unplug until you hear no more pings!).
God bless UNIX