Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\]\s+TCP\s+congestion\s+schedulers\s*$/: 52 ]

Total 52 documents matching your query.

21. iscuss] Summary of 2005 Kernel Summit Proposed Topics (score: 1)
Author: xxxxxxxxx>
Date: Tue, 29 Mar 2005 09:17:25 -0800
Getting IA64 setup today, to check. The difference was so tiny that it is in the noise of the measurements.
/archives/netdev/2005-03/msg01696.html (11,381 bytes)

22. iver ? (score: 1)
Author: xx>
Date: Tue, 29 Mar 2005 10:58:56 -0800
I took the liberty of asking one of the IA64 guru's about the indirect calls. This is what he had to say (reposted with his permision if not my complete comprehension :) <excerpt> McKinley-type cores
/archives/netdev/2005-03/msg01701.html (12,183 bytes)

23. g driver ? (score: 1)
Author: xx>
Date: Tue, 29 Mar 2005 14:32:33 -0500 (EST)
The motivation for my question is that I get very unpredictable performance over loopback with UP for all architectures, often varying by more than a factor of two. I haven't really tried to track do
/archives/netdev/2005-03/msg01705.html (10,704 bytes)

24. hedulers (score: 1)
Author: r Kepner <akepner@xxxxxxx>
Date: Tue, 29 Mar 2005 12:03:06 -0800
It could be L2 cache-coloring effects as well. Try to keep the working set size smaller than the L2 cache size of the cpu you are on.
/archives/netdev/2005-03/msg01707.html (10,672 bytes)

25. e driver (score: 1)
Author: avinandan Arakali" <ravinandan.arakali@xxxxxxxxxxxx>
Date: Tue, 29 Mar 2005 12:09:20 -0800
It could be L2 cache-coloring effects as well. Try to keep the working set size smaller than the L2 cache size of the cpu you are on. When/if using netperf, it will send from and recv to a "ring" of
/archives/netdev/2005-03/msg01710.html (10,129 bytes)

26. rmem_alloc)) failed at net/netlink/af_netlink.c (126) (score: 1)
Author: <david@xxxxxxxxxxxxxxxxxxxxx>
Date: Wed, 30 Mar 2005 01:41:24 -0800
[...] That's horrendous. Indirect calls are a performance win vs conditional branching on more sensible architectures and it's used quite extensively in various parts of the kernel. It really makes o
/archives/netdev/2005-03/msg01754.html (10,597 bytes)

27. Re: [RFC] TCP congestion schedulers (score: 1)
Author: John Heffner <jheffner@xxxxxxx>
Date: Fri, 8 Apr 2005 15:33:44 -0400 (EDT)
For the record, here are some benchmarks from an ia64 over GigE. I set the MTU to 564 so it actually stressed the CPU. Numbers are throughput (10^6 bits/sec). Command line used: netperf -H 192.168.1.
/archives/netdev/2005-04/msg01539.html (10,736 bytes)

28. Re: [RFC] TCP congestion schedulers (score: 1)
Author: Rick Jones <rick.jones2@xxxxxx>
Date: Fri, 08 Apr 2005 13:20:33 -0700
For the record, here are some benchmarks from an ia64 over GigE. I set the MTU to 564 so it actually stressed the CPU. Numbers are throughput (10^6 bits/sec). Command line used: netperf -H 192.168.1.
/archives/netdev/2005-04/msg01541.html (11,189 bytes)

29. [RFC] TCP congestion schedulers (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Mon, 14 Mar 2005 15:17:26 -0800
Since developers want to experiment with different congestion control mechanisms, and the kernel is getting bloated with overlapping data structure and code for multiple algorithms; here is a patch t
/archives/netdev/2005-03/msg02789.html (110,446 bytes)

30. Re: [RFC] TCP congestion schedulers (score: 1)
Author: John Heffner <jheffner@xxxxxxx>
Date: Tue, 15 Mar 2005 14:54:24 -0500 (EST)
Cool. :) Here's High Speed TCP. -John -- /* * Sally Floyd's High Speed TCP (RFC 3649) congestion control * * See http://www.icir.org/floyd/hstcp.html * * John Heffner <jheffner@xxxxxxx> */ include <l
/archives/netdev/2005-03/msg02861.html (15,830 bytes)

