Re: tcp write performance testing

[Jon Crowcroft <Jon.Crowcroft@xxxxxxxxxxxx>]

suite:)

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

 >>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 =3D write fd page1 in
 >>let y =3D write fd page2 in
 >>x <&> y
 >>
 >>serial:
 >>
 >>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 =
 >>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
 >>>=20
 >>> its nice to have either behaviour for programing (so you can block
 >>> th calling thread or not as programmer prefers)...
 >>>=20
 >>> In missive =
 >><CANeYhgFMgQmTbP-c=3DAqWXfri-NiHR2YbVUL-KnCz6zySVBsc6g@xxxxxxxxxxxx
 >>> om>, Balraj Singh typed:
 >>>=20
 >>>>> A quick update on tcp performance after the recent code refactoring:
 >>>>>=20
 >>>>> 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.
 >>>>>=20
 >>>>> 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.
 >>>>>=20
 >>>>> Balraj
 >>>>>=20
 >>>=20
 >>> cheers
 >>>=20
 >>>   jon
 >>>=20
 >>>=20
 >>

 cheers

   jon