There are several reasons that you could see this kind of delay.
First, your application must have a thread in the RECEIVE block state when the pulse arrives, if not then it is your own
 application's thread states contributing to the delay.
The pulse itself carries a priority, currently set to your calling thread's priority in your code.  If there are several
 messages and pulses waiting on the channel in your application, the order of receipt is in priority order and then 
longest waiting.
If there are other threads in your system running at a higher priority or ahead of your thread in the priority queue, 
then you will see a scheduling delay.  Make you pulse a higher priority than other lesser priority tasks in your system.

If you have handlers (ISR) running in your system, they are always running at a higher priority than any thread in your 
system.
Last, we check for timer expiry on every timer tick, so at the very least you should expect at the very least a possible
 delay of a timer tick (default 1 ms).  If any thread is turning off interrupts in your systems, then we will not get to
 check for expired timers until we take the timer interrupt again.  Turning off interrupts in a real time systems should
 be for as short a time as possible and as last resort.

A good section to read in our documentation on timers and timer irresolution is: Clocks, Timers, and Getting a Kick 
Every So Often

Hope this helps.