Re: Bug in make setting wrong MAKESYSPATH

[Ngie Cooper]

On Sun, May 21, 2017 at 1:54 AM, Thomas Mueller  wrote:
> I tried building ports, starting with ports-mgmt/synth, on HEAD (12-current) 
> and ran into difficulties with syntax error in bsd.compiler.mk .
>
> With PORTSDIR on another partition, mounted as /BETA1, I got these errors, 
> but not when I null-mounted /BETA1/usr/ports as /usr/ports.
>
> I shouldn't have to resort to this kludge, didn't have to in the recent past.
>
> This bug shows in both 11.0-STABLE and 12.0-CURRENT.
>
> I looked into "man make" and found that make got the wrong path for 
> MAKESYSPATH, setting to /BETA1/usr/share/mk instead of what it should be, 
> /usr/share/mk .
>
> Going into /BETA1/usr/ports/archivers/zip (for a short and simple example),
> make all-depends-list   produced
>
> sh: Syntax error: ")" unexpected
> make: "/BETA1/usr/share/mk/bsd.compiler.mk" line 52: warning: "echo 4.0.0 
> 4.0.0) | awk -F. '{print $1 * 1 + $2 * 100 + $3;}'" returned non-zero 
> status
> sh: Syntax error: ")" unexpected
> make[1]: "/BETA1/usr/share/mk/bsd.compiler.mk" line 52: warning: "echo 4.0.0 
> 4.0.0) | awk -F. '{print $1 * 1 + $2 * 100 + $3;}'" returned non-zero 
> status
> /BETA1/usr/ports/ports-mgmt/pkg
>
> make -m /usr/share/mk all-depends-list produces
> /BETA1/usr/ports/ports-mgmt/pkg
>
> This looks like a bug that ought to be fixed, though there is a workaround 
> using "make -m /usr/share/mk ..." every time, or presumably, setting
> MAKESYSPATH=/usr/share/mk
> in the environment.
>
> Should I file a bug report?
>
> I could get much more verbose outputs when there are more dependencies, such 
> as in /BETA1/usr/ports/ports-mgmt/synth, or more so,
> /BETA1/usr/ports/www/seamonkey
>
> I also noticed that in newer versions of FreeBSD, 
> /usr/share/mk/bsd.compiler.mk has greatly increased in size (not a bug. 
> except when "make" goes to the wrong MAKESYSPATH.
>
> Maybe add in .cshrc and .profile
> MAKESYSPATH=/usr/share/mk
> ?

Hi Tom,

make isn't at fault here as much as there's something else leaking
bsd.compiler.mk into the ports build. That's not supposed to happen.

Are you including any bsd.*.mk or src.*.mk files from /etc/make.conf ,
/etc/src.conf , etc?

Cheers,
-Ngie
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Bug in make setting wrong MAKESYSPATH

[Simon J. Gerraty]

Thomas Mueller  wrote:

> I tried building ports, starting with ports-mgmt/synth, on HEAD
> (12-current) and ran into difficulties with syntax error in
> bsd.compiler.mk .
> 
> With PORTSDIR on another partition, mounted as /BETA1, I got these
> errors, but not when I null-mounted /BETA1/usr/ports as /usr/ports.
> 
> I shouldn't have to resort to this kludge, didn't have to in the
> recent past.

The default value for MAKESYSPATH is ".../share/mk:/usr/share/mk" which
is geared to building src/, there was some to and fro over that value
when we first started using bmake, but that's what we settled on.

Presumably /BETA1/usr/share/mk exists?
If so, it will be found via .../share/mk if you start somewhere under
/BETA1/usr/ports

> This bug shows in both 11.0-STABLE and 12.0-CURRENT.

Not a bug - working as intended, which doesn't mean it is doing what you
want.

You can of course set MAKESYSPATH as you wish, but of course
/usr/share/mk would not be correct for building src/
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [rfc] breaking out if_ath into ... lots of modules

[Adrian Chadd]

On 22 May 2017 at 13:17, John Baldwin  wrote:

> Why not have if_ath.ko just be a wrapper module that depends on everything
> like dtraceall.ko?  That would let 'kldload if_ath' and the auto-loading
> code in ifconfig still DTRT.  You could name the "only the driver" module
> ath.ko or some such.

Oh yeah, I could also do that to reduce POLA. :)

