With the upcoming completed feature request of being able to beep the system speaker in unRAID its time to discuss the codes themselves.

 

There have been a few debates before but nothing of any real substance; most devolved into talk about missing packages./request for the feature. This thread is dedicated right from the OP on the codes themselves and nothing else.

 

The way I see it we initially need to decide on:

 

Type of beeps to choose from (i.e. short and long only? etc)

The events we would like to assign beep codes to. (i.e. failed disk, dinner is ready etc)

The array of codes to use once we have decided the types of beeps to use. (i.e. a pool of codes that can be drawn down upon when adding new events)

 

Now there will likely be a number factors that will still get in our way until the API is in place but theres no reason we cannot design the beep code scheme in advance.

 

One thing that I think is important is that we decide the scheme as a group and then stick to... that is to say if someone hears "short long short" and finds a reference to that in the forum or wiki it should only have one meaning and not different meanings as time passes or in different implementations.

 

Obviously we will probably have some heated debates about this but thats half the fun.

 

Once we start getting somewhere I will attempt to track the conclusion in the wiki.

Although it might seem useful to you to have different coded beeps, in practice, that is only a substitute method of conveying data when no other is available.   

 

As an example, a periodic "beep-beep-beep" pause... "beep-beep-beep" pause... is perfectly fine for getting your attention.  You then know to look at the web-management page or system console for the specific error or alert details.

 

Many of us share our servers usage with family members, and it might be them who first hear the "beep" alert when you are not at home.  Unless you have a very sharp family member, and a "beep" cheat-sheet handy, a coded set of beeps is not going to help much when they call you at work and say your computer is beeping... unless the scheme is *very* simple.   Unless you have a way to easily silence the beeps, they might get so annoyed at the sound they unplug the darned thing to maintain silence.

 

One beep every hour ... (very minor attention needed  - cooling fan bearings need oil-change to maintain warranty )

three beeps every minute ... (disk failure )

Zero beeps every minute ... (CPU/motherboard/power-supply/memory/speaker failure OR everything working perfectly fine  )

 

In my opinion, the number of beeps in a series is FAR easier for a non-technical user to identify and relate to you when you are not there in person than any combination of long and short beeps.   

 

There is NO substitute for a syslog, or a look at the system console for actual error details.  The "beep" is only to get your attention...

 

We can learn a lot from the POST code "beeps" used by a motherboard BIOS.  These are intended to be interpreted (for meaning) by experienced technical people when the primary interface (the system console) is not available, even then, today, many BIOS try to keep it simple. (re-seat cards, replace memory.)   Very few try to get any more detailed than that because there is little else you can do besides those few things.

 

For most users... it is either beeping, or not.  For details on how to proceed, you get a message on the screen.

 

I propose keeping it simple... very simple... no beeps when things are working... a set of three or four beeps at some reasonable interval when the array needs attention of ANY kind.

 

Joe L.

You make a good point. I cant see people memorizing lots of different beep codes however that doesn't mean there should be a suite of codes. Let me explain...

 

If you consider your point that users will hear beeps and think "oh somethings up" then its doesn't make a difference in that scenario if there are 30 different beep codes. In essence a beep is a beep.

 

However if a user has a recurring/transient problem or a need to montor for a specific scenario (such as parity complete) then having a code they learn to know as that specific problem adds value. So what I am saying is that a small subset of codes might actually be recognizable by single users based on their particular system and requirement. At the same time general users will hears "beeps" and investigate.

 

Best of both approaches

Obviously we will probably have some heated debates about this but thats half the fun.

 

Oh Baby I am hot about this hack !!!!  

 

 

Back in the days of norton dos tools I had musical tones play for events.

A beep that escalated upwards was when the system came up.

one that escalated downwards is for a crash of some sort.

I had various high low tones rather then long short pulses.

There were all sorts of tones and songs that would pierce through the air conditioned computer room. LOL.

 

What events are suggested.

It's quite possible to create a configuration file for event vs beep and allow people to choose what they want to monitor or be alerted of.

 

 

I was thinking a LEVEL type model for defaults to cover this. Stuff we have all seen before like WARNING events, DEBUG events etc.

 

Events could be categorized by level and when implemented a user could choose the level they wish and add exceptions and additions by either editing an ini or ticking some boxes.

 

One point Joe brought up that I hadn't considered is frequency of alerts. Some alerts will be one off's whilst others might be one of but need ongoing alerting until remedial action is taken (e.g. a disk has failed. It fails only once but you dont want only one alert).

 

This could quickly get into a bigger project but the lions share of it isnt really all that complicated... its the monitoring and recurring alert system that is the only really tricky part.

As of Linux 2.6.26 the driver for the PC speaker has been enhanced to be able to play almost any sound, at least for many chipsets.

 

Check out the  "PC-Speaker PCM driver" 

What events are suggested.

It's quite possible to create a configuration file for event vs beep and allow people to choose what they want to monitor or be alerted of.

 

 

 

I was thinking the same thing.  Perhaps this could all eventually be controlled from the unRAID Web interface eventually by checking a box next to a beep code you want to use.