---
- branch: MAIN
  date: Sat Nov 25 07:58:47 UTC 2017
  files:
  - new: '1.32'
    old: '1.31'
    path: src/tests/net/ndp/t_ra.sh
    pathrev: src/tests/net/ndp/t_ra.sh@1.32
    type: modified
  id: 20171125T075847Z.1f4975ea94156ff1cd696b7c0ecb0a57fc65d4e3
  log: |
    Make this test somewhat deterministic - far fewer races, and most
    of what are left are "race for the bus" type - if we lose, we just
    wait for the next one ... slower but still reliable.

    There are two exceptions ... when starting more than one rtadvd
    (on different routers) we expect to receive an RA from each, but
    all that we can check is that we received the (at least) right number
    of RAs.  It is possible (though unlikely) that one router sent two
    before another sent any, in which case we will not have the data we
    expect, and a sub-test will fail.

    Second, there is no way to know for sure that we have waited long
    enough when we're waiting for data to expire - in systems with
    correctly working clocks that actually measure time, this should not
    be an issue, if data is due to expire in < 5 seconds, and we wait
    5 seconds, and the data is still there, then that indicates a
    failure, which should be detected.   Unfortunately with QEMU testing
    time just isn't that reliable.  But fortunately, it is generally the
    sleep which takes longer, while other timers run correctly, which is
    the way that makes us happy...

    While here lots of cleanups - everything from white space and
    line wrapping, to removing superfluous quotes and adding some
    (but probably not enough) that are not (though given the data is
    all known here, lack of quotes will rarely hurt.)

    Also take note of the fact that current rtadvd *cannot* delete its
    pidfile, so waiting for that file to be removed is doomed to failure.
    Do things in a way that works, rather than simply resorting to assassination.

    Because we do a lot less "sleep and hope it is long enough" and more
    "wait until it is observed to happen" the tests generally run in less
    elapsed time than before (20% less has been observed.)  But because we
    "wait until it is observed to happen" rather than just "sleep and hope
    it is long enough" sometimes things take longer (and when that happens,
    we no longer fail).  Up to 7% slower (overall) has been observed.
    (Observations on an amd64 DomU, no idea yet as to what QEMU might observe.)
  module: src
  subject: 'CVS commit: src/tests/net/ndp'
  unixtime: '1511596727'
  user: kre