Ok, I'll add that to the TODO list before I submit a review. I'll
rename if_ath to if_ath_drv or something.

-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [rfc] breaking out if_ath into ... lots of modules

[Warner Losh]

On Mon, May 22, 2017 at 2:17 PM, John Baldwin  wrote:

> On Monday, May 22, 2017 12:29:15 PM Adrian Chadd wrote:
> > Hi,
> >
> > I've been putting this off for a few years, but now I've reached a
> > point where I kind of need to do this.
> >
> > The TL;DR is this - I'd like to break the ath driver /back/ out into
> > separate modules, and then have them be run-time loadable. It's part
> > for space savings, and part for the upcoming ath10k work where I need
> > to reuse the regulatory EEPROM code.
> >
> > The reason? I can't easily build a modular ath driver without
> > compiling in /everything/. For the AR933x/AR934x embedded platforms
> > which don't require the previous HAL chipset code, this is almost
> > 800kbyte extra binary code in the kernel that doesn't ever get run.
> > For earlier boards (say the AR9280 embedded boards), it's roughly
> > 600kbyte of AR9300 HAL code that doesn't ever get run.
> >
> > I have a patchset (which I'll push up soon) which turns if_ath into:
> >
> > * if_ath - only the driver;
> > * (if_ath_pci / if_ath_ahb stay the same);
> > * ath_hal - only the shared, global HAL code (osdep routines, HAL
> > core, regulatory code);
> > * ath_rate - the ath rate control code (either sample, amrr, onoe);
> > * ath_dfs - just dfs_null for now, but this will eventually be a radar
> detector;
> > * ath_hal_{ar5210,ar5211,ar5212,ar5416,ar9300} - the individual chipset
> HALs.
> >
> > Now, I'm thinking of further breaking out ar5416 into
> > {ar5416,ar9001,ar9002} just to save space for the embedded builds
> > (like AR9103/AR9106 which some people still use) but that can come
> > later.
> >
> > There's no AR2312/AR5312 11abg + MIPS4k core support in FreeBSD, so
> > I'll go and look at making the AR5312 wifi support work. That'll
> > become another HAL module.
> >
> > On the regulatory side, I then need to divorce the EEPROM regulatory
> > code from ath_hal and turn /it/ into a separate module because,
> > surprise, the ath10k 11ac hardware uses the same regulatory code. I'll
> > do this particular step later.
> >
> > What does this mean?
> >
> > * If you compile up a kernel with everything in it, nothing will
> > change - hopefully this is the majority of users;
> > * If you compile a modular kernel or embedded platform - you need to
> > load ath_hal and the relevant HAL modules before you load if_ath /
> > if_ath_pci otherwise it won't find your hardware.
> >
> > I realise this is a bit of a POLA change, but I'd like to get it into
> > -HEAD before FreeBSD-12 is cut.
>
> Why not have if_ath.ko just be a wrapper module that depends on everything
> like dtraceall.ko?  That would let 'kldload if_ath' and the auto-loading
> code in ifconfig still DTRT.  You could name the "only the driver" module
> ath.ko or some such.
>

I like this a lot. There's much magic in places like netstat and people's
loader.conf files that this solution would preseve that yours would break.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [rfc] breaking out if_ath into ... lots of modules

[John Baldwin]

On Monday, May 22, 2017 12:29:15 PM Adrian Chadd wrote:
> Hi,
> 
> I've been putting this off for a few years, but now I've reached a
> point where I kind of need to do this.
> 
> The TL;DR is this - I'd like to break the ath driver /back/ out into
> separate modules, and then have them be run-time loadable. It's part
> for space savings, and part for the upcoming ath10k work where I need
> to reuse the regulatory EEPROM code.
> 
> The reason? I can't easily build a modular ath driver without
> compiling in /everything/. For the AR933x/AR934x embedded platforms
> which don't require the previous HAL chipset code, this is almost
> 800kbyte extra binary code in the kernel that doesn't ever get run.
> For earlier boards (say the AR9280 embedded boards), it's roughly
> 600kbyte of AR9300 HAL code that doesn't ever get run.
> 
> I have a patchset (which I'll push up soon) which turns if_ath into:
> 
> * if_ath - only the driver;
> * (if_ath_pci / if_ath_ahb stay the same);
> * ath_hal - only the shared, global HAL code (osdep routines, HAL
> core, regulatory code);
> * ath_rate - the ath rate control code (either sample, amrr, onoe);
> * ath_dfs - just dfs_null for now, but this will eventually be a radar 
> detector;
> * ath_hal_{ar5210,ar5211,ar5212,ar5416,ar9300} - the individual chipset HALs.
> 
> Now, I'm thinking of further breaking out ar5416 into
> {ar5416,ar9001,ar9002} just to save space for the embedded builds
> (like AR9103/AR9106 which some people still use) but that can come
> later.
> 
> There's no AR2312/AR5312 11abg + MIPS4k core support in FreeBSD, so
> I'll go and look at making the AR5312 wifi support work. That'll
> become another HAL module.
> 
> On the regulatory side, I then need to divorce the EEPROM regulatory
> code from ath_hal and turn /it/ into a separate module because,
> surprise, the ath10k 11ac hardware uses the same regulatory code. I'll
> do this particular step later.
> 
> What does this mean?
> 
> * If you compile up a kernel with everything in it, nothing will
> change - hopefully this is the majority of users;
> * If you compile a modular kernel or embedded platform - you need to
> load ath_hal and the relevant HAL modules before you load if_ath /
> if_ath_pci otherwise it won't find your hardware.
> 
> I realise this is a bit of a POLA change, but I'd like to get it into
> -HEAD before FreeBSD-12 is cut.

Why not have if_ath.ko just be a wrapper module that depends on everything
like dtraceall.ko?  That would let 'kldload if_ath' and the auto-loading
code in ifconfig still DTRT.  You could name the "only the driver" module
ath.ko or some such.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[rfc] breaking out if_ath into ... lots of modules

[Adrian Chadd]

Hi,

I've been putting this off for a few years, but now I've reached a
point where I kind of need to do this.

The TL;DR is this - I'd like to break the ath driver /back/ out into
separate modules, and then have them be run-time loadable. It's part
for space savings, and part for the upcoming ath10k work where I need
to reuse the regulatory EEPROM code.

The reason? I can't easily build a modular ath driver without
compiling in /everything/. For the AR933x/AR934x embedded platforms
which don't require the previous HAL chipset code, this is almost
800kbyte extra binary code in the kernel that doesn't ever get run.
For earlier boards (say the AR9280 embedded boards), it's roughly
600kbyte of AR9300 HAL code that doesn't ever get run.

I have a patchset (which I'll push up soon) which turns if_ath into:

* if_ath - only the driver;
* (if_ath_pci / if_ath_ahb stay the same);
* ath_hal - only the shared, global HAL code (osdep routines, HAL
core, regulatory code);
* ath_rate - the ath rate control code (either sample, amrr, onoe);
* ath_dfs - just dfs_null for now, but this will eventually be a radar detector;
* ath_hal_{ar5210,ar5211,ar5212,ar5416,ar9300} - the individual chipset HALs.

Now, I'm thinking of further breaking out ar5416 into
{ar5416,ar9001,ar9002} just to save space for the embedded builds
(like AR9103/AR9106 which some people still use) but that can come
later.

There's no AR2312/AR5312 11abg + MIPS4k core support in FreeBSD, so
I'll go and look at making the AR5312 wifi support work. That'll
become another HAL module.

On the regulatory side, I then need to divorce the EEPROM regulatory
code from ath_hal and turn /it/ into a separate module because,
surprise, the ath10k 11ac hardware uses the same regulatory code. I'll
do this particular step later.

What does this mean?

* If you compile up a kernel with everything in it, nothing will
change - hopefully this is the majority of users;
* If you compile a modular kernel or embedded platform - you need to
load ath_hal and the relevant HAL modules before you load if_ath /
if_ath_pci otherwise it won't find your hardware.

I realise this is a bit of a POLA change, but I'd like to get it into
-HEAD before FreeBSD-12 is cut.

Thanks!



-adrian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Ssh.. can we please have HPN back?

[Julian Elischer]

On 23/5/17 12:13 am, Allan Jude wrote:

On 2017-05-22 03:50, Julian Elischer wrote:

On 22/5/17 2:20 pm, Allan Jude wrote:

On 2017-05-18 22:28, Julian Elischer wrote:

So after stripping out the HPN version of ssh from our product becasue
"it was no longer needed" we dicovered that we were premature in
doing so.
Apparently ssh still really needs HPN to get any throughput at all when
there are latencies involved.


For example, with HPN we get 13MB/sec between the Azure US west
Data center and the Azure East data center.But the standard ssh in 10.3
(with HPN stripped out) can barely manage 2MB/sec transfers.

I did ask at the time whether it was proved that the new ssh didn't
require the HPN changes,
and was assured, "no" but it would appear that the picture isn't as
clear.
tht seems silly to have to import the port when we have what would
otherwise be a
perfectly good ssh as part of hte system, and it's really annoying
having to specify
/usr/local/bin/scp  or /usr/local/bin/ssh in every script.

So can we please have the latest version of the HPN changes back in the
default system please?
It seem rather odd that the upstream openssh has had this problem for SO
LONG and not fixed it.

Julian


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
"freebsd-current-unsubscr...@freebsd.org"

I have this stand-alone patch ready now:

https://github.com/openssh/openssh-portable/compare/master...allanjude:V_7_5_dynamic_window


In my benchmarks with 100ms of latency (from dummynet) is increases SSH
send throughput from 1 megabyte/sec to 225 megabytes/sec provided a
large enough socket buffer.

Still seeing lesser performance on the recv case, working on it.

We have two patches of our own that upstream have ignored   an option to
set NoDelay   and a pushwindow setting option
(though I'm not sure the second is operational in the current code, it
does apply with no errors...)

The NoDelay options massively speeds up the case where you have chatty
back and forth traffic (client/server) through a ssh tunnel.

Are your changes against the sources in current?  what about stable/10?


That change is against upstream's latest release, but should apply
cleanly to any version of OpenSSH from the past 10 years that does not
have the HPN patches applied already.

However, the function channel_check_window() in stable/10 is currently
the same as the latest upstream since the commit that removed HPN. The
function is actually unchanged from upstream if you go back far enough
to before we added HPN as well.

If you revert both HPN commits, the most recent change to that function
is Aug 2008, when upstream introduced the 'move the window forward every
3 packets' thing that seams to be the main cause of the window scaling
problem in the first place. I think the nodelay option might be what
mitigates that, as it causes rapid back and forth and never allows the
window to grow to even the 2mb allowed by SSH since version 4.7



great

I'll look at applying it at $JOB and let you know what happens .. 
assuming I can get the patch downloaded and applied.



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Ssh.. can we please have HPN back?

[Allan Jude]

On 2017-05-22 03:50, Julian Elischer wrote:
> On 22/5/17 2:20 pm, Allan Jude wrote:
>> On 2017-05-18 22:28, Julian Elischer wrote:
>>> So after stripping out the HPN version of ssh from our product becasue
>>> "it was no longer needed" we dicovered that we were premature in
>>> doing so.
>>> Apparently ssh still really needs HPN to get any throughput at all when
>>> there are latencies involved.
>>>
>>>
>>> For example, with HPN we get 13MB/sec between the Azure US west
>>> Data center and the Azure East data center.But the standard ssh in 10.3
>>> (with HPN stripped out) can barely manage 2MB/sec transfers.
>>>
>>> I did ask at the time whether it was proved that the new ssh didn't
>>> require the HPN changes,
>>> and was assured, "no" but it would appear that the picture isn't as
>>> clear.
>>> tht seems silly to have to import the port when we have what would
>>> otherwise be a
>>> perfectly good ssh as part of hte system, and it's really annoying
>>> having to specify
>>> /usr/local/bin/scp  or /usr/local/bin/ssh in every script.
>>>
>>> So can we please have the latest version of the HPN changes back in the
>>> default system please?
>>> It seem rather odd that the upstream openssh has had this problem for SO
>>> LONG and not fixed it.
>>>
>>> Julian
>>>
>>>
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to
>>> "freebsd-current-unsubscr...@freebsd.org"
>> I have this stand-alone patch ready now:
>>
>> https://github.com/openssh/openssh-portable/compare/master...allanjude:V_7_5_dynamic_window
>>
>>
>> In my benchmarks with 100ms of latency (from dummynet) is increases SSH
>> send throughput from 1 megabyte/sec to 225 megabytes/sec provided a
>> large enough socket buffer.
>>
>> Still seeing lesser performance on the recv case, working on it.
> 
> We have two patches of our own that upstream have ignored   an option to
> set NoDelay   and a pushwindow setting option
> (though I'm not sure the second is operational in the current code, it
> does apply with no errors...)
> 
> The NoDelay options massively speeds up the case where you have chatty
> back and forth traffic (client/server) through a ssh tunnel.
> 
> Are your changes against the sources in current?  what about stable/10?
> 
>>
> 

That change is against upstream's latest release, but should apply
cleanly to any version of OpenSSH from the past 10 years that does not
have the HPN patches applied already.

However, the function channel_check_window() in stable/10 is currently
the same as the latest upstream since the commit that removed HPN. The
function is actually unchanged from upstream if you go back far enough
to before we added HPN as well.

If you revert both HPN commits, the most recent change to that function
is Aug 2008, when upstream introduced the 'move the window forward every
3 packets' thing that seams to be the main cause of the window scaling
problem in the first place. I think the nodelay option might be what
mitigates that, as it causes rapid back and forth and never allows the
window to grow to even the 2mb allowed by SSH since version 4.7


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: The futur of the roff toolchain

[Julian Elischer]

On 21/5/17 8:57 pm, Baptiste Daroussin wrote:

Hi all,


[...]


No the problem left is documentations available in share/doc.

I would like to push them elsewhere. Those documents are mostly useful for
historical reason (hence we want to keep them) but not really for daily use of
modern FreeBSD.
Another issue with those documentation, they are installed as text/ascii version
in base, which makes most of them not really readable (as the documents has not
be written for a ascii/text target but more for a PDF/html view - using pic(1)
for example)


I was surprised that they stayed in src when we split it up.
And really they should be supplemented by every FreeBSD based paper 
presented at a conference :-)




___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Shutter: gnome-vfs-2.0/modules/libfile.so: Undefined symbol "ih_startup"

[O. Hartmann]

On Mon, 22 May 2017 13:20:50 +0100
Graham Perrin  wrote:

>  for FreeBSD
> 9.2-RELEASE-p10 offers a patch for devel/gnome-vfs, the maintainer has tested
> it with Shutter and it "works fine".
> 
> I applied the patch with FreeBSD 12.0-CURRENT #0 r317181, installed gnome-vfs
> from ports then used pkg to install shutter.
> 
> Still, Shutter fails to start:
> 
> /usr/local/lib/gnome-vfs-2.0/modules/libfile.so: Undefined symbol "ih_startup"
> 
> Context: 
> 
> Any ideas? (What am I doing wrong?)
> 
> Thanks

[...]

Seems FreeBSD 12-CURRENT (I'm at FreeBSD 12.0-CURRENT #38 r318285: Mon May 15
12:27:29 CEST 2017 amd64) means some fun recently with "Undefined symbol":

[...]
mplayer
/usr/local/lib/libglib-2.0.so.0: Undefined symbol "environ"



This happened after the update of glib-2.0

I mention this not with the intention to raid the thread, but maybe there is a
major issue with 12-CURRENT at the moment. I'm curios if this is related only
to systems where WITH_LLD_IS_LD is enabled.

oh 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Shutter: gnome-vfs-2.0/modules/libfile.so: Undefined symbol "ih_startup"

[Graham Perrin]

 for FreeBSD 9.2-RELEASE-p10 
offers a patch for devel/gnome-vfs, the maintainer has tested it with Shutter and it 
"works fine".

I applied the patch with FreeBSD 12.0-CURRENT #0 r317181, installed gnome-vfs 
from ports then used pkg to install shutter.

Still, Shutter fails to start:

/usr/local/lib/gnome-vfs-2.0/modules/libfile.so: Undefined symbol "ih_startup"

Context: 

Any ideas? (What am I doing wrong?)

Thanks
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Problem with re(4) Ethernet driver has resurfaced in 11-STABLE and HEAD

[Thomas Mueller]

from O. Hartmann:

> Just for my curiosity: do you have "options FLOWTABLE" defined in your kernel 
> config?

I was not even aware of "options FLOWTABLE", having not seen it in GENERIC 
kernel config.

I had to look in $SRCDIR/sys/conf/NOTES to find it.

What would I get by adding "options FLOWTABLE" to my kernel config?

Tom

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Ssh.. can we please have HPN back?

[Julian Elischer]

On 22/5/17 2:20 pm, Allan Jude wrote:

On 2017-05-18 22:28, Julian Elischer wrote:

So after stripping out the HPN version of ssh from our product becasue
"it was no longer needed" we dicovered that we were premature in doing so.
Apparently ssh still really needs HPN to get any throughput at all when
there are latencies involved.


For example, with HPN we get 13MB/sec between the Azure US west
Data center and the Azure East data center.But the standard ssh in 10.3
(with HPN stripped out) can barely manage 2MB/sec transfers.

I did ask at the time whether it was proved that the new ssh didn't
require the HPN changes,
and was assured, "no" but it would appear that the picture isn't as clear.
tht seems silly to have to import the port when we have what would
otherwise be a
perfectly good ssh as part of hte system, and it's really annoying
having to specify
/usr/local/bin/scp  or /usr/local/bin/ssh in every script.

So can we please have the latest version of the HPN changes back in the
default system please?
It seem rather odd that the upstream openssh has had this problem for SO
LONG and not fixed it.

Julian


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

I have this stand-alone patch ready now:

https://github.com/openssh/openssh-portable/compare/master...allanjude:V_7_5_dynamic_window

In my benchmarks with 100ms of latency (from dummynet) is increases SSH
send throughput from 1 megabyte/sec to 225 megabytes/sec provided a
large enough socket buffer.

Still seeing lesser performance on the recv case, working on it.


We have two patches of our own that upstream have ignored   an option 
to set NoDelay   and a pushwindow setting option
(though I'm not sure the second is operational in the current code, it 
does apply with no errors...)


The NoDelay options massively speeds up the case where you have chatty 
back and forth traffic (client/server) through a ssh tunnel.


Are your changes against the sources in current?  what about stable/10?





___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Ssh.. can we please have HPN back?

[Allan Jude]

On 2017-05-18 22:28, Julian Elischer wrote:
> So after stripping out the HPN version of ssh from our product becasue
> "it was no longer needed" we dicovered that we were premature in doing so.
> Apparently ssh still really needs HPN to get any throughput at all when
> there are latencies involved.
> 
> 
> For example, with HPN we get 13MB/sec between the Azure US west
> Data center and the Azure East data center.But the standard ssh in 10.3
> (with HPN stripped out) can barely manage 2MB/sec transfers.
> 
> I did ask at the time whether it was proved that the new ssh didn't
> require the HPN changes,
> and was assured, "no" but it would appear that the picture isn't as clear.
> tht seems silly to have to import the port when we have what would
> otherwise be a
> perfectly good ssh as part of hte system, and it's really annoying
> having to specify
> /usr/local/bin/scp  or /usr/local/bin/ssh in every script.
> 
> So can we please have the latest version of the HPN changes back in the
> default system please?
> It seem rather odd that the upstream openssh has had this problem for SO
> LONG and not fixed it.
> 
> Julian
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

I have this stand-alone patch ready now:

https://github.com/openssh/openssh-portable/compare/master...allanjude:V_7_5_dynamic_window

In my benchmarks with 100ms of latency (from dummynet) is increases SSH
send throughput from 1 megabyte/sec to 225 megabytes/sec provided a
large enough socket buffer.

Still seeing lesser performance on the recv case, working on it.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature