hpn_buffer_size

[Petar Bogdanovic]

Hi,

I'm trying to figure out, why two nearly identical netbsd-6 hosts have
troubles using hpn. They are connected through a 5000 Kb/s link and the
following (not very scientific) test:

dd if=FILE bs=1m count=2 | ssh HOST dd bs=64k of=/dev/null

yields different results when defaults are in place (430KB/s) and when
HPNDisabled=yes and/or HPNBufferSize=2048 (590KB/s).

I did a diff on the -vvv output, but am not really sure how to interpret
the values:

--- hpn.default 2012-04-27 19:42:26.000000000 +0200
+++ hpn.disabled 2012-04-27 19:42:48.000000000 +0200
@@ -126,329 +126,449 @@
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
-debug2: channel 0: rcvd adjust 32768
+debug2: channel 0: rcvd adjust 131072
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
-debug2: channel 0: rcvd adjust 32768
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
-debug2: channel 0: rcvd adjust 32768
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
-debug2: channel 0: rcvd adjust 32768
(...same pattern for a while...)
+debug2: channel 0: rcvd adjust 81920
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: channel 0: rcvd adjust 81920
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: channel 0: rcvd adjust 81920
(...same pattern for a while...)
@@ -489,6 +609,6 @@
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug3: fd 2 is not O_NONBLOCK
-Transferred: sent 2104512, received 4440 bytes, in 4.9 seconds
-Bytes per second: sent 428033.4, received 903.0
+Transferred: sent 2104512, received 3192 bytes, in 3.6 seconds
+Bytes per second: sent 582904.2, received 884.1
debug1: Exit status 0


--- hpn.default 2012-04-27 19:42:26.000000000 +0200
+++ hpn.2048 2012-04-27 19:43:14.000000000 +0200
@@ -126,351 +126,645 @@
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
-debug2: channel 0: rcvd adjust 32768
+debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
-debug2: channel 0: rcvd adjust 32768
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
debug2: tcpwinsz: 33580 for connection: 5
(..............)
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: channel 0: rcvd adjust 131072
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: tcpwinsz: 33580 for connection: 5
+debug2: channel 0: rcvd adjust 131072
(..............)
@@ -489,6 +783,6 @@
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
debug3: fd 2 is not O_NONBLOCK
-Transferred: sent 2104512, received 4440 bytes, in 4.9 seconds
-Bytes per second: sent 428033.4, received 903.0
+Transferred: sent 2102624, received 2904 bytes, in 3.7 seconds
+Bytes per second: sent 573858.1, received 792.6
debug1: Exit status 0


I'm fine with disabling HPN but something tells me that hpn is supposed
to work out of the box and it took me quite a while to understand that
it wasn't $some_application 's fault so lets help those googlers..

Thanks,

Petar Bogdanovic

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by Petar Bogdanovic
Hi,
I'm trying to figure out, why two nearly identical netbsd-6 hosts have
troubles using hpn. They are connected through a 5000 Kb/s link and the
dd if=FILE bs=1m count=2 | ssh HOST dd bs=64k of=/dev/null
yields different results when defaults are in place (430KB/s) and when
HPNDisabled=yes and/or HPNBufferSize=2048 (590KB/s).

590 KB/sec on a 50000 Kb/sec link is pretty good!

It does strike me that you aren't moving enough data for measurements to
be particularly useful. The SSH negotiation will have a significant
impact.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Petar Bogdanovic]

Post by Thor Lancelot Simon
It does strike me that you aren't moving enough data for measurements to
be particularly useful. The SSH negotiation will have a significant
impact.

I tried more, FILE is a regular file (a cd-image) the results are pretty
much the same. Also not every application gets the same results. An
ssh-tunneled bacula restore for example drops down to 100-200 KB/s while
the same restore gets ~590 KB/s to a netbsd-4 / netbsd-6 host (w/o HPN)
or fantastic 60 MB/s over gigabit to a Laptop (Cipher: arcfour).

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chuck Swiger]

Post by Petar Bogdanovic
I'm trying to figure out, why two nearly identical netbsd-6 hosts have
troubles using hpn. They are connected through a 5000 Kb/s link and the
dd if=FILE bs=1m count=2 | ssh HOST dd bs=64k of=/dev/null
yields different results when defaults are in place (430KB/s) and when
HPNDisabled=yes and/or HPNBufferSize=2048 (590KB/s).

