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

Re: tcp write performance testing


In missive <04001E80-7334-4B56-86A2-1FBE8C08E8EF@xxxxxxxxxx>, Anil Madhavapeddy

 >>Yeah; we don't need separate versions in Mirage since the blocking =
 >>can be manipulated as a first-class value, and composed and joined =
 >>let x =3D write fd page1 in
 >>let y =3D write fd page2 in
 >>x <&> y
 >>lwt x =3D write fd page1 in
 >>lwt y =3D write fd page2 in
 >>The type of the thread contains an 'Lwt.t' while it's potentially =
 >>and you have to pass it through a yield point before you can get the =
 >>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 =
 >>> 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 =
 >>>>> 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 =
 >>>>> 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 =
 >>>>> in ARP.
 >>>>> Balraj
 >>> cheers
 >>>   jon





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