On 31 Aug, 2012, at 7:40 pm, Jim Gettys wrote: > On 08/31/2012 08:53 AM, Rick Jones wrote: >> On 08/30/2012 11:55 PM, Eric Dumazet wrote: >>> On locally generated TCP traffic (host), we can override the 100 ms >>> interval value using the more accurate RTT estimation maintained by TCP >>> stack (tp->srtt) >>> >>> Datacenter workload benefits using shorter feedback (say if RTT is below >>> 1 ms, we can react 100 times faster to a congestion) >>> >>> Idea from Yuchung Cheng. >> >> Mileage varies of course, but what are the odds of a datacenter's >> end-system's NIC(s) being the bottleneck point?
> Ergo my comment about Ethernet flow control finally being possibly more > help than hurt; clearly if the bottleneck is kept in the sending host > more of the time, it would help. > > I certainly don't know how often the end-system's NIC's are the > bottleneck today without flow control; maybe a datacenter type might > have insight into that. Consider a fileserver with ganged 10GE NICs serving an office full of GigE workstations. At 9am on Monday, everyone arrives and switches on their workstation, which (because the org has made them diskless) causes pretty much the same set of data to be sent to each in rapid succession. The fileserver satisfies all but the first of these from cache, so it can saturate all of it's NICs in theory. In that case a queue should exist even if there are no downstream bottlenecks. Alternatively, one floor at a time boots up at once - say the call-centre starts up at 7am, the developers stumble in at 10am, and the management types wander in at 11:30. :-) Then the bottleneck is the single 10GE link to each floor, rather than the fileserver's own NICs. That's all theoretical, of course - I've never built a datacentre network so I don't know how it's done in practice. - Jonathan Morton _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
