[Server-devel] buffer bloat - may be OT

[Tom Mitchell]

On Fri, Jun 3, 2011 at 1:16 PM, Peter Robinson <pbrobinson at gmail.com> wrote:
There are some back of the envelope computations that
can help with OLPC in a wireless mesh or from a server.

Bandwidth is fixed.  So if there are two OLPCs connecting
to a server you need to divide the bandwidth by two and target
a sub second send  buffer allocation configuration.   Watching
latency can prove important because latency problems indicate that
one application near or far could fill the buffers.   By keeping the
send buffers
small a fair share access to the net can effectively be established by
the system
process scheduler.  Receive buffers can be big, but it is better to
have the system
advertise a modest buffer space.

Next in the talk is a mention of critical services.  One of which is
name services.
DNS is in the critical path for almost all operations in the OLPC and XS server.
Time outs for DNS lookups are many seconds so a slow lookup can
keep a window from opening for many seconds.   Most often overlooked
is localhost (127.0.0.1).  After localhost are the lookups for private networks
(192.168.x.x, 172.16.x.x, 10.x.x.x).   These are often allocated by DHCP
for each OLPC but even these need to be resolved quickly because timeouts
are long.  The system will continue after the timeout but timeouts are long.
The XS must be able to resolve any address it allocates via DHCP.  And
each OLPC must be able to lookup names for all the IP addresses it connects to.
It is possible to setup a name server on the XS that is authorative or with
a host res order that places hosts before dns in the /etc/host.conf file.
Populating /etc/hosts with all the private name lookups is a valuable trick
when establishing a class room that is not known to the world because it
is hidden behind a NAT box.

Also watch for another type of private networking uses the link-local
address range
(169.254.1.0 to 169.254.255.254).  If link-local or Zero configuration
networking is
involved these addresses also need to be resolved promptly.

It helps but is not sufficient to just use numbers.   A secure shell connection
(ssh me at 192.168.4.24) can take fifteen seconds to connect if the lookups
to three name servers fail.   If both ends are quickly resolved the
connection can take place
in the blink of a screen refresh.

It also makes sense for the XS server to run a squid proxy server.  DHCP can be
configured so DHCP clients get the proxy server info.    The big value
of a squid
server is all the rich web content that sites serve up.   The proxy server also
places a number of critical lookups on the XS where they can be evaluated,
measured and managed.   IP filters can also firewall many problems.....

Some of this is analogous to the issues that HPC clusters
like a ROCKS or Beowulf cluster encounter.   Like an XS setup there is one
larger system that serves as a gateway and central "hub" and behind it are
many compute servers.   These clusters like a school server can be isolated
or fully connected to the internet and have the same living in isolation or
full network service connected issues and problems.


> On Fri, Jun 3, 2011 at 7:37 PM, Sameer Verma <sverma at sfsu.edu> wrote:
>> On Thu, Jun 2, 2011 at 7:32 PM, James Cameron <quozl at laptop.org> wrote:
>>> On Thu, Jun 02, 2011 at 09:50:57AM -0700, Sameer Verma wrote:
>>>> I don't know if any traffic shaping implications will affect the
>>>> school server, but in the hopes that it might, I'm copying that list
>>>> as well.


-- 

                      T o m   M i t c h e l l
                    mitch-at-niftyegg-dot-com
"My lifetime goal is to be the kind of person my dogs think I am."