Well, I have learned something very interesting.  There are actually TWO! virtual timers running for each monster.  They only use one physical timer entry but there are two things going on at once.  Generally, there is a type 32 timer and a type 37 timer.  When the physical timer is queued its type is set to the type of timer that will expire earlier and Byte 8 of the timer is set to the length of time until the other timer type will expire, so that when the timer is processed it can know, again, which type of physical timer should be queued.  The two virtual timers can have periods that are unrelated to each other, thereby causing rather complex behaviour.  I have no idea why the designers chose this (rather complex) method of keeping two timers going at once unless it was to save memory; the second timer costing only one byte (that was probably unused otherwise).  At any rate, this solves a longstanding puzzle...."what on earth is that Byte 8 business?".  And it makes talking about the two kinds of timers easier because they operate more-or-less independently of each other.

The type 32 timer appears to cause the monster to look about for the party.  If the party is nowhere near then it will look again in a time specified by BITS 4-7 of word14 of the Monster Descriptor.  Nothing random.  Tick-tock-tick-tock like a clock.  Since this is a 4-bit field, the longest time between type 32 timers will be 15 sixths of a second or about 2-1/2 seconds.  Diagram  If the monster does see the party......well, that is a story for another day.  Right now we are discussing the easier problem of monsters far from the party.

The type 37 timers ????????