i wrote a prototype for a nic driver for my theses some time
ago. when looking at the performance of my nic driver i could
not beleave how slow it is. i started to log tcp sequence
numbers and saw that the network stack asks my driver to
transmit the same tcp paket multiple times within less then
2ms. how can that happen? below you see what the drivers sees
when an ssh connection is set up on a PII 400MHz 2.4.7 kernel.
why does net_dev.hard_start_xmit get called multiple times
with the same tcp packet?
TxMit: transmit function of the nic driver
TxIrq: packet transmission reported by nic
RxIrq: packet reception reported by nic
cpu clock-tick | event | Tcp SeqNo | Tcp AckNo
---------------|-------|-----------|----------
0x186dce194bc8 | TxMit | 909902971 | 0
0x186dce1beb05 | TxIrq | 909902971 | 0
0x186dce1ef8f8 | RxIrq | 897283491 | 909902972
0x186dce1f8b03 | TxMit | 909902972 | 897283492
0x186dce220317 | TxIrq | 909902972 | 897283492
0x186dce3002e8 | RxIrq | 897283492 | 909902972
0x186dce308560 | TxMit | 909902972 | 897283515 <- dublicate
0x186dce330bab | TxIrq | 909902972 | 897283515
0x186dce3c09bf | TxMit | 909902972 | 897283515 <- dublicate
0x186dce3e9b6f | TxIrq | 909902972 | 897283515
0x186dce424310 | RxIrq | 897283515 | 909902994
0x186dce47bc44 | RxIrq | 897283515 | 909902994
0x186dcf094683 | TxMit | 909902994 | 897283791
0x186dcf0bcafb | TxIrq | 909902994 | 897283791
From: Christian Widmer <[email protected]>
Date: Fri, 5 Oct 2001 14:29:53 +0200
why does net_dev.hard_start_xmit get called multiple times
with the same tcp packet?
Because the ACK is not coming back for those packets within the RTO
(which for a local network is very low). Check your TCP dumps,
the ACKs of the original data packets are being dropped in transit.
Franks a lot,
David S. Miller
[email protected]
"David S. Miller" wrote:
>
> From: Christian Widmer <[email protected]>
> Date: Fri, 5 Oct 2001 14:29:53 +0200
>
> why does net_dev.hard_start_xmit get called multiple times
> with the same tcp packet?
>
> Because the ACK is not coming back for those packets within the RTO
> (which for a local network is very low). Check your TCP dumps,
> the ACKs of the original data packets are being dropped in transit.
Well, TCP certainly shouldn't be sending two retransmissions
back-to-back within 2ms, especially with nothing received in between.
Not with RTO (which in Linux is never below 20ms, and according to RFC
should be conservatively rounded up to 1 second), nor with fast
retransmits or SACK.
Just an observation.
MikaL
That isn't a duplicate:
>0x186dce1f8b03 | TxMit | 909902972 | 897283492
> 0x186dce220317 | TxIrq | 909902972 | 897283492
> 0x186dce3002e8 | RxIrq | 897283492 | 909902972
> 0x186dce308560 | TxMit | 909902972 | 897283515 <- dublicate
Acknowledge 897283515, send 0 bytes.
(must be send 0, since the next tx has the same sequence no)
> 0x186dce330bab | TxIrq | 909902972 | 897283515
> 0x186dce3c09bf | TxMit | 909902972 | 897283515 <- dublicate
Acknowledge didn't change, send 22 bytes
(must be 22 bytes, 909902994-909902972)
> 0x186dce3e9b6f | TxIrq | 909902972 | 897283515
> 0x186dce424310 | RxIrq | 897283515 | 909902994
> 0x186dce47bc44 | RxIrq | 897283515 | 909902994
> 0x186dcf094683 | TxMit | 909902994 | 897283791
I'd say bad luck: you try to send data 2 milliseconds after the delack
timer expired.
--
Manfred