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

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.

1. 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/msg00403.html (9,991 bytes)
2. 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/msg00405.html (10,368 bytes)
3. t away? (score: 1): Author: <yoshfuji@xxxxxxxxxx>; 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/msg00866.html (109,705 bytes)
4. tion Layer II (score: 1): Author: x>; 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/msg00938.html (15,167 bytes)
5. nce for IGMP (alb/tlb mode) (score: 1): Author: herbert@xxxxxxxxxxxxxxxxxxx>; 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/msg00946.html (10,127 bytes)
6. 婃槆澶┿仐銇俱亸銈娾櫔 (score: 1): Author: @xxxxxx>; 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/msg01042.html (10,309 bytes)
7. th (score: 1): Author: ert@xxxxxxxxxxxxxxxxxxx>; 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/msg01056.html (11,793 bytes)
8. as a wrong header (score: 1): Author: xxxxxxxxxxxxxx>; 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/msg01057.html (11,283 bytes)
9. Ipsec-tools-devel] more phase 2 reinitiation problems (score: 1): Author: u <herbert@xxxxxxxxxxxxxxxxxxx>; 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/msg01059.html (12,547 bytes)
10. itiation problems (score: 1): Author: t@xxxxxxxxxxxxxxxxxxx>; 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/msg01060.html (12,721 bytes)
11. e: [PATCH] /proc/net/stat/rt_cache has a wrong header (score: 1): Author: lo <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/msg01062.html (13,755 bytes)
12. Experimental Driver for Neterion/S2io 10GbE Adapters (score: 1): Author: xxxxxxxxxxxxxx>; 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/msg01117.html (11,370 bytes)
13. x IPsec calculation in ip_append_data/ip6_append_data (score: 1): Author: <tgraf@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/msg01186.html (11,832 bytes)
14. e: iptables breakage WAS(Re: dummy as IMQ replacement (score: 1): Author: k <buytenh@xxxxxxxxxxxxxx>; 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/msg01189.html (11,323 bytes)
15. end_data/ip6_append_data (score: 1): Author: jheffner@xxxxxxx>; Date: Mon, 21 Mar 2005 22:30:03 +0000; David S. Miller wrote: On Mon, 21 Mar 2005 16:25:56 -0500 (EST) John Heffner <jheffner@xxxxxxx> wrote: Would you really expect a single extra indirect call per ack to have a significant performance i; /archives/netdev/2005-03/msg01192.html (12,375 bytes)
16. der chips oops on shutdown (score: 1): Author: xxxxxxxx>; Date: Mon, 21 Mar 2005 16:10:36 -0800; John Heffner wrote: On Sat, 19 Mar 2005, Andi Kleen wrote: Stephen Hemminger <shemminger@xxxxxxxx> writes: Since developers want to experiment with different congestion control mechanisms, and the ke; /archives/netdev/2005-03/msg01197.html (18,411 bytes)
17. IMQ replacement (score: 1): Author: Walter <wolfgang.walter@xxxxxxxxxxxxxxxxxxxx>; Date: Tue, 22 Mar 2005 02:41:54 +0100; I think that was one of the benchmarks where the ia64 slowdown with LSM was diagnosed; netperf suffered some 10-15% degradation. And that was just with the capability module loaded, no fancy stuff go; /archives/netdev/2005-03/msg01202.html (11,006 bytes)
18. (score: 1): Author: xxxxxxx>; Date: Tue, 22 Mar 2005 08:41:22 +0100; For the LSM case we saw the problem with running netperf over loopback. It added one or two hooks per packet, but it already made a noticeable difference on IA64 boxes. On other systems it is unnotic; /archives/netdev/2005-03/msg01212.html (12,329 bytes)
19. ame all functions to have a common mv643xx_eth prefix (score: 1): Author: sworth" <dale@xxxxxxxxxxxxxx>; Date: Mon, 28 Mar 2005 15:51:17 -0800; Running on 2 Cpu Opteron using netperf loopback mode shows that the change is very small when averaged over 10 runs. Overall there is a .28% decrease in CPU usage and a .96% loss in throughput. But b; /archives/netdev/2005-03/msg01649.html (13,216 bytes)
20. d Topics (score: 1): Author: en Vreeken <pe1rxq@xxxxxxxxx>; Date: Tue, 29 Mar 2005 17:25:38 +0200; Opteron has no problems with indirect calls, IA64 seems to be different though. But when you see noticeable differences even on a Opteron I find it somewhat worrying. -Andi; /archives/netdev/2005-03/msg01687.html (11,102 bytes)

Current List: 1 - 20
Page: [1] [2] [3]