mtr has a number of problems when used for long-term connection
monitoring.

Concept: I'd like to keep track of the quality of a connection
using mtr --raw --interval 35

Problems:

[1] This busy waits doing select() if stdin is /dev/null.
[important]

[2] it's my belief (I've not done enough tests on this to be sure)
that raw.c should have fflush(stdout) after the printf() lines in each
of the two routines that use printf.  Otherwise, information isn't sent
to file in a timely fashion.

[3] --count seems like it would usefully work with --raw [to have mtr
only run for some specific time.] [wishlist]

[4] it would be Really Nice if mtr would have an option to timestamp
its lines with --raw (so I could tell what time a problem happened).
[wishlist]  A machine readable timestamp format would be ideal here

(I'm using tai64n from cr.yp.to/daemontools/damemontools-0.70.tar.gz at
the moment, with the tai64nlocal filter to display -- the libtai library
is public domain, but daemontools is not free software as far as i know).

Thanks,

severity 77638 wishlist
thanks

Not only that but it'll waste a perhaps-not-insignificant amount of your
bandwidth.

If *I* was doing this, I wouldn't use mtr at all. I'd use something like:

echo -n $(date):\  >> logfile
fping -C 1 -q [hostname] 2>/dev/null >> logfile
if [ "$?" = "1" ]; then
	traceroute [hostname] >> logfile
fi

If you want the traceroute triggered when the link is down *or slow*, use
fping's -t[milliseconds] option.

Hello, another bug report you should be aware of...

The way I'm using it (mtr --interval 35), the amount of bandwidth being
used is indeed insignificant.  We're talking maybe a thousand round-trip
packets an hour.

Those packets are something like 78 bytes outgoing and 64 bytes incoming.

So, we're talking about maybe 173 bits per second outgoing and
142 bits per second incoming.  This is significantly less than 1%
of the pipe.  [It's a high-speed wan connection I'm monitoring, not
a modem connection.]

traceroute uses udp, which I've decided is unacceptable in this
context.  [Would require reconfiguring too many things.]

Slow is indeed an issue, but I also want to measure the line quality
and *topology* when line quality is good.

Also, traceroute is significantly less systematic (in terms of packet
timing) than mtr.

I understand that parts of my bug report are wishlist severity -- however,
the busywaits if stdin is /dev/null is important, I think.  First off, it
makes mtr almost useless from under cron.  Secondly, it indicates a design
flaw (admittedly, perhaps a kernel design flaw or a posix design flaw)
that (in principle, at least) could show up under other circumstances).

Heh.. but at least it's not a red hat.  Eh? :)