William "Chops" Westfield mac.com> writes: > On Dec 18, 2005, at 12:39 PM, Peter wrote: > > >>> Ethernet and WiFi does not scale linearly with users and/or speed. > >> > >> A controversial statement. > > > I think that some stress testing will show that a normal bunch of > > machines hitting the same server on the same segment at the same time > > will result in spectacularly un-democratic bandwidth distribuition and > > huge backoff times > > But are those ethernet limitations or transport limitations? There was > a > lot of research on fairness and so on at the TCP level. Briefly. Then > microsoft got into networking in a big way with proprietary code that > (probably) ignored much of that research and the rest is history... My reference to testing refers to unix:unix testing. No uncompliant tcp/ip stack was involved. My understanding is that assuming 2 machines hit the same server with a request, and the packets collide, the clients will re-request, subject to a random delay. This is when one of the clients wins. Thereafter the first client starts pulling data and saturates the network, and the second client retransmits at longer and longer intervals, with very good chances of causing a collision followed by an even longer delay to the next request. It is possible to control this by using throttling but it's still not so good, since the peers are not synchronised, the higher the traffic the more collisions, the more retransmit delays, and the slower it gets. I think that a segment with a lot of peers can only run at up to 50% of the segment speed, and this can only be divided evenly if per-client throttling is used (which throttling must be dynamic - i.e. one peer - 100% bw - 2 peers - give 50% each - 3 - give 33% each etc). If any peers engage in unruly behavior, like ping or arp storms or broadcasting 'election' data in a SMB domain you can just about forget about the 50% too. As you know, with default settings, a TCP/IP stack that sees 50% collisions will slow down considerably, thus any imbalance in the distribution will be immediately amplified. Everyone knows download cases where one has maybe 3 parallel connections to the same server, and they almost invariably become unbalanced, with one using up the bulk of the bandwidth, and the others lagging behind more or less slowly. Peter -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist