On 08/31/2016 04:11 PM, Eric Dumazet wrote:
On Wed, 2016-08-31 at 15:47 -0700, Rick Jones wrote:
With regard to drops, are both of you sure you're using the same socket
buffer sizes?
Does it really matter ?
At least at points in the past I have seen different drop counts at the
SO_R
With regard to drops, are both of you sure you're using the same socket
buffer sizes?
In the meantime, is anything interesting happening with TCP_RR or
TCP_STREAM?
happy benchmarking,
rick jones
problematic
since it takes up server resources for sockets sitting in TCP_CLOSE_WAIT.
Isn't the server application expected to act on the read return of zero
(which is supposed to be) triggered by the receipt of the FIN segment?
rick jones
We are also in the process of contacting Appl
onnection
which has been reset? Is it limited to those errno values listed in the
read() manpage, or does it end-up getting an errno value from those
listed in the recv() manpage? Or, perhaps even one not (presently)
listed in either?
rick jones
On 06/02/2016 10:06 AM, Aaron Conole wrote:
Rick Jones writes:
One of the things I've been doing has been setting-up a cluster
(OpenStack) with JumboFrames, and then setting MTUs on instance vNICs
by hand to measure different MTU sizes. It would be a shame if such a
thing were not possib
may add more thorough
error handling.
How do you see this interacting with VMs getting MTU settings via DHCP?
rick jones
v2:
* Whitespace and code style cleanups from Sergei Shtylyov and Paolo Abeni
* Additional test before printing a warning
Aaron Conole (2):
virtio: Start feature MTU
R and even aggregate _RR/packets per second for many VMs on
the same system would be in order.
happy benchmarking,
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at ht
return an error and report the
required size to hold the data.
Is there any chapter and verse on whether a "failed" getsockopt() may
alter the items passed to it?
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On 04/15/2015 11:32 AM, Eric Dumazet wrote:
On Wed, 2015-04-15 at 11:19 -0700, Rick Jones wrote:
Well, I'm not sure that it is George and Jonathan themselves who don't
want to change a sysctl, but the customers who would have to tweak that
in their VMs?
Keep in mind some VM use
On 04/15/2015 11:08 AM, Eric Dumazet wrote:
On Wed, 2015-04-15 at 10:55 -0700, Rick Jones wrote:
Have you tested this patch on a NIC without GSO/TSO ?
This would allow more than 500 packets for a single flow.
Hello bufferbloat.
Woudln't the fq_codel qdisc on that interface address
Have you tested this patch on a NIC without GSO/TSO ?
This would allow more than 500 packets for a single flow.
Hello bufferbloat.
Woudln't the fq_codel qdisc on that interface address that problem?
rick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Strange thing is that sender does not misbehave at the beginning when
receiver window is still small. Only after a while.
Just guessing, but when the receiver window is small, the sender cannot
get a large quantity of data out there at once, so any string of lost
packets will tend to be smal
On 01/06/2015 11:16 AM, Rick Jones wrote:
I'm assuming one incident starts at XX:41:24.748265 in the trace? That
does look like it is slowly slogging its way through a bunch of lost
traffic, which was I think part of the problem I was seeing with the
middlebox I stepped in, but I don'
re I would
have expected it. Still, it looks like the sender has an increasing TCP
RTO as it is going through the slog (as it likely must since there are
no TCP timestamps?), to the point it gets larger than I'm guessing curl
was willing to wait, so the FIN at XX:41:53.269534 after a ten s
heduling issues/questions, but can ask if you
tried binding netserver to a CPU other than the one servicing the
interrupts via the -T option on the netperf command line:
netperf -T , ...
http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#index-g_t_002dT_002c-Global-41
happy benchnmar
pushed up the stack.
happy benchmarking,
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-I 99,. A width of 5% is what
gives the +/- 2.5% (and/or demonstrates my lack of accurate statistics
knowledge :) )
happy benchmarking,
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.or
c functions. The entirety of their functionality will likely
consist of a single userspace program; they might not even have a PID 2.
*That's* the kind of "embedded" we're talking about, not the
supercomputers we carry around in our pockets.
Would this be some sort of "Interne
ill, even armed with that information, tracking down the regression or
regressions will be no small feat particularly since the timespan is so
long. A very good reason to be trying the newer versions as they
appear, even if only briefly, rather than leaving it for so long.
happy benchmarkin
htons(43012), sin_addr=inet_addr("0.
0.0.0")}, 16) = -1 EADDRINUSE (Address already in use)
The output of netstat -an didn't by any chance happen to still show an
endpoint in the LISTEN state for that port number did it?
rick jones
--
To unsubscribe from this list: send the lin
ng.
Am I correct in assuming this is a mechanism which would not be used in
a high aggregate PPS situation?
happy benchmarking,
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
On 01/24/2013 04:22 AM, Leandro Lucarella wrote:
On Wed, Jan 23, 2013 at 11:28:08AM -0800, Rick Jones wrote:
Then if syncookies are enabled, the time spent in connect() shouldn't be
bigger than 3 seconds even if SYNs are being "dropped" by listen, right?
Do you mean
On 01/23/2013 02:47 AM, Leandro Lucarella wrote:
Thanks for the info. I'm definitely dropping SYNs and sending cookies,
around 50/s. Is there any way to tell how many connections are queued in
a particular socket?
I am not familiar with one. Doesn't mean there isn't one, only that I
am not ab
On 01/22/2013 10:42 AM, Leandro Lucarella wrote:
On Tue, Jan 22, 2013 at 10:17:50AM -0800, Rick Jones wrote:
What is important is the backlog, and I guess you didn't increase it
properly. The somaxconn default is quite low (128)
Leandro -
If that is being overflowed, I believe you shou
the kernel and put a
"timestamp offset" on a socket.
Is there a chance a connection can be moved more than once within the
"lifetime" of a given timestamp value?
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
What is important is the backlog, and I guess you didn't increase it
properly. The somaxconn default is quite low (128)
Leandro -
If that is being overflowed, I believe you should be seeing something like:
14 SYNs to LISTEN sockets dropped
in the output of netstat -s on the system on wh
re:
... -- -k
RT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY
Additional information about how the omni output selectors work can be
found at
http://www.netperf.org/svn/netperf2/trunk/doc/netperf.html#Omni-Output-Selection
happy benchmarki
rrent sessions from 10?
rick jones
Netperf Local VM to VM test:
- VM1 and its vcpu/vhost thread in numa node 0
- VM2 and its vcpu/vhost thread in numa node 1
- a script is used to lauch the netperf with demo mode and do the postprocessing
to measure the aggreagte result with the help of time
On 10/03/2012 02:47 AM, Mel Gorman wrote:
On Tue, Oct 02, 2012 at 03:48:57PM -0700, Rick Jones wrote:
On 10/02/2012 01:45 AM, Mel Gorman wrote:
SIZE=64
taskset -c 0 netserver
taskset -c 1 netperf -t UDP_STREAM -i 50,6 -I 99,1 -l 20 -H 127.0.0.1 -- -P
15895 -s 32768 -S 32768 -m $SIZE -M $SIZE
ot; will be silently truncated to 30.
happy benchmarking,
rick jones
PS - I trust it is the receive-side throughput being reported/used with
UDP_STREAM :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.or
e
variables into three - what netperf's user requested via the command
line, what it was right after the socket was created, and what it was at
the end of the data phase of the test.
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On 07/08/2012 08:23 PM, Jason Wang wrote:
On 07/07/2012 12:23 AM, Rick Jones wrote:
On 07/06/2012 12:42 AM, Jason Wang wrote:
Which mechanism to address skew error? The netperf manual describes
more than one:
This mechanism is missed in my test, I would add them to my test scripts.
http
f dealing
with skew error)
A single instance TCP_RR test would help confirm/refute any
non-trivial change in (effective) path length between the two cases.
Yes, I would test this thanks.
Excellent.
happy benchmarking,
rick jones
--
To unsubscribe from this list: send the line "unsubsc
r upgrading.
happy benchmarking,
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-i option to set the confidence iteration count will silently cap
the max at 30.
happy benchmarking,
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
een processed on both CPUs at
various points in the past, it doesn't necessarily mean that they are
being processed on both CPUs at the same time right?
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
he message length with a normal read/recv, and then read that many
bytes in the next call?
rick jones
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.
Could the corruption be seen in a tcpdump trace prior to transmission
(ie taken on the sender) or was it only seen after the data passed out
the NIC?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
Adrian Bunk wrote:
On Tue, Nov 27, 2007 at 01:15:23PM -0800, Rick Jones wrote:
The real problem is that these drivers are not in the upstream kernel.
Are there common reasons why these drivers are not upstream?
One might be that upstream has not accepted them. Anything doing or
smelling
The real problem is that these drivers are not in the upstream kernel.
Are there common reasons why these drivers are not upstream?
One might be that upstream has not accepted them. Anything doing or
smelling of TOE comes to mind right away.
rick jones
-
To unsubscribe from this list: send
f what MACs were installed in which slot, which
slot is associated with a given ethN. Having the end-user slot ID
visible is then going to be a great help to that poor admin who is doing
the install.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Felix von Leitner wrote:
Thus spake Rick Jones ([EMAIL PROTECTED]):
Past performance is no guarantee of current correctness :) And over an
Ethernet, there will be a very different set of both timings and TCP
segment sizes compared to loopback.
My guess is that you will find setting the lo
Felix von Leitner wrote:
Thus spake Rick Jones ([EMAIL PROTECTED]):
Oh I'm pretty sure it's not my application, because my application performs
well over ethernet, which is after all its purpose. Also I see the
write, the TCP uncork, then a pause, and then the packet leaving.
We
Felix von Leitner wrote:
Thus spake Rick Jones ([EMAIL PROTECTED]):
How could I test this theory?
Can you take another trace that isn't so "cooked?" One that just sticks
with TCP-level and below stuff?
Sorry for taking so long. Here is a tcpdump. The side on port 445 is
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
I'll try to go pester folks in tcpdump-workers then.
The thing to check is "TP_STATUS_CSUMNOTREADY".
When using mmap(), it will be provided in the descriptor. When using
recvmsg() it will be provided via a P
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 01 Nov 2007 14:48:45 -0700
One could I suppose try to ammend the information passed to allow
tcpdump to say "oh, this was a tx packet on the same machine on
which I am tracing so don't worry about checksum mi
t too since the IP length of
those was 0, but IIRC we got that patched to use the length of zero as a "ah,
this was TSO so wing it" heuristic.)
rick jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
LSAPIC tlb_flush
253:586255449315448982
497702 LSAPIC resched
254:123162161166168154
109 140 LSAPIC IPI
ERR: 0
it appears as eth6.
rick jones
...
is at the mercy of sysctls. I wonder if it would be
better to have it use their FORCE versions to make life easier on the
benchmarker - such as myself - who has an unfortunate habit of forgetting to
update sysctl.conf :)
rick jones
-
To unsubscribe from this list: send the line "unsubs
ory starts so this probably isn't a latent bug.
Although it does rather sound like a driver writer yanking the rope from the
hand's of the sysadmin and hanging him with it rather than letting the sysadmin
do it himself. I've seen other drivers' README's suggesti
ot; or the receiver rather than the
sender would be a good thing, and trying again with CKO disabled on the
interface(s) (via ethtool) might be something worth looking at. Ultimately,
doing the partial checksum modificiations in a CKO-friendly manner might be a
good thing.
rick jones
-
To u
you
cna also switch the output of a TCP_RR test to bits or bytes per second a la the
_STREAM tests.
rick jones
My initial idea was that it has something todo with the different MTU on
loopback. My initial block size was 16k, but the problem stayed when I
changed it to 64k.
Felix
-
To unsubsc
the packet trace was a bit too cooked perhaps, but there were indications that
at times the TCP window was going to zero - perhaps something with window
updates or persist timers?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
us places (stacks) as an "accepted" broadcast IP
in the receive path, but not the send path for quite possibly decades now.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
slightly lower than the value used by the e1000 driver, so it seems
like a safe upper limit.
FWIW the OFED 1.2 bits take the MTU of IPoIB up to 65520 bytes :)
rick jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
. The "send a request, wait for reply, send next request, etc etc
etc" is a rather common application behaviour afterall.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
% in the second.
So, in broad handwaving terms, TSO increased the per-transaction service demand
by something along the lines of (23.27 - 17.67)/17.67 or ~30% and the
transaction rate decreased by ~6%.
rick jones
bitrate blindless is a constant concern
-
To unsubscribe from this list: send th
nk there is any issue. The knob is there via
ethtool for people who really want to disable it.
Just to be paranoid (who me?) we are then at a point where what happened
a couple months ago with forwarding between 10G and IPoIB won't happen
again - where things failed because a 10G NIC had LRO
ignored.
(i.e. a list of 5 strings is returned, but bit 24 is set)
Is that to enable "hidden" bits? If not I'd think that emitting some
sort of "UNKNOWN_FLAG" might help flush-out little oopses like
forgetting a string.
rick jones
-
To unsubscribe from this list: s
s. If the delay
there starts to match the delay as you go out to the right on the graph
it would suggest that it is indeed cache effects.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
packets queued
What implications does c have for something like tcpdump?
rick jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
w IGMP packets to be received back on any port
in the logical aggregation.
IMO, the switch behavior in this case seems questionable.
FWIW,
rick jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
tack does :) It is also a floor wax, AND a
dessert topping!-)
rick jones
--
ftp://ftp.cup.hp.com/dist/networking/misc/rachel/
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, OR post, but please do NOT do BOTH...
my email address is raj in the cup.hp.com domain
blasting 300MBit of tcp unrestricted)
>
> TCP _requires_ the remote end ack every 2nd frame regardless of progress.
um, I thought the spec says that ACK every 2nd segment is a SHOULD not a
MUST?
rick jones
--
ftp://ftp.cup.hp.com/dist/networking/misc/rachel/
these opinions are mine, all
robably a bug.
A TCP _is_ free to drop data prior to sending an ACK - it simply drops
it and does not ACK it.
rick jones
--
ftp://ftp.cup.hp.com/dist/networking/misc/rachel/
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, OR post, but please do NOT do BO
the TCP code should be "honouring" the link-local MTU in its selection
of MSS.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
h mtu lower 576 is not full functional.
I thought that the specs said that 576 was the "minimum maximum"
reassemblable IP datagram size and not a minimum MTU.
rick jones
--
ftp://ftp.cup.hp.com/dist/networking/misc/rachel/
these opinions are mine, all mine; HP might not want them anyway
> > As time marches on, the orders of magnitude of the constants may change,
> > but basic concepts still remain, and the "lessons" learned in the past
> > by one generation tend to get relearned in the next :) for example -
> > there is no such a thing as a free lunch... :)
>
> ;->
> BTW, i am r
it from achieving link-rate?
One way to try and deduce that would be to meld some of the SG and preSG
behaviours and copy packets into varying numbers of buffers per packet
and measure the resulting impact on throughput through the NIC.
rick jones
As time marches on, the orders of magnitude of t
based on Alteon?
How does ZC/SG change the nature of the packets presented to the NIC?
How well does the NIC do with that changed nature?
rick jones
sometimes, performance tuning is like squeezing a balloon. one part gets
smaller, but then you start to see the rest of the balloon...
--
ftp://f
) you get a
very nice synergistic effect once the last "access" of data is removed.
CKO gets you say 10%, avoiding the copy gets you say 10%, but doing both
at the same time gets you 30%.
rick jones
http://www.netperf.org/
--
ftp://ftp.cup.hp.com/dist/networking/misc/rachel/
these opinions are mi
l author to check these bits.
I thought that most firewalls were supposed to be insanely paranoid.
Perhaps it would be considered a possible covert data channel, as
farfecthed as that may sound.
rick jones
--
ftp://ftp.cup.hp.com/dist/networking/misc/rachel/
these opinions are mine, all mine;
here would be more than
two requests. Without the explicit (cork et al)/implicit (tcpnodely)
push at the client those 2-N requests will pile-up into a nice sized TCP
segment. Those requests will arrive en-mass at the server and will then
have RTT issues ammortized.
rick jones
--
ftp://ftp.cup.hp.com/dis
ose coded software anyhow and not a
random CGI dribbler. In that sense, the "logically associated data" are
all the server's URL's from that page. Yes, this paragraph is in slight
contradiction with my statement above about keeping things queued in the
client :)
rick jones
--
ft
dean gaudet wrote:
>
> On Wed, 17 Jan 2001, Rick Jones wrote:
>
> > > actually the problem isn't nagle... nagle needs to be turned off for
> > > efficient servers anyhow.
> >
> > i'm not sure I follow that. could you expand on that a bit?
>
Olivier Galibert wrote:
>
> On Thu, Jan 18, 2001 at 10:04:28PM +0100, Andrea Arcangeli wrote:
> > NAGLE algorithm is only one, CORK algorithm is another different algorithm. So
> > probably it would be not appropriate to mix CORK and NAGLE under the name
> > "CONTROL_NAGLING", but certainly I agr
[EMAIL PROTECTED] wrote:
>
> Hello!
>
> > So if I understand all this correctly...
> >
> > The difference in ACK generation
>
> CORK does not affect receive direction and, hence, ACK geneartion.
I was asking how the semantics of cork interacted with piggybacking
ACK's on data flowing the othe
much throughput, i
suspect it would not only be designed with 64/66 busses (or better), but
also have things on several different busses. that makes device to
device life more of a challenge.
rick jones
--
ftp://ftp.cup.hp.com/dist/networking/misc/rachel/
these opinions are mine, all mine; HP m
Linus Torvalds wrote:
> Remember the UNIX philosophy: everything is a file.
...and a file is simply a stream of bytes (iirc?)
rick jones
--
ftp://ftp.cup.hp.com/dist/networking/misc/rachel/
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, OR post,
Ingo Molnar wrote:
>
> On Wed, 17 Jan 2001, Rick Jones wrote:
>
> > i'd heard interesting generalities but no specifics. for instance,
> > when the send is small, does TCP wait exclusively for the app to
> > flush, or is there an "if all else fails"
Andi Kleen wrote:
>
> On Wed, Jan 17, 2001 at 02:17:36PM -0800, Rick Jones wrote:
> > How does CORKing interact with ACK generation? In particular how it
> > might interact with (or rather possibly induce) standalone ACKs?
>
> It doesn't change the ACK generation.
Linus Torvalds wrote:
>
> On Wed, 17 Jan 2001, Rick Jones wrote:
> >
> > > The fact that I understand _why_ it is done that way doesn't mean that I
> > > don't think it's a hack. It doesn't allow you to sendfile multiple files
> > >
how low is the system call overhead to check for the next request before
you flush?
(i'm not sure that I'd say HP-UX sendfile() was a combination of system
calls - i'd probably say it was a (partial) replacement for writev())
rick jones
--
ftp://ftp.cup.hp.com/dist/networking/misc/
ot sure, but I think I've just been insulted !-) (in case it is not
clear, that is meant as a joke...)
rick jones
--
ftp://ftp.cup.hp.com/dist/networking/misc/rachel/
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to email, OR post, but please do NOT do BOTH...
> : show that they were stupid and clueless by the things they brag about).
> :
> : Oh, well. Not everybody can be as goodlooking as me. It's a curse.
nor it would seem, as humble :)
Hello Linus, my name is Rick Jones. I am the person at Hewlett-Packard
who drafted the "so _
85 matches
Mail list logo
