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 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.
Heh. I'd pretty much though of doing the same thing, but added dropping the frequency of the ping based on the percentage of pings dropped; high pitched rapid beeps for a decent high speed link and steady dull drone for all packets lost. I suppose you could do something with the volume as well to indicate hopcount by getting quieter as you move further away...
UNIX? They're not even circumcised! Savages!
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?)
Checking current ping times is not much use for an important application where low latencies are needed. If the network is nice and fast before you begin the surgery, how do you know the ping times will still be as low three hours from now?
What's needed is some way to reserve bandwidth in advance, some kind of ICMP packet that says 'I want to be able to send packets quickly to the following address during the next three hours'. The router will reply with 'okay' or 'no, I can't guarantee that'. If the router has given you a guarantee then it can prioritize your packets during the timeslot you reserved. There would be an extra charge from your ISP for such reservations of course - and the ISP would pass some of this charge on to its peers. Indeed, the routers might be able to negotiate prices among themselves.
-- Ed Avis ed@membled.com
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."
i think a lot of you folks have quite missed the point.
picture the page in your newspaper that has the little weather contour map of the high and low pressure areas. This information could be much more simply depicted as a table of pressure reading at various map points, so why do we go to all the trouble of producing the picture? Because the human brain is good at extracting information from pictures, it follows the lines, it analyses the curves, it recognises the directional arrows and can extract the information contained in the data - which is exactly what you want to get across.
A telesurgeon has only two senses not already quite occupied, only one of which can be utilised for accepting the output of a computer. The brain is good at detecting harmonics in a sound frequency, so delivering the latency information in this way is very clever indeed.
If you really want to read some pointless raving put down the new scientist and go read some patents or something.
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.
I think the parent's point was that even if you do get this information without looking at a screen, what good is it to you? If you're trying to detect a huge difference so that you can stop working without worrying about packets being lost, then you can just use numbers. The "tone theory" is for hearing ultra-minute differences in network reliability, but at this small scale (I imagine we're talking ten-thousandths of seconds and lower, though the article didn't say specifically), it seems like jitter would fluctuate almost to the point of never being the same at any two instants.
What tangible advantage would this give a remote surgeon?
Later,
Patrick
In a recent eweek article ( http://www.eweek.com/search_results/0%2C3685%2C%2C 00.asp?qry=jaalam&site=eWEEK - sorry about the lack of html I am still mainly a paper oriented person) a company called Jaalam was mentioned that has a product called AppareNet that uses the ICMP packets to find out the health of networks and provide trouble shooting and status of networks. I actually saw an early demo of their product and it was impressive how it found latency issues, duplex issues, and bottlenecks across our company WAN just by doing an analysis of the data contained in the standard ICMP packet. It was also impressive that it did not trigger any of the firewalls along the way that look for scanners and such.
One of Verisign's services is telephone wiretapping. A telco can outsource their wiretapping function to Verisign, which then takes care of transmitting the calls to law enforcement or other wiretapping customers.
The way Verisign does this uses their control of the Signalling System 7 network, which controls phone call routing and which they bought a few years ago by acquiring Illuminet.
The basic concept is that Verisign alters the routing for the tapped phone so that all calls to and from it route through some Verisign tapping facility. Phone numbers today are somewhat "portable", which requires a DNS-like database lookup for every call. Change the database, and calls are rerouted.
This approach avoids the need to tap into the voice path at end offices. But there's a side effect. Because it changes the routing for the voice path, it has to change the time of flight, based on speed of light lag.
A useful tapping test for a phone is thus to measure its round-trip time to a nearby phone. Normally, local call latency is a few 8Khz sample times, under 1ms. But a round trip to Northern Virginia from a West Coast phone would add about 30ms of latency.
Using a short section of hose at each end to get the phones to feed back around the loop gives you a quick read on latency. If you hear a high-pitched whine, latency is normal; if you hear a low-pitched growl on a local call, the routing is nonstandard and something funny is going on.
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