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.
Well, a wise old engineer tried to teach me that the proper spelling is
ass-u-me :) so just for grins, you might try the TCP_RR test anyway :) And
even if your application is correct (although I wonder why the receiver
isn't sucking data-out very quickly...) if you can reproduce the problem
with netperf it will be easier for others to do so.
My application is only the server, the receiver is smbget from Samba, so
I don't feel responsible for it :-)
Might want to strace it anyway... no good deed (such as reporting a potential
issue) goes unpunished :)
Still, when run over Ethernet, it works fine without waiting for
timeouts to expire.
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 mtu to 1500 a very interesting
experiment.
To reproduce this:
- smbget is from samba, you probably already have this
- gatling (my server) can be gotten from
cvs -d :pserver:[email protected]:/cvs -z9 co dietlibc libowfat gatling
dietlibc is not strictly needed, but it's my environment.
First built dietlibc, then libowfat, then gatling.
Felix
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
