Using Sound To Test Internet Connections 183
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."
Obligatory Monty Python Quote (Score:3, Funny)
Re:Obligatory Monty Python Quote (Score:2)
No, that only happens if they play "Dude Looks Like a Lady."
Heart Failure (Score:2)
Sorry, your dead !
Better still they could just stream internet radio (Score:3, Insightful)
I agree totally (Score:2)
If I had this is RTCW maybe I could adjust my aim better. Thats whats holding me back!
Sounds like Slashdot! (Score:5, Funny)
Doesn't that sound like Slashdot?
Well.. (Score:4, Interesting)
Re:Well.. (Score:1)
O.M.P.Q. (Score:5, Funny)
NURSE #1: Yes. Certainly, Doctor.
DOCTOR SPENSER: And, uh, get the machine that goes 'ping'.
This is Stupid (Score:3, Insightful)
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.
Re:This is Stupid (Score:5, Informative)
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..
Re:This is Stupid (Score:4, Interesting)
I heard that (Score:2, Informative)
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 [auralizer.com] which plays sounds based on network activity. But Peep is oriented toward behavior of an entire network, not of specific connections.
Re:This is Stupid (Score:2)
a working example (Score:3, Informative)
If you don't want to figure out how to insert a literal ^G, you can try this simple example:
Re:a working example (Score:1)
Re:a working example (Score:2)
Dude, get real.
A "echo Is this thing on?" is all you need.
Re:a working example (Score:2)
perl -pe expr is equivalent to:
perl -e 'while() { expr; print }'
In other words, the -p takes care of the while() print loop for you.
Just FYI,
Justin Dubs
Re:a working example (Score:2)
Re:This is Stupid (Score:3, Informative)
man ping in FreeBSD-STABLE:
Re:This is Stupid (Score:1, Insightful)
Please buy a dictionary and look up 'frequency'.
Re:This is Stupid (Score:1)
Re:This is Stupid (Score:2, Insightful)
A surgeon isn't going to want to have to look up every 5 seconds at some display while he's working if he can avoid it. Having a constant tone that will immediately change when network conditions change would be much easier since the surgeon can get the necessary information without breaking his focus on the job at hand. I think the article appears to feature people that are actually rather clueful.
Re:This is Stupid (Score:1, Informative)
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
Re:This is Stupid (Score:2)
Because sometimes looking at a numeric display means looking away from something important.
I think the idea is that using sound as an additional input means that the user is able to concentrate on using their eyes for things that need sight and can use their ears for something that does not (i.e. telling how good the connection is)
E.g. I'm controlling a robot that requires absolute concentration. Obviously, a change in the quality of the connection will require me to change what I'm doing with the robot (as its responsiveness changes) so I need to be aware of the connection quality. At the same time, I don't want to be switching between looking at what the robot is doing and a checking connection.
I don't think this is intended for normal computer users.
Good idea & novel approach (Score:3, Informative)
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
Rather more like 'interface' ? (Score:2, Insightful)
The most important point is the connection itself. The surgeon should know when it goes down, or when latency changes, whatever the means used (light, sound, hell, why not electric shock !).
I see that as a maybe fun way to see the trouble, but it won't solve it.
I'll of course assume the surgeon buys special bandwidth with certified low- or fixed- latency before doing the surgical act...
Re:Good idea & novel approach (Score:5, Interesting)
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.
An ongoing trend.... (Score:1)
I agree with the "they thought it was cool" blurb.
Re:An ongoing trend.... (Score:1)
Most of this seems to be geared towards increasing Situational Awareness [mit.edu] in the context of aircraft cockpits.
Re:An ongoing trend.... (Score:1)
Digital tuners that do the same thing are available at your local music store for about $50.
Another Dreary Post (Score:5, Funny)
"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!
Re:Another Dreary Post (Score:1)
ping? Really? (Score:1)
And they're just now discovering it? Did the reporter read a man page or something?
Re:ping? Really? (Score:1)
ie replies 'connection timed out' whatever the error is, so people don't check if the remote host is up or not using 'ping'...
(ok, free bashing on ie, sometimes you just hafta say what you got inside you !)
Re:ping? Really? (Score:3, Funny)
'Ping' is a duck. I learned this in first grade.
(But check out This Amazon review (scroll down) [amazon.com] by : John E. Fracisco. (No, the link doesn't give me referer bonuses or whatever.))
Re:ping? Really? (Score:1)
Woah! Don't jump to such radical conclusions! It takes years of using a UNIX like OS to be able to consult man pages.
eureka (Score:4, Funny)
I wonder... (Score:2, Funny)
I'm guessing it's just going to sound like people laughing at you.
Is testing enough for life-critical operations? (Score:3, Insightful)
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.
Re:Is testing enough for life-critical operations? (Score:1)
Lag change, noticed or not, can be just the bad thing that kills your patient.... even on a simple operation !
That's why indeed there's the need for guaranteed (and maybe more important constant) lag time...
Re:Is testing enough for life-critical operations? (Score:2)
What happens when some surgeon begins surgery, and some router in the middle of the link has to deal with the /. effect? Or worse, someone else launches a DOS attack?
I want my telesurgery done over QOS links, with guaranteed bandwidth.
Re:Is testing enough for life-critical operations? (Score:2)
Re:Is testing enough for life-critical operations? (Score:2)
I was thinking the same thing. Imagine some city workers digging somewhere along the line and hitting your fiber with something like excavator. How's any testing that will be done before operation going to provide any safety against something like that? Does it help if this system can for sure tell that "connection is lost" during the critical operation?
First thing to do is to prevent mechanical failure, but I don't see a way to do that. All you can do is to have multiple backups. Like in addition to that fiber connection, you need enough bandwith on some low latency radio system for the full length of communication line or something. And that can provide only one level of redundancy.
Doctors could do a lot of things.... (Score:2, Insightful)
Sure, there could be a doctor holding two fingers on the jugular of a patient, but that requires another person, and sure they could have a machine that did it for them without sound, but that would require people to be watching it.
Having an audible signal for when something goes wrong makes multitasking easier, and therefore, this could be beneficial.
Re:Doctors could do a lot of things.... (Score:1)
The ear is very sensitive... (Score:5, Interesting)
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?)
Re:The ear is very sensitive... (Score:3, Insightful)
You can that! I had to debug some modem problems a while back, and it got to the point that I could not only tell whether it was going to connnect or not, but at what speed, just by listening to the entrain sequences. Bearing in mind that V.90 only has a limited set of frequencies it can connect at, I was either getting the right value or one of the adjacent ones *every time*.
Yeah, I know: Sad! ;)
Re:The ear is very sensitive... (Score:2)
And the penalty for reverse engineering it is death (for one person atleast)
The other way round, surely? (Score:2)
Given that the latency of a ping is no guarantee of the connection speed in 5 minutes time, regardless of whether you use your screen or your ears, isn't this the other way around? Taking a method as good as any other and writing a clever bit of software to use the clever bit of software in your brain to get much the same results as a simple ping?
And what about a quick glance at a latency graph on the pc's monitor? If I was undergoing remote surgery, I'd much rather rely on a nice smooth graph of low ping latency over the past 2 hours than the questionable skills of a tech listening to the pings for a few minutes...
Re:The ear is very sensitive... (Score:5, Interesting)
Two additional thoughts/perspectives on this (from a symphony french horn player now broadband guy):
- sound, in learning theory, is very powerful and when combined with other learning mediums (e.g. visual or conceptual) can be a good reinforcer.
Incidentally, if you ever wish to learn morse code, some of the most effective ways to learn it well and quickly are to learn it as sound - not patterns - because of how the brain processes things faster there.
People that try to think of code as "dah - dit - dah" - long/short/long - are crippling themselves and engineering future speed problems. I've actually seen people draw out lines and dots when hearing code, then going back to visually review it all and convert to letters. Audiatory --> Visual --> Conceptual. Ugh!
Instead, by learning it as a language based on sound - they'll be able to reach 30 wpm and greater because of how our brains are designed for optimized processing of language/sound. They'll begin hearing letters without even thinking of dahs and dits, or dashes and periods.
- sound for network testing: Using sound isn't that crazy. We already use Winamp and a 160 Kb shoutcast stream for lots of testing - you can be working on a circuit and immediately recognize you've got a problem when the audio drops, and the loading is nice when you're dealing with broadband residential service. Sure, there are special software tools for this, but none as pleasant to work with as a shoutcast of digitalgunfire.com
*scoove*
Re:The ear is very sensitive... (Score:2)
Re:The ear is very sensitive... (Score:2)
But if your program entered a loop, the loudspeaker started emitting a very high pitched and steady tone. You could tell other things by listening too - depending on whether the whole "kernel" was looping or not, you might hear individual interrupt handlers breaking in. It was actually a pretty cool tool and I have often considered how difficult it would be to build a UI (not that there was any such thing as a UI in those days) that gave the equivalent information.
CPUs are now way too fast of course and do too many things at once to make this approach any use. But I think it could be a very useful way to very quickly get a good estimation of the quality of a network connection.
Whether you'd want to start open heart surgery based on that estimate is another matter of course.
Re:The ear is very sensitive... (Score:2)
Re:The ear is very sensitive... (Score:2)
Newbie to google (Score:1)
technology in use (Score:1)
It looks ridiculous said like this, but imagine the uses in emergency situations - you have to setup a connection using whatever network you can find, and the bandwidth usage changes constantly. So by listening to the "sound", you can take action at the right time without worrying about lag.
A suitably clever piece of software (Score:1)
Of course, you can always do it using a suitably clever piece of software that "converts the frequencies of a 'ping' to sound", what were they thinking?
ping - packet internet groper (Score:2)
Re:ping - packet internet groper (Score:1)
Just a thought.
Why do I get the mental image.... (Score:1)
Connery: "One Ping Mr. Reilly"
Reilly: "But Sir!"
Connery: "I said one ping!"
Perfect example of bullshit (Score:3, Informative)
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.
Re:Perfect example of bullshit (Score:2, Informative)
Regardless of how well you design your network, it is possible for it to go down or experience brief glitches, as you yourself pointed out. If the network does go down and you are in the middle of a delicate procedure, it is essential the surgeon knows about it as quickly as possible, and not just from an image freezing or something. Imagine what can go wrong during 0.5 of a second in which a surgeon has hold of some delicate piece of tissue and thinks the reason it isn't moving is because he isn't applying enough pressure, when in fact the image has momentarily frozen because of a brief network glitch. Having a pet geek monitoring the network and yelling if something goes wrong isn't good enough to deal with such short-term matters.
The point is it sounds like a good idea for the surgeon to know how the network is responding RIGHT NOW!! It's not a question of whether the network has gone down, but whether the image on the screen is an accurate representation of what is going on at this precise instant
I'm not talking from any knowledge telesurgery, but I can't think of any faster way for a surgeon to be alerted of network problems. The pings could be sent out constantly at a high rate (without even waiting for each to come back before sending the next), and their results converted to a sound which the surgeons hears continuously. If there was a sudden drop in responsiveness or if the connection is lost, the surgeon may even know quickly enough to respond instinctively.
Sometimes very simple ideas turn out to be highly effective and lasting. Think about the dead man's handle on trains, for example. And sometimes the more complicated ones cost lives, like the Airbus computers. (and yes I know the Airbus problems were technically pilot error, but the point still stands - it's good for the person in control of a potentially dangerous situation to get accurate feedback in the simplest and most robust way possible)
>> 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
Nonsense! If for some reason, during an operation the network goes down, what the surgeon needs to know, and know bloody quickly, is THAT it has gone down, so he can do whatever he has been trained to do to minimise the danger of the situation. As to WHY it went down, there's plenty of time for thinking about that once the patient is safe
Ah ok. (Score:2)
When I first read the headlines I imagined that weenie from the teleco ads using VoIP to ask "Can you hear me now?"
Quake Shows Internet Connection Quality (Score:5, Funny)
"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."
Old idea, new application (Score:3, Informative)
Re:Old idea, new application (Score:2)
A cool, simple idea (Score:3, Insightful)
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.
This isn't far fetched... (Score:2)
webserver monitoring (Score:5, Funny)
ping........ping........ping....[slashdot story posted]....ping..ping...ping.ping..ping..ping.pin
ping.pingpingpingpingpingpingpingpingpingpingp
pipipipipipipipiipiipipipipipiiiiiiiiiiiiiii
Re:webserver monitoring (Score:2)
what's with all the negative comments? (Score:2, Informative)
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)
Re:what's with all the negative comments? (Score:1)
You're missing the point! (Score:2)
I'd be bloody terrified if the surgeon started to cut into a vital organ, a DOS attack slowed the network down suddenly, and he had to hold his scalpel in precisely the same position for 5 mins while the connection stabilised. A gimmicky audio program wouldn't help with that, because by the time you could hear the problem, it'd be too late!
Re:what's with all the negative comments? (Score:3, Interesting)
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.
Re:what's with all the negative comments? (Score:2)
PING studorgs (127.0.0.1) from 127.0.0.1 : 56(84) bytes of data.
64 bytes from studorgs (127.0.0.1): icmp_seq=0 ttl=64 time=44 usec
64 bytes from studorgs (127.0.0.1): icmp_seq=1 ttl=64 time=45 usec
64 bytes from studorgs (127.0.0.1): icmp_seq=2 ttl=64 time=46 usec
64 bytes from studorgs (127.0.0.1): icmp_seq=3 ttl=64 time=46 usec
Interesting idea but it's been out for years (Score:2)
Why do they make simple things complicated?
Icecast: http://www.icecast.org
ShoutCast: http://www.shoutcast.com
SimpleServer Shout: http://www.analogx.com
If you don't like sensationalism... (Score:1)
similar projects (Score:1)
one of them is a kind of plugin for apache:
digital emotions [formwerks.de]
They need some good samples.. (Score:1)
Ping Ping, n. Probably of imitative origin.
The sound made by a bullet in striking a solid object or in passing through the air.
1913 Webster
They'd feel themselves real field surgeons then.
Reminds me of the iron foundry (Score:3, Interesting)
This idea of using sound to check connections may be less absurd than it sounds
Old idea (Score:2, Informative)
OPTIONS
-a Listen to packets on
be noisy).
Imagine.. (Score:1)
Peep - the network auralizer (Score:2)
Actually there is a sourceforge [sf.net] project that you can hear the network traffic as the sound of rain or a forest, the more traffic generated the busier the forest sounds or the harder the rain falls
i have run this and i have to say it beats listening to the sound of a server rooms fans
you can see/download the project here [auralizer.com]
missed the point (Score:1, Interesting)
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.
pinging nightmares (Score:2)
3am: Story posted on slashdot.. many slashdotters just gone to bead: ping blip blip pant pant blip pant
7am: Story extremely popular : Ping pant pant huff *scream* *ouch* *fry* *sizzle* *fzzzzzt*.......... ping timeout
No offense... (Score:2)
The problem I see is this (Score:2)
"Network sounds a bit slow today."
"Nah, sounds OK to me. Hey Joe, what d'you think?"
"Dunno, sounds bubbly."
ONCE AGAIN (Score:2)
I do that already (Score:3, Funny)
This is dumb (Score:2)
Jeff
Can you hear me now? (Score:2)
In my head... (Score:3, Funny)
A company that has the clever software (Score:2, Interesting)
I think everyone missed the point here... (Score:2)
While "neat", this doesn't seem particularly radical, or even hard to implement. I could probably come up with a crude working version within an hour.
I don't, however, put much stock in the claims about making telesurgery safer. The information obtained by this only gives a more fine-grained, modally-unusual form of information about the link's *current* state. It has no long-term predictive power whatsoever.
I didn't quite get the comments about modelling the network as a drum rather than a guitar string - I understand the need for a multidimensional representation, but to monitor even a small subnet you get into numbers of dimensions humans have no familiar analaog to (and thus, cannot extract meaningful information from). Unless they meant that one could plot the "to" times on one axis and the "from" times on the other, and model *that* as a 2D surface such as a drum. That would work, I guess, but would make it harder to understand the output.
How freaky, that's just what I did! (Score:3, Interesting)
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
Old principles and new misunderstandings (Score:2, Insightful)
I can remember it that clearly for two reasons:
That's right, whatever wise man said "Never whistle while you're pissing" (I remember it first in connection with Robert Anton Wilson, but I could be wrong) had no idea this day was coming. (And if you ever hear the Star Spangled Banner playing in the washroom, try not to salute!)
Numbers on a terminal window don't have much meaning unless put in perspective, or the perspective is known very well to begin with. Music is a "given" perspective that most people know already. They may not be able to play a note, but they know what sounds right and what doesn't. This method is a good way to convert numeric data into something more immediately recognizeable.
Now, the bad news: The connection between doctor and patient in a telesurgery operation must be both low latency and low jitter. When either one isn't there, the participants have good reason to panic. And all that auditory monitoring of ping times and jitter will do is enable that panic to set in that much more quickly. Can you say "liability," boys and girls?
I just don't consider the modern Internet to be sufficiently reliable for any application, and I expect its quality will continue to degrade as time goes by, more people get on, ISPs save money by not upgrading their equipment to handle the new press of people, and certain forces work to pollute the net with carnality, banality, and commercialism.
If your connection drops in the middle of surgery (Score:2)
ping -a (Audible ping) (Score:2)
iputils-20020124-8 from Red Hat 8.0 has an "-a" switch, that makes the ping audible.
It makes a "bell" sound for every packet. Combining -a and -f (flood ping) doesn't work though.
I wouldn't rely on ping too much, though, audible or not; recently one of our servers suddenly lost its root-device. Amazingly the kernel limped on and replyed to pings. Our network monitoring program (www.nagios.org) therefore claimed the host was up, but all services had stopped answering.
Re:it is clear (Score:2)