[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tcp write performance testing

Yeah; we don't need separate versions in Mirage since the blocking thread
can be manipulated as a first-class value, and composed and joined separately.


let x = write fd page1 in
let y = write fd page2 in
x <&> y


lwt x = write fd page1 in
lwt y = write fd page2 in

The type of the thread contains an 'Lwt.t' while it's potentially blocking,
and you have to pass it through a yield point before you can get the value
out.  More on lightweight threads at:


On 12 Jul 2012, at 07:23, Jon Crowcroft wrote:

> 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.