31. Re: [RFC] TCP congestion schedulers (score: 1)
Author: John Heffner <jheffner@xxxxxxx>
Date: Tue, 15 Mar 2005 17:16:19 -0500 (EST)
This fixes a null pointer dereference when closing listen sockets. -John == include/net/tcp.h 1.107 vs 1.108 == -- 1.107/include/net/tcp.h Tue Mar 15 15:12:54 2005 +++ 1.108/include/net/tcp.h Tue Mar
/archives/netdev/2005-03/msg02869.html (10,775 bytes)

32. Re: [RFC] TCP congestion schedulers (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Thu, 17 Mar 2005 20:12:31 -0800
An array of 48 pointers to "u8" eh? :-) It happens to work, but you're using too much space (specifically: 48 * sizeof(u8 *)) as a side effect. Otherwise, the only comment I have is that we lose the
/archives/netdev/2005-03/msg02965.html (10,957 bytes)

33. Re: [RFC] TCP congestion schedulers (score: 1)
Author: Arnaldo Carvalho de Melo <arnaldo.melo@xxxxxxxxx>
Date: Fri, 18 Mar 2005 09:53:25 -0300
I haven't looked over this patch completely, so I may well be saying something stupid, but if possible, please don't use the tcp/TCP prefix where you think this code can be used by other inet transpo
/archives/netdev/2005-03/msg02979.html (12,367 bytes)

34. Re: [RFC] TCP congestion schedulers (score: 1)
Author: jamal <hadi@xxxxxxxxxx>
Date: 18 Mar 2005 08:43:04 -0500
Yes, that would be really nice. Also heres another thought: if we can have multiple sockets, destined to the same receiver, to share the same congestion state. This is motivated from the CM idea the
/archives/netdev/2005-03/msg02980.html (11,888 bytes)

35. Re: [RFC] TCP congestion schedulers (score: 1)
Author: Arnaldo Carvalho de Melo <arnaldo.melo@xxxxxxxxx>
Date: Fri, 18 Mar 2005 13:13:45 -0300
The DCCP drafts mention that they choose not to require the CM, but yes, it is something to consider anyway, its interesting stuff. Again without looking at the patch fully, the tcp_sock passing to t
/archives/netdev/2005-03/msg02982.html (13,071 bytes)

36. Re: [RFC] TCP congestion schedulers (score: 1)
Author: Stephen Hemminger <shemminger@xxxxxxxx>
Date: Fri, 18 Mar 2005 08:45:55 -0800
Let's abstract it for TCP first, then as a later patch reduce the scope and generalize it.
/archives/netdev/2005-03/msg02983.html (13,281 bytes)

37. Re: [RFC] TCP congestion schedulers (score: 1)
Author: Arnaldo Carvalho de Melo <arnaldo.melo@xxxxxxxxx>
Date: Fri, 18 Mar 2005 13:59:02 -0300
Fine with me, just wanted to trow these thoughts so that when working on it you think about it :-) -- - Arnaldo
/archives/netdev/2005-03/msg02985.html (14,226 bytes)

38. Re: [RFC] TCP congestion schedulers (score: 1)
Author: Andi Kleen <ak@xxxxxx>
Date: Sat, 19 Mar 2005 21:19:11 +0100
[...] Did you do any benchmarks to check that wont slow it down? I would recommend to try it on a IA64 machine if possible. In the past we found that adding indirect function calls on IA64 to network
/archives/netdev/2005-03/msg03040.html (12,018 bytes)

39. Re: [RFC] TCP congestion schedulers (score: 1)
Author: John Heffner <jheffner@xxxxxxx>
Date: Mon, 21 Mar 2005 16:25:56 -0500 (EST)
Is there a canonical benchmark? Would you really expect a single extra indirect call per ack to have a significant performance impact? This is surprising to me. Where does the cost come from? Replaci
/archives/netdev/2005-03/msg03109.html (12,493 bytes)

40. Re: [RFC] TCP congestion schedulers (score: 1)
Author: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Mon, 21 Mar 2005 13:51:54 -0800
Maybe not for ACK processing (that's very thick already) but perhaps for a lighter fast path definitely so.
/archives/netdev/2005-03/msg03112.html (12,042 bytes)


This search system is powered by Namazu