Ian, I really do appreciate your effort and your input has been helpful, but do you not agree that such a bug needs to be tackled at the root? Please see below. | > [CCID 3]: Fix packet tardiness BUG | > | > Problem: | > -------- | > Due to packet scheduling in CCID 3, it can happen that the | > actual send time of a packet is later than t_now: in this case | > t_nom < t_now. | > This case brings the entire packet scheduling out of sync, since | > the next packet is scheduled at t_nom + t_ipi, and t_nom is in | > the past. | > | > Fix: | > ---- | > Update t_nom to t_now whenever a packet is late due to scheduling | > (and then t_nom < t_now). This update takes place in ccid3_hc_tx_ | > send_packet. In between calls to this function, it is irrelevant | > if t_nom < t_now (since it will be caught eventually). | > | Agree with the problem statement and your fix helps but I think this | fix isn't quite right and mine uses a bit too much CPU resource. | | The problem with yours is that it resets t_nom whenever it is late | rather than just due to t_ipi changing. Sorry, did you read the earlier emails that I sent? The point is that t_ipi will never cause t_nom to become negative. Let things be what they may - one thing is clear: the problem of being too late in scheduling must be accounted for. This is what the patch does. There is a second issue which is more subtle: there are several functions which access t_nom asynchronously: packet_sent, packet_recv, no_feedback timer. Due to concurrency this means that we have a race condition if we allow several functions to access t_nom without enforcing mutual exclusion via locks: the problem is that one function can read an old t_nom, while t_ipi has just been subtracted .... and so on. I have prepared another patch to take care of this. | The problem like this is that if the packet is late for other reasons | then we shouldn't slow down following packets as it hurts performance. Ian, which `other reasons' do you mean?: it is logically impossible to create a t_nom < t_now other than being too late in scheduling. Gerrit - To unsubscribe from this list: send the line "unsubscribe dccp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
