On Fr, 20.07.2012, 16:06, Yuchung Cheng wrote:
> On Mon, Jul 16, 2012 at 6:03 AM, Piotr Sawuk
> wrote:
>> On Mo, 16.07.2012, 13:46, Eric Dumazet wrote:
>>> On Mon, 2012-07-16 at 13:33 +0200, Piotr Sawuk wrote:
On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
> I am not sure if the is r
On Mon, Jul 16, 2012 at 6:03 AM, Piotr Sawuk wrote:
> On Mo, 16.07.2012, 13:46, Eric Dumazet wrote:
>> On Mon, 2012-07-16 at 13:33 +0200, Piotr Sawuk wrote:
>>> On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
>>> > I am not sure if the is really necessary since the most
>>> > of the stats are a
On Mo, 16.07.2012, 17:24, Christoph Paasch wrote:
> You should do jiffies_to_msecs(tp->srtt) >> 3.
>
> The RTT is already exposed by tcp_info anyway... (see tcp_get_info() - where
> you also see the bitshift)
thanks a lot. rtt is output for completion's sake, it helps in diagnosis.
here my hopefu
On Monday 16 July 2012 17:12:26 Piotr Sawuk wrote:
> + seq_printf(seq, "%d: %-21pI4:%u %-21pI4:%u "
> + "%8u %8lu %8lu %8lu %8lu%n",
> + st->num,
> + &inet->inet_rcv_saddr,
> +
On Mo, 16.07.2012, 15:32, Ben Hutchings wrote:
> On Sat, 2012-07-14 at 09:56 +0200, Piotr Sawuk wrote:
>> On Sa, 14.07.2012, 03:31, valdis.kletni...@vt.edu wrote:
>> > On Fri, 13 Jul 2012 16:55:44 -0700, Stephen Hemminger said:
>> >
>> >> >+/* Course retransmit inefficiency-
On Sat, 2012-07-14 at 09:56 +0200, Piotr Sawuk wrote:
> On Sa, 14.07.2012, 03:31, valdis.kletni...@vt.edu wrote:
> > On Fri, 13 Jul 2012 16:55:44 -0700, Stephen Hemminger said:
> >
> >> >+ /* Course retransmit inefficiency- this packet has been
> >> >received
> >> twice. */
> >> >+
On Mo, 16.07.2012, 13:46, Eric Dumazet wrote:
> On Mon, 2012-07-16 at 13:33 +0200, Piotr Sawuk wrote:
>> On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
>> > I am not sure if the is really necessary since the most
>> > of the stats are available elsewhere.
>>
>> if by "most" you mean address and
On Mon, 2012-07-16 at 13:33 +0200, Piotr Sawuk wrote:
> On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
> > I am not sure if the is really necessary since the most
> > of the stats are available elsewhere.
>
> if by "most" you mean address and port then you're right.
> but even the rtt reported
On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
> I am not sure if the is really necessary since the most
> of the stats are available elsewhere.
if by "most" you mean address and port then you're right.
but even the rtt reported by "ss -i" seems to differ from tcphealth.
however, if instead b
On So, 15.07.2012, 11:53, Eric Dumazet wrote:
> On Sun, 2012-07-15 at 11:17 +0200, Piotr Sawuk wrote:
>> On So, 15.07.2012, 09:16, Eric Dumazet wrote:
>> > On Sun, 2012-07-15 at 01:43 +0200, Piotr Sawuk wrote:
>> >
>> >> oh, and again I recommend the really short although outdated thesis
>> >>
>> >
On Sun, 2012-07-15 at 11:17 +0200, Piotr Sawuk wrote:
> On So, 15.07.2012, 09:16, Eric Dumazet wrote:
> > On Sun, 2012-07-15 at 01:43 +0200, Piotr Sawuk wrote:
> >
> >> oh, and again I recommend the really short although outdated thesis
> >>
> >> [1] https://sacerdoti.org/tcphealth/tcphealth-paper.
On So, 15.07.2012, 09:16, Eric Dumazet wrote:
> On Sun, 2012-07-15 at 01:43 +0200, Piotr Sawuk wrote:
>
>> oh, and again I recommend the really short although outdated thesis
>>
>> [1] https://sacerdoti.org/tcphealth/tcphealth-paper.pdf
>
> A thesis saying SACK are not useful is highly suspect.
>
>
On Sun, 2012-07-15 at 01:43 +0200, Piotr Sawuk wrote:
> oh, and again I recommend the really short although outdated thesis
>
> [1] https://sacerdoti.org/tcphealth/tcphealth-paper.pdf
A thesis saying SACK are not useful is highly suspect.
Instead of finding why they behave not so good and fix t
On Sa, 14.07.2012, 23:48, Stephen Hemminger wrote:
> Maybe it would be better to use netlink info (for ss command)
> rather than a /proc/net interface.
> See how existing TCP values and MEMINFO are handled.
>
I'm confused, what exactly do you mean?
of course a library-interface might be more inter
Maybe it would be better to use netlink info (for ss command)
rather than a /proc/net interface.
See how existing TCP values and MEMINFO are handled.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
Don't we report all of this shit in tcp_info already?
I really hate such cruddy patches like this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pl
On Sat, 2012-07-14 at 09:56 +0200, Piotr Sawuk wrote:
> On Sa, 14.07.2012, 03:31, valdis.kletni...@vt.edu wrote:
> > On Fri, 13 Jul 2012 16:55:44 -0700, Stephen Hemminger said:
> >
> >> >+ /* Course retransmit inefficiency- this packet has been
> >> >received
> >> twice. */
> >> >+
On Sa, 14.07.2012, 03:31, valdis.kletni...@vt.edu wrote:
> On Fri, 13 Jul 2012 16:55:44 -0700, Stephen Hemminger said:
>
>> >+ /* Course retransmit inefficiency- this packet has been
>> >received
>> twice. */
>> >+ tp->dup_pkts_recv++;
>> I don't understand that
On Fri, 13 Jul 2012 16:55:44 -0700, Stephen Hemminger said:
> >+/* Course retransmit inefficiency- this packet has been
> >received twice. */
> >+tp->dup_pkts_recv++;
>
> I don't understand that comment, could you use a better sentence please?
I think what
I am not sure if the is really necessary since the most
of the stats are available elsewhere.
Here are some comments on getting the simplified to match
the kernel style.
>
> static inline struct tcp_sock *tcp_sk(const struct sock *sk)
>diff -rub A/net/ipv4/tcp_input.c B/net/ipv4/tcp_input.c
>---
On Do, 12.07.2012, 23:35, Stephen Hemminger wrote:
> On Thu, 12 Jul 2012 22:55:57 +0200
> "Piotr Sawuk" wrote:
>
>> + * Federico D. Sacerdoti: Added TCP health monitoring.
>
> Please don't do this.
> The kernel community no longer maintains a list of contributors
> in the comments. The h
On 07/12/2012 01:55 PM, Piotr Sawuk wrote:
> hello! I haven't done any kernel-hacking before, so be patient.
>
> I got as far as to make tcphealth run, but now I need some help:
> how does read-locking work in the tcp_sock struct?
> the original code (for 2.5.1) made a read_lock(&head->lock) with
On Thu, 12 Jul 2012 22:55:57 +0200
"Piotr Sawuk" wrote:
> diff -rub linux-3.4.4/net/ipv4/tcp_input.c
> linux-3.4.4-heal-lsm/net/ipv4/tcp_input.c
> --- linux-3.4.4/net/ipv4/tcp_input.c 2012-06-22 20:37:50.0 +0200
> +++ linux-3.4.4-heal-lsm/net/ipv4/tcp_input.c 2012-07-06
> 10:12:12.00
hello! I haven't done any kernel-hacking before, so be patient.
I got as far as to make tcphealth run, but now I need some help:
how does read-locking work in the tcp_sock struct?
the original code (for 2.5.1) made a read_lock(&head->lock) with
struct tcp_ehash_bucket *head = &tcp_ehash[i];
at the
24 matches
Mail list logo
