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
On Fr, 20.07.2012, 16:06, Yuchung Cheng wrote:
On Mon, Jul 16, 2012 at 6:03 AM, Piotr Sawuk a9702...@unet.univie.ac.at
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
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
On Mon, Jul 16, 2012 at 6:03 AM, Piotr Sawuk a9702...@unet.univie.ac.at 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
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
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 hopefully
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_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
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
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
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
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 by
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 by ss -i
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 port then
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, 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- this packet
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 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]
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
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 the
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.
Instead of
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.pdf
A
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
[1]
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
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
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
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 comment, could
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. */
+
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
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
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
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
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
On Do, 12.07.2012, 23:35, Stephen Hemminger wrote:
On Thu, 12 Jul 2012 22:55:57 +0200
Piotr Sawuk a9702...@unet.univie.ac.at 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
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 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 was
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(>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
>
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(>lock) with
struct tcp_ehash_bucket *head = _ehash[i];
at the
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
On Thu, 12 Jul 2012 22:55:57 +0200
Piotr Sawuk a9702...@unet.univie.ac.at 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
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
48 matches
Mail list logo
