| To: | Federico David Sacerdoti <fds@xxxxxxxxxxx> |
|---|---|
| Subject: | Re: A TCP monitoring /proc/net file |
| From: | Andi Kleen <ak@xxxxxx> |
| Date: | Sat, 24 Mar 2001 13:34:24 +0100 |
| Cc: | Andi Kleen <ak@xxxxxx>, "David S. Miller" <davem@xxxxxxxxxx>, kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx, linux-net@xxxxxxxxxxxxxxx |
| In-reply-to: | <3ABBAFC2.6991DBA2@xxxxxxxxxxx>; from fds@xxxxxxxxxxx on Fri, Mar 23, 2001 at 09:19:14PM +0100 |
| References: | <3ABA9E98.81D1413E@xxxxxxxxxxx> <15034.40807.977418.671551@xxxxxxxxxxxxxxx> <20010323093918.A1476@xxxxxxxxxx> <3ABBAFC2.6991DBA2@xxxxxxxxxxx> |
| Sender: | owner-netdev@xxxxxxxxxxx |
On Fri, Mar 23, 2001 at 09:19:14PM +0100, Federico David Sacerdoti wrote: > The external monitoring made possible by the /proc/net/tcphealth is > interesting because the SRTT is proportional to the speed of one's > network connection, and duplicate acks indicate that packets are being > lost (or reordered, less likely) somewhere in the network. 2.4 has a special state machine to detect reordering when the connection supports timestamps. I guess some long term statistics (currently TCP_INFO only dumps current state) would be useful too, but it's David's call if he want to put in the few cycles that'll cost (probably only in slow paths anyways) I guess it would be better if you would put it into the existing TCP_INFO framework, perhaps with an additional /proc frontend to TCP_INFO. Having two ways to do a similar thing is not good. -Andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Adding just a pinch of icache/dcache pressure..., Andrew Morton |
|---|---|
| Next by Date: | Re: Adding just a pinch of icache/dcache pressure..., Jan Harkes |
| Previous by Thread: | Re: A TCP monitoring /proc/net file, Federico David Sacerdoti |
| Next by Thread: | Re: A TCP monitoring /proc/net file, kuznet |
| Indexes: | [Date] [Thread] [Top] [All Lists] |