1) Messages were almost always delayed event if it was not necessary.
The reason was that the budget was replenished only at the
multiples of period since the VRES thread started. Even if no
message was sent for several periods, the budget was not
replenished immediately when a new message arrived, but the code
wait for the next period.
2) It was possible to send more bytes then the VRES should allow. If
the message was too large, the code just wait for the new replenish
and then sent the message. At the next replenish instant, the
budget was fully replenished again another oversized message could
be sent again.
The new algorithm should solve all the above points.