The bandwidth stat explains typically how fast it could read the source shape to start processing. In this case how fast it fetched the records from the SMS tables to start processing.
The processing rate stat explains the "End To End" time taken for 1 record to complete. From fetch time to delivery time to the actual SMSC server (in sync mode this would also include the wait for the ACK SMPP packet that got back from the SMSC)
In delivery channels like SMS these rate could differ highly depending upon the lag time between Pega server and the SMSC server in the network side. If the individual data flow shapes are doing more of in-memory processing, these rates will be very close.
Btw, can you clarify what to do you mean by you are using data flows to send SMS in your project ? Are you referring to the OOTB implementation in Pega Marketing 7.4 onwards or you have a custom implementation ? Also make sure not to take over any of these shipped data flows as you would run into upgrade issue in the future.
I have one observation in respect to the above mentioned understanding of bandwidth and processing rate difference.
When we tested for scenario where SMSes are failed to be delivered (i.e the very 1 st fragment out of the 5 we have fails to be delivered) there we are experiencing this huge difference in bandwidth and processing rate e.g bandwidth 1800 rec/sec but processing aret 250 rec/sec.
However in case of success scenario when all five fragments are sent successfully there the bandwidth and processing rate are close e.g 71 rec/sec and 69 rec/sec respectively.
So question is if bandwidth is how fast source shape can read, then it should be independent of SMS success and failure scenario?
Yes, we are trying to provide a custom solution in PM 7.22 to give the multinode feature similar to 7.4 or higher, for that we are using a DF. This is to save the upgrade cost, client isn't very anxious to do another upgrade.
For sending the SMS we have created a new DF, however to populate the addition partition column in pr_data_corr_sms we have to override the OOTB DF_Writetostaging DF.
We already highlighted the risk involved in providing custom solution w.r.t to future upgrade.