10 messages in net.launchpad.lists.openstackRe: [Openstack] Performance metrics| From | Sent On | Attachments |
|---|---|---|
| Neelakantam Gaddam | Jun 20, 2012 5:56 am | |
| Dan Wendlandt | Jun 20, 2012 6:24 am | |
| Sandy Walsh | Jun 20, 2012 6:54 am | |
| Rick Jones | Jun 20, 2012 9:35 am | |
| Huang Zhiteng | Jun 20, 2012 8:08 pm | |
| Rick Jones | Jun 21, 2012 9:16 am | |
| Narayan Desai | Jun 21, 2012 12:40 pm | |
| Rick Jones | Jun 21, 2012 2:20 pm | |
| Narayan Desai | Jun 21, 2012 7:05 pm | |
| Rick Jones | Jun 29, 2012 2:35 pm |
| Subject: | Re: [Openstack] Performance metrics | |
|---|---|---|
| From: | Narayan Desai (nara...@gmail.com) | |
| Date: | Jun 21, 2012 7:05:46 pm | |
| List: | net.launchpad.lists.openstack | |
On Thu, Jun 21, 2012 at 4:21 PM, Rick Jones <rick...@hp.com> wrote:
TSO and GRO can cover a multitude of path-length sins :)
Along with a 64 MB TCP window ;)
That is one of the reasons netperf does more than just bulk transfer :) When I was/am measuring "scaling" of an SMP node I would use aggregate, burst-mode, single-byte netperf TCP_RR tests to maximize the packets per second while minimizing the actual bandwidth consumed.
Yeah, for a completely random workload pps is the limiting factor. We're lucky in that our primary high bandwidth use case is wide area data transfer where we can fill our jumbo packets. (kudos to the nova folks on that count; we were completely able to configure jumbo frames without having to hack anything up)
We were actually more thrilled to be able to build relatively fat single streams, due to our workload. -nld
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : open...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp