Ring a "bell" in case of packet loss?

[hildeb]

We usually keep mtr running on a laptop somwhere, not looking at it. Now, in case of packet loss, it would be cool if some sound could be played -- and as far as I know most terminal offer a "bell" kind of thing (\a?) It would be cool if there was the option to have a bell for e.g. packetloss.

[rewolff]

This is a feature request I don't have time for right now.

The problem is that packets aren't ever lost. The return packets just aven't arrived yet.... When can you decide a packet has defintively been lost?

Of course we could consider say 5, 10 or 30 seconds as "lost".

I think this should be implemented as a "trigger": You specify a condition (e.g. packet loss > 2% over 100 packets) and when the condition triggers, you specify "something to do". I think that should always be "execute some program" . What YOU want to do is specify "play BELL".

I have a friend who has a switch that is unreliable. A powercycle solves it. So he'd specify something like "packetloss > 50% over 60 seconds" as the condition and a script to powercylce the switch as the "what to do".

[yvs2014]

The return packets just aven't arrived yet.... When can you decide a packet has defintively been lost? Of course we could consider say 5, 10 or 30 seconds as "lost".

There's an idea, an alarm can be trigerred after '-i' interval. For example, if we have '-1 (no response)' in host[].saved[last - 2], then a bell is played. Switches on/off of bells related stuff can be put into -d display mode integer. I've tried to code something like that in https://github.com/yvs2014/mtr/commit/b5eb77f2dc3896420d29abc658ebb632472d8d17 commit with audible/visible bells. Looks like it works.

[rewolff]

Looks like a start.

I much prefer that you just always call the "seal" function. The check for if (audible_bell) then happens there: if (!audible_bell && !visible_bell) return;

Makes the patch shorter. I like shorter. :-)

And then adding my proposal: "Allow for a program to be executed", is easy and localized to implement.

[yvs2014]

always call the "seal" function.

Assuming that bell functionality will be used very rarely, the cost of function call is too excessive in relation to resources. Kinda "if (a) call b()" vs "b() { if (!a) return;.. }; always call b();" Anyway it's just a detail.

[rewolff]

Yes. I understand that. But for readability shorter is better. And the "cost" of software is mostly "developer time". So shorter is better. Less time needed to read the code.

For a machine running TCPIP a few function calls should be within the possibilities... :-)