You need to increase the TCP window size to take significant advantage
of the SSH HPN changes. Take a look at the following sysctls:

kern.sbmax
net.inet.tcp.rfc1323
net.inet.tcp.recvbuf_max
net.inet.tcp.sendbuf_max
net.inet.tcp.recvspace
net.inet.tcp.sendspace

You'll also need to increase NMBCLUSTERS, unless that has become
a sysctl tunable as well...

Regards,

[Petar Bogdanovic]

Post by Chuck Swiger

Post by Petar Bogdanovic
I'm trying to figure out, why two nearly identical netbsd-6 hosts have
troubles using hpn. They are connected through a 5000 Kb/s link and the
dd if=FILE bs=1m count=2 | ssh HOST dd bs=64k of=/dev/null
yields different results when defaults are in place (430KB/s) and when
HPNDisabled=yes and/or HPNBufferSize=2048 (590KB/s).

You need to increase the TCP window size to take significant advantage
kern.sbmax
net.inet.tcp.rfc1323
net.inet.tcp.recvbuf_max
net.inet.tcp.sendbuf_max
net.inet.tcp.recvspace
net.inet.tcp.sendspace
You'll also need to increase NMBCLUSTERS, unless that has become
a sysctl tunable as well...

Thanks for the hints but I'm not sure I understand the logic behind
this. HPNDisabled=no is the default setting, and I'm not running high
powered n Gigabit-Interfaces so why should a default setting in a rather
unspectacular environment require any additional tweaking?

Or in other words: Wouldn't a HPNDisabled=yes default make more sense?

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chuck Swiger]

Post by Petar Bogdanovic

Post by Chuck Swiger
You need to increase the TCP window size to take significant advantage
kern.sbmax
net.inet.tcp.rfc1323
net.inet.tcp.recvbuf_max
net.inet.tcp.sendbuf_max
net.inet.tcp.recvspace
net.inet.tcp.sendspace
You'll also need to increase NMBCLUSTERS, unless that has become
a sysctl tunable as well...

Thanks for the hints but I'm not sure I understand the logic behind
this. HPNDisabled=no is the default setting, and I'm not running high
powered n Gigabit-Interfaces so why should a default setting in a rather
unspectacular environment require any additional tweaking?

The defaults are chosen to be reasonable for a wide range of circumstances, without consuming a lot of network buffer memory. If you have a high-speed link and want to improve performance, then the default values are not ideal. (Note that these values date back to when 10Mbs ethernet was "fast", so even a gigabit link could be improved by tuning....)

Post by Petar Bogdanovic
Or in other words: Wouldn't a HPNDisabled=yes default make more sense?

Maybe. HPN also permits some other things like a null crypto type, which is useful when you want to use SSH auth, but you don't care about encrypting the data being sent....

Regards,

[Mouse]

Maybe. HPN also permits some other things like a null crypto type, which is$

Any particular reason you're using paragraph-length lines? I'd suggest
avoiding it for normal running text like this.

HPN also permits some other things like a null crypto type, which is
useful when you want to use SSH auth, but you don't care about
encrypting the data being sent....

I'm of two minds about that. For people who actually understand the
issues and find the tradeoffs acceptable, it's convenient. But for
people who think they understand more than they actually do, it's a
nice stout piece of rope already tied into a noose.... I'm not sure
where I come down on that question. My own implementation won't use
none by default, but if you tell it to it won't give you any backtalk.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chuck Swiger]

Post by Mouse

Maybe. HPN also permits some other things like a null crypto type, which is$

Any particular reason you're using paragraph-length lines? I'd suggest
avoiding it for normal running text like this.

Yes, there are particular reasons:

http://lists.ntp.org/pipermail/questions/2011-September/030457.html

Post by Mouse

HPN also permits some other things like a null crypto type, which is
useful when you want to use SSH auth, but you don't care about
encrypting the data being sent....

I'm of two minds about that. For people who actually understand the
issues and find the tradeoffs acceptable, it's convenient. But for
people who think they understand more than they actually do, it's a
nice stout piece of rope already tied into a noose.... I'm not sure
where I come down on that question. My own implementation won't use
none by default, but if you tell it to it won't give you any backtalk.

