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."
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
Perhaps, but ever tried something like this?
ping 192.168.60.254|sed 's/ttl/ttl^G/g'
^G is ctrl-g, possibly ctrl-q,ctrl-g or ctrl-v,ctrl-g depending on your shell. It's really easy to "hear" a few ten ms differences between individual packets, and obviously you don't need a display to hear connections failing..
"Ten years from now, they could do it in a few seconds." -- The Racketeer of the Hellfire Club, 1993, Phrack 42
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
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.
Oh, it's not a guage, oh, why don't they print out a number... Sounds like a bunch of frustrated programmers who haven't had an idea of their own.
... It's so simple, it's perfect. Like treemaps. Have you ever seen hiarchial data represented in such a useful manner?
It's called human computer interaction. The doctor has his hands and eyes full. A small auditory queue of whether it's safe to try to move that robotic arm (via an APPROPRIATE interface, not the keypad on your keyboard) is of great benefit.
It's simple, effective, and doesn't require an understanding of networking or what the numbers mean. Low pitch bad, high pitch good (or whatever the mapping is)
snoop (the packet sniffer in Solaris) has had an option to "listen" to packets since at least SunOS 5.6: ... snipped from man snoop ...
/dev/audio (warning: can
OPTIONS
-a Listen to packets on
be noisy).
Tim Brown
You have frequency confused with amplitude - even an AC like myself knows that. for example
using only 0 and 1 i will now demonstrate a frequency of 2 "1's" per second given you are reading at a four number per second rate
010101010101010101
there ya go.
frequency is instances over time
amplitude is peak amount per instance
You've all seen a similar use. Listen to the approach of the lunar shuttle to the TMA-1 base in "2001: A Space Odyssey".
And fifteen years ago I was listening to network behavior: the RF leakage from a computer or network device can produces recognizable patterns on a radio. I identified excessive directory searches in an application from the background chatter. The higher speeds of current technology makes this more difficult with simple broadcast AM/FM radios.
I also believe that Slashdot discussed Peep, the Network Auralizer which plays sounds based on network activity. But Peep is oriented toward behavior of an entire network, not of specific connections.
man ping in FreeBSD-STABLE: