Re: [patch] increase tst-tls13.c timeout.

[cgd at broadcom dot com]

At Tue, 9 Sep 2003 19:45:56 +0000 (UTC), "Roland McGrath" wrote:
> tst-tls13 does 1000 dlopens and thus some goodly amount of filesystem access.
> But I don't think it should take vastly longer than many of the other tests.

Err, well, i just took a quick look at the other elf tests, and the
only other loop-heavy ones that i noticed were:

        * loadtest does 1000 or so dlopens and dlcoses (combined,
          around 500 of each).

        * tst-tls8 does about 40 each dlopens and dlcloses (on quick
          read of the source).

        * tst-tls6 and tst-tls7 each do about 10 dlopens and then for
          each a bunch of other assorted ops (incl. close).

        * resolvfail.c does 10000 dlsyms (all of the same symbol),

dlopen does a lot more than dlsym (given the fact that dlsym is just
compute on already-loaded objects), so the only one that's really
close in amount of work is loadtest.


so, anyway, to time them:

* loadtest run w/ cold cache seems to take fractionally over 2s, and
  drops to about 1.6s or so w/ warm cache.

* tst-tls13.sh takes about 4.4s w/ a cold cache, drops to around
  4-4.1s with a warm cache.

* resolvfail.c takes > .5s cold, > .2s warm.  (not really a surprise.)


So, loadtest seems close to a 2s limit, too.  However, it doesn't use
the test skeleton doesn't do its own timeout handling, so it *has* no
limit.  8-)

I don't know why the difference between loadtest and tst-tls13 isn't
just "2x", but i believe the number i've seen.  (and anyway, 2x would
still be well over 2s.)


Given the variations of CPUs running around here that I use for native
builds, i'd expect it the tst-tls13.c timing to range up to 6s or so,
normally.  A couple of seconds pad doesn't hurt, hence 8.


Anyway, if you don't think it's appropropriate, that's OK by me too.  8-)


chris