This sounds entirely reasonable. SSH should use encryption for data by
default, but the user should be able to chose the null cipher if they like.

Regards,

[Mouse]

Post by Chuck Swiger

Post by Mouse
Any particular reason you're using paragraph-length lines?

http://lists.ntp.org/pipermail/questions/2011-September/030457.html

Quoting from that (with long-line damage manually repaired)...

Post by Chuck Swiger
$WORK obligates me to use a MUA which supports i18n well, by which I
don't mean UTF-8 and ISO-Latin-1, but various UTF-16 encodings like
Big5/GBK and ISO-2022-JP. Unfortunately, Mail.app no longer
implements the format=flowed MIME Content-type.

Then I suggest you switch to some other user agent for non-$WORK mail,
or, if your job involves writing to these lists, external-to-$WORK work
mail. Or at least insert a line break every 70 characters or so.
Using paragraph-length lines for running text substantially impairs its
readability for many people (especially on the more technical lists,
where rewrapping text not marked as rewrappable severely mangles things
like quoted dmesg output).

Post by Chuck Swiger
Feel free to file your own bug reports with Apple [...]

I am no customer of theirs and am not likely to be; they have no reason
to pay any attention whatsoever to me. I have no idea how to go about
filing a bug report with Apple and see no reason to learn, especially
since I expect it would involve things I am not willing to do (such as
giving them a nontrivial amount of information about myself that is not
relevant to the bug). In any case, I see no reason *I* should go to
any trouble to make up for *your* not only choosing to use an MTA which
doesn't know how to use perfectly good applicable standards, but then,
apparently, being unwilling to even do your readers the courtesy of
typing one extra keystroke every 70 or so to make your text more
readable.

Post by Chuck Swiger
Alternatively, one could leap ahead and use a 21st-century MUA which
wraps text.

When it's not marked as mecahnically rewrappable? In the presence of a
perfectly good spec for doing such marking? That would be - "is",
perhaps I should say, since you imply some do do it - a bug, regardless
of century. (Well, absent specific configuration to the contrary, I
suppose.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chuck Swiger]

On Apr 27, 2012, at 11:43 PM, Mouse wrote:
[ ... ]

Post by Mouse
Quoting from that (with long-line damage manually repaired)...

Post by Chuck Swiger
$WORK obligates me to use a MUA which supports i18n well, by which I
don't mean UTF-8 and ISO-Latin-1, but various UTF-16 encodings like
Big5/GBK and ISO-2022-JP. Unfortunately, Mail.app no longer
implements the format=flowed MIME Content-type.

Then I suggest you switch to some other user agent for non-$WORK mail,
or, if your job involves writing to these lists, external-to-$WORK work
mail. Or at least insert a line break every 70 characters or so.

It's simply not practical for me to switch MUAs, most of the time.

Nothing in my job involves writing to NetBSD mailing lists:
I'm a network administrator, not in Apple Developer Relations.

And yes, if I make a point of it, I can manually wrap text.

Post by Mouse
Using paragraph-length lines for running text substantially impairs its
readability for many people (especially on the more technical lists,
where rewrapping text not marked as rewrappable severely mangles things
like quoted dmesg output).

You're not saying anything here which I don't already know.

Fifteen or so years ago, I used to do GNKSA reviews:

http://www.newsreaders.com/gnksa/gnksa.txt

"14) Try to respect the 80-character line-length conventions

Any line breaks shown to the user while she is editing her article
SHOULD still be present when the article is actually posted to the Net.
The software SHOULD NOT show the user four 75-character lines while
actually posting a single 300-character line. Nor should it show the
user a series of 100-character lines while actually posting alternating
lines of 80 and 20 characters each."

...and I'm pretty sure I've got bug reports against email systems at CMU
which are old enough to drink legally.

Post by Mouse

Post by Chuck Swiger
Feel free to file your own bug reports with Apple [...]

I am no customer of theirs and am not likely to be; they have no reason
to pay any attention whatsoever to me. I have no idea how to go about
filing a bug report with Apple and see no reason to learn, especially
since I expect it would involve things I am not willing to do (such as
giving them a nontrivial amount of information about myself that is not
relevant to the bug). In any case, I see no reason *I* should go to
any trouble to make up for *your* not only choosing to use an MTA which
doesn't know how to use perfectly good applicable standards, but then,
apparently, being unwilling to even do your readers the courtesy of
typing one extra keystroke every 70 or so to make your text more
readable.

For all these words you've written in response to a year-old archive link,
your actual point is unclear.

Filing a bug report with Apple involves roughly the same level of effort
and information disclosure that filing a bug report with Bugzilla against
Thunderbird or filing a PR with NetBSD entails.

I'm pretty sure that's not a relevant point, though-- if you don't want to
read messages from me, hit spacebar, or set up a From: filter. Yet, I
suspect that's also aside from the point.

So, why such eloquent histrionic outrage about a minor matter?

[ Talk about a first-world problem. Well, some folks would complain just
because their TV remote was out of reach, yet such folks don't even recognize
just how fortunate they are to not comprehend what a real problem actually is.
Just for the record, my definition of a real problem involves learning what
happens when thousands of people burn to death. ]

Post by Mouse

Post by Chuck Swiger
Alternatively, one could leap ahead and use a 21st-century MUA which
wraps text.

When it's not marked as mecahnically rewrappable? In the presence of a
perfectly good spec for doing such marking? That would be - "is",
perhaps I should say, since you imply some do do it - a bug, regardless
of century. (Well, absent specific configuration to the contrary, I
suppose.)

Here's a decade-old unfixed bug against Mozilla Thunderbird with regard to
format=flowed:

https://bugzilla.mozilla.org/show_bug.cgi?id=199776

I suspect that describing f=f as a "perfectly good spec" is somewhere between
an optimistic perspective and a rhetorical position held for the sake of arguing.

Regards,

[Thor Lancelot Simon]

Post by Chuck Swiger
[ ... ]

Post by Mouse
Quoting from that (with long-line damage manually repaired)...

Post by Chuck Swiger
$WORK obligates me to use a MUA which supports i18n well, by which I
don't mean UTF-8 and ISO-Latin-1, but various UTF-16 encodings like
Big5/GBK and ISO-2022-JP. Unfortunately, Mail.app no longer
implements the format=flowed MIME Content-type.

Then I suggest you switch to some other user agent for non-$WORK mail,
or, if your job involves writing to these lists, external-to-$WORK work
mail. Or at least insert a line break every 70 characters or so.

It's simply not practical for me to switch MUAs, most of the time.

What if your preferred user agent made it impossible to do inline
quotations (or, at least, as hard as it is to wrap text at 80 in
Mail.app), so if you used it it was much easier to top-post? Would
you start top-posting on old Internet mailing lists, too?

At some point, you should show some respect for the cultural conventions
of the place you're visiting. Not because they're necessarily more
rational nor in some other way better (though I think there are good
arguments to be made that both hard-wrapping text and inline quotation
are, when compared to endless lines and top-posting) but because when
you want to communicate with other people, you should respect their
cultural norms. Why should everyone else have to do extra work to
interact with you? That just screams that you don't really care what
anyone else gets out of your participation in the discussion; that you're
in it just for you.

I occasionally (and regrettably) exchange email with someone who
insists on using his own made-up pronouns instead of "he" and "she";
his own silly posessives instead of "his" and "hers"; and so forth
(there's a lot of "so forth"). This makes him feel great, I'm sure,
but it stops the eye every time one scans across his sentences, disrupts
linguistic flow, and makes is slow and hard to read his text. It is
hard not to come away with the impression that a large part of his
purpose, when communicating, is to _fail_ to communicate the simple
sense of his text -- to actively annoy and impede the reader instead,
as a way of making the reader think about how great this bozo's shiny
new linguistic conventions (his made up words) are.

For a reader (and perhaps more important, respondent) using the tools
many of us traditionally use to interact here, on the NetBSD mailing lists,
500 word lines are a lot like that. They display strangely in most user
agents for character-cell terminals. They're hard to quote properly when
responding because one effectively has to reflow the text by hand. Sure,
one could quote them as 500 word lines; but that just kicks the can down
the road to the next person who might want to respond to (and, as is
polite, quote) only part of a paragraph. They basically scream "I don't
care how much work you have to do to have a conversation with me, it's
all about what _I_ have to say." Is it as bad as top-posting, where
rearranging a message into a sane order for response could take 10 minutes?
No. But it's still rude, in the same way. Or so it seems to me.

If the point is to offend -- even if only in small ways -- then
disrespect for the reader is a good strategy. And certainly you have
the right to offend other people if you want to. But if that's not your
intention, then you might want to reconsider pissing all over everyone
else when you choose how to format your text.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Gert Doering]

