Use skb timestamp for TX side
PATCH 6/29 Use skb timestamp for TX side
This patch uses skb timestamps (and provides the necessary enable/disable mechanism) instead of layer-4 timestamping. This affords a more accurate RTT estimation.
Background:
The sender currently computes the timestamp of received (Ack) packets when the packet is delivered to layer 4. The skb timestamp is taken earlier, and the differences are notable: dDuring test runs under different load conditions, the layer-4 timestamp was observed to be on average up to 100 microseconds, in the extreme up to a millisecond, later than the skb timestamp. This has a negative impact on the RTT estimation (reduced accuracy).
--- net/dccp/ccids/ccid3.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-)
net/dccp/ccids/ccid3.c +3 -1
@@ -469,7 +469,7 @@ static void ccid3_hc_tx_packet_recv(struct sock *sk, struct sk_buff *skb) else /* can not exceed 100% */ hctx->ccid3hctx_p = 1000000 / pinv; -do_gettimeofday (&now); +skb_get_timestamp (skb, &now);/* * Calculate new round trip sample as per [RFC 3448, 4.3] by
@@ -645,6 +645,7 @@ static int ccid3_hc_tx_init(struct ccid *ccid, struct sock *sk) ccid3_hc_tx_no_feedback_timer; hctx->ccid3hctx_no_feedback_timer.data = (unsigned long )sk;init_timer (&hctx->ccid3hctx_no_feedback_timer); +net_enable_timestamp ();return 0 ; }
@@ -657,6 +658,7 @@ static void ccid3_hc_tx_exit(struct sock *sk)ccid3_hc_tx_set_state (sk,TFRC_SSTATE_TERM );sk_stop_timer (sk, &hctx->ccid3hctx_no_feedback_timer); +net_disable_timestamp ();/* Empty packet history */ dccp_tx_hist_purge (ccid3_tx_hist, &hctx->ccid3hctx_hist);
Signature · 1 line
1.5.0.6
David Miller
maintainerFrom: Arnaldo Carvalho de Melo <[email protected]>
Date: Thu, 12 Apr 2007 18:14:46 -0300
Quoted 13 lines
This patch uses skb timestamps (and provides the necessary enable/disable mechanism) instead of layer-4 timestamping. This affords a more accurate RTT estimation.
Background:
The sender currently computes the timestamp of received (Ack) packets when the packet is delivered to layer 4. The skb timestamp is taken earlier, and the differences are notable: dDuring test runs under different load conditions, the layer-4 timestamp was observed to be on average up to 100 microseconds, in the extreme up to a millisecond, later than the skb timestamp. This has a negative impact on the RTT estimation (reduced accuracy).
Quoted 3 lines
Signed-off-by Gerrit Renker <[email protected]>Acked-by Ian McDonald <[email protected]>Signed-off-by Arnaldo Carvalho de Melo <[email protected]>
This patch screws the entire system over with the overhead of timestamping every packet processed as soon as there are DCCP sockets using ccid3.
I'll pull this in for now, but you must find a better way before I merge this to Linus for 2.6.22
Quoted 20 lines · David Miller
From: Arnaldo Carvalho de Melo <[email protected]>
Date: Thu, 12 Apr 2007 18:14:46 -0300Quoted 13 lines
This patch uses skb timestamps (and provides the necessary enable/disable mechanism) instead of layer-4 timestamping. This affords a more accurate RTT estimation.
Background:
The sender currently computes the timestamp of received (Ack) packets when the packet is delivered to layer 4. The skb timestamp is taken earlier, and the differences are notable: dDuring test runs under different load conditions, the layer-4 timestamp was observed to be on average up to 100 microseconds, in the extreme up to a millisecond, later than the skb timestamp. This has a negative impact on the RTT estimation (reduced accuracy).
Quoted 3 lines
Signed-off-by Gerrit Renker <[email protected]>Acked-by Ian McDonald <[email protected]>Signed-off-by Arnaldo Carvalho de Melo <[email protected]>
Quoted 6 lines
This patch screws the entire system over with the overhead of timestamping every packet processed as soon as there are DCCP sockets using ccid3.
I'll pull this in for now, but you must find a better way before I merge this to Linus for 2.6.22
I think then that we revert this patch also. If there are genuine races going on around time stamping (which was one of the arguments) then we can implement our own locking where needed.
Signature · 3 lines
Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz WAND Network Research Group