[00:40:12] --- Jeffrey Altman has left: Replaced by new connection [00:40:12] --- Jeffrey Altman has become available [04:42:28] --- pod has become available [07:13:37] --- deason has become available [07:17:25] --- jaltman has left: Disconnected [07:17:31] --- jaltman has become available [07:19:04] --- jaltman has left: Replaced by new connection [07:19:05] --- jaltman has become available [09:11:39] --- Russ has become available [09:21:25] --- jaltman has left: Disconnected [09:22:02] --- jaltman has become available [09:32:46] --- Simon Wilkinson has become available [09:47:57] --- deason has left [09:48:03] --- deason has become available [10:25:06] --- deason has left [10:25:32] --- deason has become available [14:37:11] possibly dumb question about gerrit 580/969 from awhile ago (rx RTT stuff): [14:37:41] I don't think I understand the removal of the serial checks; doesn't that compute rtt for all packets in the tx queue, regardless of what was ACKed? [14:38:11] (unless the packet was retransmitted or already acked, of course) [15:15:25] --- mdionne has become available [15:29:55] --- deason has left [15:47:42] --- mdionne has left [15:58:59] we want to compute the rtt for all packets that have been sent once and that are newly ack'd. [15:59:45] regardless of whether the packet was ack'd via a hard ack or a soft ack [16:43:26] --- phalenor has left [16:52:49] --- phalenor has become available [16:54:00] --- deason has become available [16:56:01] what if it's not acked? either RX_ACK_TYPE_NACK or if 'tp->header.seq > first + nAcks' ? [17:25:42] if it isn't ack'd it should be ignored. [17:42:48] even a nack provides us an upper bound on the rtt [17:51:10] That code makes my brain hurt. But, yeah, I think if we have neither a payload ACK, nor a NACK for a packet we shouldn't be including it in RTT calculations even though it's in the transmit queue. [17:51:56] There's also the argument that the timings for packets that are ack'd by a window size move are different than those which are ack'd in the payload. Window size move timings include the time taken by the application layer to read the data. [17:57:10] We need to measure both types because the vast majority of rpcs from the client (minus store data) will never exceed a window size. [17:57:42] and the window size moves while they take longer still set an upper bound for the retry time [18:35:07] > if 'tp->header.seq > first + nAcks' actually, while a nack seems fine (you got an explicit notification tied to something, which gives you an rtt) i'm not sure why this case should be measured. [20:11:06] --- abo has left [20:12:29] --- abo has become available [21:17:00] a nack provides an upper-bound on what the rtt should be [21:17:18] that is all we are after. how long should we wait before sending a retry [21:24:47] --- Simon Wilkinson has left [21:27:56] i'm not arguing not a NACK. i'm arguing the outside the window case [21:36:42] the outside the window case is wrong [21:37:27] we have other problems with windows that we will need to fix. Simon has some ideas and perhaps code that will reduce the cost of evaluating the packets in the transmit queue. [21:38:23] i'll talk with him about it tomorrow and we'll see if his overlap with mine [21:38:53] at the moment i am nearing the end of my broadcasting day [21:40:36] Simon has hit the end of his. I'm wrapping up mine. [22:25:59] > NACK it seems like you're double-counting the ack in that case for the rtt computation, though... if you send 2 packets and the 1st gets dropped, for rtt you're treating it the same as if you can deliver 2 packets in that amount of time, which you can't [22:26:06] or rather, which you may or may not be able to [22:27:42] but either way it's not causing problems for me or anything; the code just confused me, so thanks for clarifying [22:32:44] --- deason has left [23:01:30] --- Russ has left: Disconnected