timoOutLoopStartLab() checks if any transactions have been delayed
for so long that we are forced to perform some action (e.g. abort,
resend etc).

It is *MEANT* to (according to the comment):
> To avoid aborting both transactions in a deadlock detected by time-out
> we insert a random extra time-out of upto 630 ms by using the lowest
> six bits of the api connect reference.
> We spread it out from 0 to 630 ms if base time-out is larger than 3 sec,
> we spread it out from 0 to 70 ms if base time-out is smaller than 300 msec,
> and otherwise we spread it out 310 ms.

The comment (as all do) lies.

the API connect reference is not very random, producing incredibly
predictable "random" numbers. This could lead to both txns being
aborted instead of just one.

Before:
timeout value: 123 3
timeout value: 122 2
timeout value: 122 2
timeout value: 122 2
timeout value: 123 3

After:
timeout value: 127 7
timeout value: 126 6
timeout value: 129 9
timeout value: 139 19
timeout value: 137 17
timeout value: 151 31
timeout value: 130 10
timeout value: 132 12

Index: ndb-work/ndb/src/kernel/blocks/dbtc/DbtcMain.cpp
===================================================================


ndb/src/common/util/Makefile.am:
  BUG#30379 Better randomise time before retry in timeout check (DBTC)
ndb/include/util/ndb_rand.h:
  BUG#30379 Better randomise time before retry in timeout check (DBTC)
ndb/src/common/util/ndb_rand.c:
  BUG#30379 Better randomise time before retry in timeout check (DBTC)
ndb/src/kernel/blocks/dbtc/DbtcMain.cpp:
  BUG#30379 Better randomise time before retry in timeout check (DBTC)