;)
--variable VARIABLE specify the variable(s) to include, can be repeated
--prefix PREFIX add a prefix to all variable names
rick jones
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscrib
n the cumulative
time for successive retransmissions of TCP SYNs was completely wrong - 3
+ 6 + 12 isn't 17, but 21... :)
rick
Thanks
Klaus
-Ursprüngliche Nachricht-
Von: Rick Jones [mailto:rick.jon...@hp.com]
Gesendet: Freitag, 31. Mai 2013 19:17
An: Klaus Schürmann
Cc:
On 05/31/2013 04:55 AM, Klaus Schürmann wrote:
May 31 10:33:08 swift-proxy1 proxy-logging 10.4.2.99 10.4.2.99
31/May/2013/08/33/08 GET /v1/AUTH_provider1/129450/829188397.31 HTTP/1.0 200 -
Wget/1.12%20%28linux-gnu%29 provider1%2CAUTH_tke6408efec4b2439091fb6f4e75911602
- 283354 - txd4a3a4bf3f38
:
...
Can someone explain such behavior?
I'm sure others will suggest storage things to check. Being a
networking type, I will suggest looking into TCP retransmissions.
Netstat -s commands can be helpful there. On your client, the proxy and
perhaps even your object server(s).
rick
rking at a distance" - perhaps something else in the realm of
quantum physics?
rick jones
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More
iperf. It seems unlikely that the
network could retain a "memory" of a previous transfer to cause a
subsequent, non-overlapping transfer to run more slowly.
The logs on the compute node(s) will show how long it took to actually
retrieve the image yes?
utilized CPU during a test, in addition to reporting the overall CPU
utilization.
rick jones
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
ith the glance/controller node. Take some snapshots over an
interval in each case and run them through something like beforeafter:
netstat -s > before
...wait a defined/consistent moment...
netstat -s > after
beforeafter before after > delta
and go from there.
rick jo
and go from there. I'm guessing your tests are all bulk-transfer - you
might want to consider adding some latency and/or aggregate small-packet
performance tests.
happy benchmarking,
rick jones
the applicability varies, but attached is some boilerplate I've
built-up over time, on th
agram Too Big
messages through. It is perhaps my failing, but I fail to see how
blocking them improves "security."
rick jones
adde parvum parvo magnus acervus erit - Ovid quoted in The Mythical Man
Month
___
Mailing list: https://launchpa
On 03/08/2013 11:49 AM, Aaron Rosen wrote:
Hi Rick,
You are right. I just ran curl to test for myself and it does set the
DF bit. Why is this? Any ideas why it specifies that the packet cannot
be fragmented?
Because most, if not virtually all TCP stacks going back to the mid
1990s (RFC 1191 i
eing ignored?
Only changing the VM MTU to 1454 does the trick ('ifconfig eth0 mtu 1454').
For info, 192.168.10.3 is the floating IP bound to 10.0.0.4 (private IP).
I suppose if 10.0.0.4 doesn't explicitly know about 192.168.10.3 it
might indeed ignore the ICMP message. As
lost,
that's it, and the CLOSE_WAIT may remain forever.
Again though, given the rarity of actual application use of a simplex
TCP connection, 99 times out of 10, seeing lots of CLOSE_WAIT
connections building-up implies a buggy application or the libraries
doing work on its behalf.
r
-only ability by default and can oversubscribe the
compute node the instance goes on.
Will it use the same /var/lib/nova/sch_hosts/ mechanism to allow
mere mortals to use it like the onhost stuff did?
thanks,
rick
Best,
-jay
On 12/27/2012 02:45 PM, Rick Jones wrote:
Does the convention of a
Does the convention of adding --onhost--computenodename to the instance
name being created still work?
rick jones
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net
ld
have expected - 2650163744.
FWIW, that there was a SYN-ACK sent in response to the SYN in the first
place suggests that 10.0.41.3 received what it thought was a properly
checksummed SYN segment. All the more reason I suspect to take traces
at both ends and compare the packets byte by byte.
catch the
error with strace, if it works on ARM.
Strace is your friend even if he is sometimes a bit on the chatty side.
It looks as though there is at least some support for ARM if
http://packages.debian.org/search?keywords=strace is any indication.
rick jones
tness
alogrithms/heuristics. And disabling it suggests an opportunity to tune
an application for better performance.
rick jones
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe :
nto/out-of the F5 (cluster of F5's?) and how
utilized is that pipe already? If it is running at anything more than
2.5% (5000/20) to 5.5% (5000/9) in the direction the GETS will
flow it will become a bottleneck. (handwaving it as 100% GETS rather
than 90%)
rick jones
Today, w
with a value of zero can, sometimes, confuse
beforeafter if a stat appears in after that was not present in before.)
It might not be a bad idea to include ethtool -S statistics from each of
the interfaces in that procedure as well.
rick jones
probably a good idea to mention the bonding mode
questions.
Btw , how could I flush the memory of arp_cache which using by XFS(SWIFT)?
You can use the classic "arp" command to manipulate the ARP cache. It
can also show you how many entries there are. I suspect that a web
search on "linux flush arp cache" may yield some h
On 06/21/2012 02:21 PM, Rick Jones wrote:
TSO and GRO can cover a multitude of path-length sins :)
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_R
R test but each transaction is a
freshly created and torn-down TCP connection.
happy benchmarking,
rick jones
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/
On 06/20/2012 08:09 PM, Huang Zhiteng wrote:
On Thu, Jun 21, 2012 at 12:36 AM, Rick Jones wrote:
I do not have numbers I can share, but do have an interest in discussing
methodology for evaluating "scaling" particularly as regards to
"networking." My initial thoughts are
rigors
of netperf workloads it will probably scale well under "real" workloads.
Such scaling under netperf may not be necessary, but it should be
sufficient.
happy benchmarking,
rick jones
___
Mailing list: https://launchpad.net/~openstack
arrived off the wire, and when the response was
sent (queued to the driver at least).
Caveat - you should not try to do math between absolute timestamps on
the client and on the server unless you know that the two systems have
really, Really, REALLY well synchronized clocks...
rick jones
htt
bers of an
instance-local range of ports being opened. Some verbiage about that
might be goodness.
Also the example description for adding port 22 is incomplete - it isn't
allowing tcp traffic traffic generally. It is allowing ssh/scp traffic
specifically
hope that helps,
rick jones
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
wouldn't be minutes, but it could
add up a bit I suppose.
rick jones
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
anual
for the current top-of-trunk version of netperf is at:
http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html
and the top-of-trunk bits can be pulled via subversion pointing at
http://www.netperf.org/svn/netperf2/trunk
happy benchmarking,
rick jones
For example, between a pair of Ub
29 matches
Mail list logo
