Re: tcp write performance testing

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

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.

parallel:

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

serial:

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:
http://www.openmirage.org/wiki/tutorial-lwt

-anil

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
> 
>