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."

6 of 183 comments (clear)

  1. Good idea & novel approach by cpct0 · · Score: 3, Informative

    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.

    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". ... and it's hoping the usage of the different nodes are constant and have enough bandwidth to support the steam in the first place.

    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

  2. Re:This is Stupid by Chexum · · Score: 5, Informative
    there is no frequency beside on and off.

    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
  3. a working example by rillian · · Score: 3, Informative

    If you don't want to figure out how to insert a literal ^G, you can try this simple example:

    ping localhost | perl -e 'while (<>) { print "\007" if /ttl/; print }'
  4. Perfect example of bullshit by the+bluebrain · · Score: 3, Informative

    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
  5. Old idea, new application by bigboard · · Score: 3, Informative

    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.
  6. Re:This is Stupid by Permission+Denied · · Score: 3, Informative
    ping 192.168.60.254|sed 's/ttl/ttl^G/g'

    man ping in FreeBSD-STABLE:

    -A Audible. Output a bell (ASCII 0x07) character when no packet is
    received before the next packet is transmitted. To cater for
    round-trip times that are longer than the interval between trans-
    missions, further missing packets cause a bell only if the maxi-
    mum number of unreceived packets has increased.

    -a Audible. Include a bell (ASCII 0x07) character in the output
    when any packet is received. This option is ignored if other
    format options are present.