Re: Fwd: tcp write performance testing

[Jon Crowcroft <Jon.Crowcroft@xxxxxxxxxxxx>]

doesn't write() on a socket have a non blocking option (e.g.
setsockopt or ioctl to do non blocking) then you get EWOULDBLOCK
if you write and the buffer is full

its nice to have either behaviour for programing (so you can block
th calling thread or not as programmer prefers)...

In missive <CANeYhgFMgQmTbP-c=AqWXfri-NiHR2YbVUL-KnCz6zySVBsc6g@xxxxxxxxxxxx
om>, Balraj Singh typed:

 >>A quick update on tcp performance after the recent code refactoring:
 >>
 >>TCP read speeds have gone down from about 1 Gb/s between VMs on the
 >>same host to about 450 Mb/s.  It looks like this is because of a flow
 >>control / pkt dispatch problem.  TCP write seems to have a more
 >>serious problem that it is sending pkts outside the available window -
 >>these pkts are dropped as expected and then the stack spends most of
 >>the time re-xmiting and recovering from the losses.  It looks like the
 >>write calls succeed instead of failing or blocking when there is no
 >>window available.
 >>
 >>So if you are using it, expect TCP to be very fragile for now.  Also
 >>it looks like DHCP is not working and there is a small race condition
 >>in ARP.
 >>
 >>Balraj
 >>

 cheers

   jon