Changeset View
Standalone View
sys/netinet/tcp_stacks/rack.c
- This file is larger than 256 KB, so syntax highlighting is disabled by default.
| Show First 20 Lines • Show All 6,600 Lines • ▼ Show 20 Lines | if (frac) { | ||||
| if (hz == 1000) { | if (hz == 1000) { | ||||
| frac = (((uint64_t)frac * (uint64_t)HPTS_USEC_IN_MSEC) / (uint64_t)TCP_RTT_SCALE); | frac = (((uint64_t)frac * (uint64_t)HPTS_USEC_IN_MSEC) / (uint64_t)TCP_RTT_SCALE); | ||||
| } else { | } else { | ||||
| frac = (((uint64_t)frac * (uint64_t)HPTS_USEC_IN_SEC) / ((uint64_t)(hz) * (uint64_t)TCP_RTT_SCALE)); | frac = (((uint64_t)frac * (uint64_t)HPTS_USEC_IN_SEC) / ((uint64_t)(hz) * (uint64_t)TCP_RTT_SCALE)); | ||||
| } | } | ||||
| tp->t_rttvar += frac; | tp->t_rttvar += frac; | ||||
| } | } | ||||
| } | } | ||||
| RACK_TCPT_RANGESET(tp->t_rxtcur, RACK_REXMTVAL(tp), | tp->t_rxtcur = RACK_REXMTVAL(tp); | ||||
| rack_rto_min, rack_rto_max); | if (TCPS_HAVEESTABLISHED(tp->t_state)) { | ||||
| tp->t_rxtcur += TICKS_2_USEC(tcp_rexmit_slop); | |||||
rrs: What is the reason you don't want to have RTT Slop in the mix here?
I do think its a bit high… | |||||
Done Inline ActionsWhen retransmitting the first SYN, the base stack does not include the slop. So when switching to RACK before the first SYN goes out, the behvaiour would be different. However, thinking about that, when switching in the middle of a connection, you want to put the slop in there. Regarding the t_rttlow: I think in principle the conversion would belong to the routine. But let me take that out, since it is a separate issue. tuexen: When retransmitting the first SYN, the base stack does not include the slop. So when switching… | |||||
Not Done Inline Actionst_rttlow is not used by rack. It is updated, but not used. Its arguably incorrect So my fundamental question then is why do we have slop included in any timeout? If its good enough for the SYN not to include it, why do we include it on I suppose it could be an allowance for the fact that a full segment may have a propagation delay rrs: t_rttlow is not used by rack. It is updated, but not used. Its arguably incorrect
when we go to… | |||||
Done Inline ActionsI thought it is to compensate for a delay of the peer when the timer is based on the actual RTT. But then it does not make sense to use it in (all but the first) retransmission SYN retransmissions... tuexen: I thought it is to compensate for a delay of the peer when the timer is based on the actual RTT. | |||||
| } | |||||
| if (tp->t_rxtcur > rack_rto_max) { | |||||
| tp->t_rxtcur = rack_rto_max; | |||||
| } | |||||
| } | } | ||||
| static void | static void | ||||
| rack_cc_conn_init(struct tcpcb *tp) | rack_cc_conn_init(struct tcpcb *tp) | ||||
| { | { | ||||
| struct tcp_rack *rack; | struct tcp_rack *rack; | ||||
| uint32_t srtt; | uint32_t srtt; | ||||
| ▲ Show 20 Lines • Show All 13,338 Lines • Show Last 20 Lines | |||||
What is the reason you don't want to have RTT Slop in the mix here?
I do think its a bit high IIRR 200ms, but if we are going to use it the
next RTT measurement we get, why is it not valid for the first time
we go established too?
Oh and I am not sure about t_rttlow, rack does not use it, not sure who
does, but I don't think the conn_init code sets it either so probably doing
it here is a double conversion ... not that it matters it will get set right
on the next measurement unless it translates to a very small number which
I don't think it will.