Whether it is CBWFQ or WFQ, the sheduling is based on the weight value , the sheduler prefer lowest weight and it takes the packet with lowest weight from software queue and move in to hardware queue
Let say we have CBWFQ configured on interface and fair queue configured under class-default the sheduler will takes the the packet with lowest weight from the queue
2^n + 7 wieht = 1024 this is for link quue for traffic like routing
2^n + 8 weight = 0 This is for Priority queue
>2^n + 8 weight = const*interface BW/class-map Bandwidth User defined class maps
2^n weight = 32384/(IPP +1) this is WFQ and all the queues are dynamically assign
So the strange thing i observed is if we configured user-defined class with bandwidth 3% and remaing allocated to the class default with fair queue
* user-defined class is still allocated with more bandwidth then the class-default with fair queue
to summarise on my understanding
To summarize what we learned so far:
1) CBWFQ is nothing else than WFQ on steroids 
2) User-defined classes have much better scheduling weights than any dynamic flow queue. Therefore, the bandwidth allocated to dynamic queue usually is small compared to any user-defined class.
3) Scheduler shares interface bandwidth in relative proportions. For example, if you have two classes configured with bandwidth values of “32” and “64” and interface bandwidth 128 that does not mean system will allocate classes 32Kbps and 64Kbps. That means: in case on congestion CBWFQ will share bandwidth in proportions 32:64=1:2 between the two classes, plus some small amount to class-default. If you want bandwidth to be “realistic”, ensure your entire bandwidth values sum to interface bandwidth. The same goes to bandwidth percents. 4) If you want the scheduler to honor class-default traffic, assign it an explicit bandwidth value. This will effectively disable dynamic flow queues (though preserve Link Queues) and assign all unclassified traffic to a single FIFO queue.
Info taken from
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Is there a question in your last post?
Unclear, to me, how your follow-up posting relates to my posting.
It's true both CBWFQ and WFQ use weights in their dequeuing; that's the reason for "W" in both acronyms.
". . . the sheduler prefer lowest weight and it takes the packet with lowest weight from software queue and move in to hardware queue", no it doesn't. It uses the weight to try to provide a proportional share of bandwidth relative to other active queues. I.e. another queue's packet with a higher weight might be dequeued next.
NB: BTW, the weighing differs in the particular vintage of WFQ.
The blog reference is very good, but not current as it describing CBWFQ pre-HQF or CBWFQ not found on 7500 VIP or FlexWAN line cards.
"CBWFQ is nothing else than WFQ on steroids " Rather simplistic statement. Comparison is more like an ordinary man vs. the comic book Superman especially when you look at HQF CBWFQ or 7500 VIP CBWFQ.
