No, it's the limiting in slots allocated to HCC on GPU. Set the "Connect every..." (client 6) or "Minimum work buffer" (client 7) to 0.01 (the smallest value), and the frequency of work fetch requests is maximum, *before* a thread runs dry. Maybe that helps.

edit: response to Simplex0

Yes and no, it's not really liked, preferred a bunch of Ready to Report are send up combined with a single grouped work fetch, but it's better than idling client cores. There's work enough, but other sciences also need to get a chance to serve the volunteer computers. Work fetches serving is the prime directive I think ... no cap on the quantity of those :D.

The 0.01 frequency is not a "I'm allowed so I will". If the buffer [sum of work being computed plus work ready to start], is above the 0.01 value, there wont be an attempted fetch request. That said, someone reported to have walked into a 164 quota capping for a device. I calculate that a single GPU card must be running them faster than 8.9 minutes to reach that point in a day. With setting more threads per card [at your own risk], or multiple cards in a device, or a fast card that's well possible.

Yes, the limit of "In progress" is set to 10 for HCC per processor thread. Not informed if this is a CPU only restriction.

Are you using two AMD cards (or two Nvidia cards would produce the same result), and also use a cc_config.xml file to exclude one of them? Then the normal work buffer is not used, for some obscure reason.
http://boinc.berkeley.edu/dev/forum_thread.php?id=7796&nowrap=true#45350

We ran into this on POEM a short while ago.

A few background details:

Work is being sent out at a rate of about 9 per second.
HCC1 has 45 slots assigned to it in our shared memory (the buffer where the server checks for work to send to fill a client's request).
It therefore takes about 5 seconds to empty the shared memory slots for the project.

Over the weekend, our scripts did their work and filled a 1.5 day buffer for work ready to send for the project. That means that there are about 1.1 million jobs ready to send out in the database for the project. As a result, when it goes to fetch the next set of jobs to put into the shared memory it is taking a little too long to load (about 6 seconds at times). This means that the shared memory is periodically going empty. We have changed how much is cached down to 1 day and we are doing a few other things to fix this.

At the moment though this means that you will periodically get no work messages.