Of course if there is some substantial processing needed to get the proper answer the delay could be based on that... But sometimes it is not. The OP has 120 slaves (which is a lot) and presumably wants to make a quick poll cycle. If the request and answer for a simple poll ("Do you have something new?" - "No, thanks." :-) consists of only a few characters, it is not too reasonable to wait for another 6-10 characters per request-answer, if the hardware permits it. Also, if hardware permits, it is not reasonable to base the delay on character time - although it is simple to implement it so (simply transmitting dummy bytes for the time being).

My only point in that reponse was, that if the turnaround time should be shortened as much as possible and CRC calculation turns out to be too lengthy, the trick might be to calculate CRC on the fly during reception (and transmission), rather than calculate both the received (for check) and to-be-transmitted packet CRC at once between the reception and transmission.
An another trick how to win some little time might be to start transmitting "blindly" - the packeting protocols tend to have headers often with fixed first few bytes, so one could quite safely start to transmit them even while the answer itself is under process.

Jan Waclawek