> things get this bad). Network bottlenecks are especially troublesome: even > with a switched 100BaseT network, the pipe from server to switch is only > 100Mbps. However, this pipe must serve every single client. If you have 50 > clients sharing a 100Mbps pipe, you're going to have bottlenecks. The only > way around this that I can see is some sort of channel bonding, where you > have two or more network cards that are considered by the kernel to be a > single ip address, and network load is shared among them. But this would > require a switch that also knew about this, and divided load accordingly. I > don't have the network expertise to say anything more on this matter, and I > don't even know if its possible.
Having done a bit more research, it seems that channel bonding (aka 'trunking' by 3com) really is as simple as this. You need a switch that knows about channel bonding and has a good implementation, and it's best to bond identical network cards (although different ones will work). The problem is mostly getting a switch that has a good implementation: not all are created equal, it seems. A lot of good info is in the kernel docs, even on what switches are know to work and on network topology issues: see Documentation/networking/bonding.txt As for the kernels, >2.4.12 have native support, though you almost certainly need to recompile your kernel. You also need the userland tool 'ifenslave' to do the actual bonding. It is found in the kernel docs, Documentation/networking/ifenslave.c Reading the docs ( Documentation/networking/bonding.txt ), the Linux implementation appears quite robust. SMP safe, NIC-independent (even Gigabit ethernet!), multiple bonded channels, no limit to number of slaves per channel, three different bonding modes, and two ways to compensate for NIC failure (depending on your card's capabilities). Kernels <2.4.12 may require application of a patch and grabbing ifenslave from the net. See Documentation/networking/bonding.txt for details. Stolen from bonding.txt: Resources and links =================== Current developement on this driver is posted to: - http://www.sourceforge.net/projects/bonding/ Donald Becker's Ethernet Drivers and diag programs may be found at : - http://www.scyld.com/network/ You will also find a lot of information regarding Ethernet, NWay, MII, etc. at www.scyld.com. For new versions of the driver, patches for older kernels and the updated userspace tools, take a look at Willy Tarreau's site : - http://wtarreau.free.fr/pub/bonding/ - http://www-miaif.lip6.fr/willy/pub/bonding/ To get latest informations about Linux Kernel development, please consult the Linux Kernel Mailing List Archives at : http://boudicca.tux.org/hypermail/linux-kernel/latest/ [EOF] Just FYI, it seems Beowulf clusters use channel bonding quite a bit, although they typically have channel bonding on both clients (rather, nodes, I guess) and server, with the channels running through different switches. This solution is not really practical for LTSP setups since the only bottleneck is between switch and server, not client and switch. With channel bonding, monolithic server setups might be a bit more compelling. At the very least, putting clients and servers on separate subnets is a more viable option for even very large numbers of clients. -- Francis Avila ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.openprojects.net