Hi,

On Mon, Apr 30, 2012 at 09:51:22AM -0400, Thor Lancelot Simon wrote:
[..]

Post by Thor Lancelot Simon
What if your preferred user agent made it impossible to do inline
quotations (or, at least, as hard as it is to wrap text at 80 in
Mail.app), so if you used it it was much easier to top-post? Would
you start top-posting on old Internet mailing lists, too?

[..]

while at the topic of "well-behaving on mailing lists"... reading the
From: and Subject:, I expected to be enlightened about buffer tuning
issues, high-performance SSH, and so on.

Instead I read another sermon about use of mail clients, proper
formatting, and so on - which I can agree to, but which I'm not
interested in reading.

Would you, being so wisened in the use of e-mail and human communication,
please bother to change the Subject: line accordingly, then?

thanks,

Gert Doering

[Thor Lancelot Simon]

It seems explicit that some folks in the NetBSD community want me to
leave, and I'll respect such wishes by unsubscribing from these
lists.

Explicit? I'd appreciate a quotation, then -- who has said they want
you to leave?

Personally, I'd prefer that you not leave more than I'd prefer that you
stop posting infinite paragraphs. But should that mean I am somehow not
permitted to tell you that I would like it if you'd stop posting infinite
paragraphs?

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Chuck Swiger]

Post by Gert Doering
[..]

Post by Thor Lancelot Simon
What if your preferred user agent made it impossible to do inline
quotations (or, at least, as hard as it is to wrap text at 80 in
Mail.app), so if you used it it was much easier to top-post? Would
you start top-posting on old Internet mailing lists, too?

[..]
while at the topic of "well-behaving on mailing lists"... reading the
From: and Subject:, I expected to be enlightened about buffer tuning
issues, high-performance SSH, and so on.

Absolutely-- talking about SSH HPN and network tuning sysctls had been my
original intent.

Post by Gert Doering
Instead I read another sermon about use of mail clients, proper
formatting, and so on - which I can agree to, but which I'm not
interested in reading.
Would you, being so wisened in the use of e-mail and human communication,
please bother to change the Subject: line accordingly, then?

As I've said before, and to an individual CC:ed here: "Many folks are more apt
to fault others than they are to fault themselves for the same error."

Well, Thor and Mouse, feel free to keep throwing stones if you like:
"though boys throw stones at the frogs in sport, the frogs die in earnest."

It seems explicit that some folks in the NetBSD community want me to leave,
and I'll respect such wishes by unsubscribing from these lists.

So long, and thanks for all the fish...

Regards,

[Mouse]

It seems explicit that some folks in the NetBSD community want me to
leave, and I'll respect such wishes by unsubscribing from these
lists.

It could be true. But I don't think I'm part of that "some folks"; I
certainly did not intend to say any such thing.

If it comes down to a choice of having you here with paragraph-sized
lines or having you gone...I see arguments each way and don't know
which side I come down on; perhaps fortunately, I don't think I need to
figure that out, because it's not my choice to make. I don't run the
list and most certainly don't run NetBSD.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by Petar Bogdanovic
Hi,
I'm trying to figure out, why two nearly identical netbsd-6 hosts have
troubles using hpn. They are connected through a 5000 Kb/s link and the
dd if=FILE bs=1m count=2 | ssh HOST dd bs=64k of=/dev/null
yields different results when defaults are in place (430KB/s) and when
HPNDisabled=yes and/or HPNBufferSize=2048 (590KB/s).

I do think you need to test with larger files. But the other thing that
occurs to me is that you're now using a kernel that automatically sizes
the TCP socket buffers; HPN has a tunable that needs to be set right if
this is the case (RcvBufferPolling? Something like that.) which you
might want to investigate.

In fact, I think I'd first make sure it were set appropriately for a
kernel that _does_ auto-size the socket buffers, then try setting it
the other way and using systctl to set the socket buffer sizes by hand
(you will need to do this on *both* ends and restart the ssh daemon
process after each of these changes) to see whether the problem is either
A) HPN not playing nice with our socket buffer autosizing code due to wrong
default settings, or perhaps B) our socket buffer autosizing code being
broken.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de