typo in Pod::Man special character table
Hi, while looking at Pod::Man, here is another, simpler bug in there. The preamble defines an \*(Ae string, but no \*(AE, and then the character table uses \*(AE, but not \*(Ae. The reason for the confusion probably is that (at least newer) groffs define an \(AE built-in special character. However, neither groff nor mandoc automatically resolve undefined strings to characters of the same name, as both live in separate namespaces. The patch below fixes the following author name in /usr/ports/pobj/p5-MooseX-Getopt-0.37/MooseX-Getopt-0.37/lib/MooseX/Getopt.pm AEvar Arnfjoer` Bjarmason Without the patch, both groff and mandoc render only var Arnfjoer` Bjarmason OK to commit? Of course, i will also send this upstream, it still looks broken in the Perl 5.15 git HEAD. Yours, Ingo Index: Man.pm === RCS file: /cvs/src/gnu/usr.bin/perl/cpan/podlators/lib/Pod/Man.pm,v retrieving revision 1.2 diff -u -r1.2 Man.pm --- Man.pm 24 Sep 2010 15:06:55 - 1.2 +++ Man.pm 5 Dec 2011 00:07:09 - @@ -1315,7 +1323,7 @@ undef, undef, undef, undef,undef, undef, undef, undef, undef, undef, undef, undef,undef, undef, undef, undef, -"A\\*`", "A\\*'", "A\\*^", "A\\*~", "A\\*:", "A\\*o", "\\*(AE", "C\\*,", +"A\\*`", "A\\*'", "A\\*^", "A\\*~", "A\\*:", "A\\*o", "\\*(Ae", "C\\*,", "E\\*`", "E\\*'", "E\\*^", "E\\*:", "I\\*`", "I\\*'", "I\\*^", "I\\*:", "\\*(D-", "N\\*~", "O\\*`", "O\\*'", "O\\*^", "O\\*~", "O\\*:", undef,
font translation woes in Pod::Man::switchquotes
Hi,
while working on the p5-Moose port, Andreas Voegele reported
misformatting by mandoc(1) that can be reproduced with the
following minimal example provided by Andreas:
$ cat example.pod
=over
=item Two arg method B<< $obj->($x, $y) >>
bla.
=back
$ pod2man example.pod > example.man
$ mandoc example.man | less
Andreas wrote:
> mandoc doesn't emphasise the method declaration's second argument.
> Groff, on the other hand, underlines the second argument.
As Andreas suspected, there is indeed a bug in pod2man(1),
which generates this roff(7) code:
.ie n .IP "Two arg method \fB\fB$obj\fB\->($x, \f(BI$y\fB)\fR" 4
.el .IP "Two arg method \fB\f(CB$obj\fB\->($x, \f(CB$y\fB)\fR" 4
The problem is that in the first line, the second CB (constant bold)
font escape was translated to BI (bold italic), even though there
is nothing about italic anywhere in the neighbourhood, and even
though the first CB was correctly translated to B (just bold).
I tracked the problem down to Pod/Man.pm, function switchquotes().
One thing that function does is replace constant width font escapes by
standard bold and italic escapes in nroff(1) mode, while leaving them
intact in troff(1) mode, because constant width fonts are often not
recognized by nroff(1): mandoc(1) is no exception in that respect.
Actually, the REs in that function suffer from two bugs: They only
replace font escapes followed by R or P switchbacks, such that some
escapes slip through even though nroff(1) cannot handle them.
And they neglect to check that the R or P switchback they find
is actually the *next* font escape, such that any font escapes
in between remain unprocessed. For example, in "\f(CB \f(CI \fP",
the CB would be translated to B, but the CI would slip through.
The patch given below fixes this. I have also checked that it
doesn't cause regressions in formatting our Perl manuals.
To the contrary, it reduces the groff-mandoc differences in base
by about 0.7 percent (minus 360 lines of diffs).
Is it OK to commit this patch?
If so, i should clearly send it upstream to perl.org as well,
since the problematic code is still in the Perl 5.15 git HEAD,
but before sending something to the Perl people, i'd
appreciate a look from our own Perl developers.
Thanks,
Ingo
P.S.
After digging into this code, i do feel dirty.
The whole architecture seems rather ad-hoc and fragile.
Index: Man.pm
===
RCS file: /cvs/src/gnu/usr.bin/perl/cpan/podlators/lib/Pod/Man.pm,v
retrieving revision 1.2
diff -u -p -r1.2 Man.pm
--- Man.pm 24 Sep 2010 15:06:55 - 1.2
+++ Man.pm 4 Dec 2011 21:52:22 -
@@ -646,10 +646,18 @@ sub switchquotes {
# to Roman rather than the actual previous font when used in headings.
# troff output may still be broken, but at least we can fix nroff by
# just switching the font changes to the non-fixed versions.
-$nroff =~ s/\Q$$self{FONTS}{100}\E(.*?)\\f[PR]/$1/g;
-$nroff =~ s/\Q$$self{FONTS}{101}\E(.*?)\\f([PR])/\\fI$1\\f$2/g;
-$nroff =~ s/\Q$$self{FONTS}{110}\E(.*?)\\f([PR])/\\fB$1\\f$2/g;
-$nroff =~ s/\Q$$self{FONTS}{111}\E(.*?)\\f([PR])/\\f\(BI$1\\f$2/g;
+
+# The first case (CW) is complicated: Replacing CW by R would
+# be wrong because we might be inside high-level man(7) macros
+# (like SS) that want to keep B or I up. Thus, remove CW;
+# and if the next font escape is P, remove that one as well.
+$nroff =~ s/\Q$$self{FONTS}{100}\E((?:[^\\]|\\(?!f))*)(?:\\fP)?/$1/g;
+
+# The remaining cases are easier: When replacing a font escape,
+# as opposed to removing it, the next font escape does not matter.
+$nroff =~ s/\Q$$self{FONTS}{101}\E/\\fI/g;
+$nroff =~ s/\Q$$self{FONTS}{110}\E/\\fB/g;
+$nroff =~ s/\Q$$self{FONTS}{111}\E/\\f\(BI/g;
# Now finally output the command. Bother with .ie only if the nroff
# and troff output aren't the same.
Re: raise max value for tcp autosizing buffer [WAS: misc@ network tuning for high bandwidth and high latency]
> Date: Sun, 4 Dec 2011 15:10:56 +0100 > From: Claudio Jeker > > On Sun, Dec 04, 2011 at 01:35:33PM +0100, Sebastian Reitenbach wrote: > > On Sunday, December 4, 2011 13:24 CET, Camiel Dobbelaar > > wrote: > > > > > On 4-12-2011 13:01, Sebastian Reitenbach wrote: > > > > the default maximum size of the tcp send and receive buffer used by the > > > > autosizing algorithm is way too small, when trying to get maximum speed > > > > with high bandwidth and high latency connections. > > > > > > I have tweaked SB_MAX on a system too, but it was for UDP. > > > > > > When running a busy Unbound resolver, the recommendation is too bump the > > > receive buffer to 4M or even 8M. See > > > http://unbound.net/documentation/howto_optimise.html > > > > > > Otherwise a lot of queries are dropped when the cache is cold. > > > > > > I don't think there's a magic value that's right for everyone, so a > > > sysctl would be nice. Maybe separate ones for tcp and udp. > > > > > > I know similar sysctl's have been removed recently, and that they are > > > sometimes abused, but I'd say we have two valid use cases now. > > > > > > So I'd love some more discussion. :-) > > > > since they were removed, and there is this keep it simple, and too many > > knobs are bad attitude, which I think is not too bad, I just bumped the > > SB_MAX value. > > If there is consensus that a sysctl would make sense, I'd also look into > > that approach and send new patch. > > SB_MAX is there to protect your system. It gives a upperbound on how much > memory a socket may allocate. The current value is a compromize. Running > with a huge SB_MAX may make one connection faster but it will cause > resource starvation issues on busy systems. > Sure you can bump it but be aware of the consequneces (and it is why I > think we should not bump it at the moment). A proper change needs to > include some sort of resource management that ensures that we do not run > the kernel out of memory. But 256k simply isn't enough for some use cases. Turning this into a sysctl tunable like FreeBSD and NetBSD would be a good idea if you ask me. Yes, people will use it to shoot themselves in the foot. I don't care.
Re: terminal descriptions for AMD/Intel consoles
And here we go, sync to latest upstream terminfo.src from
ncurses-2011203. Just the changes from Alexei Malinin.
ok?
Index: termtypes.master
===
RCS file: /cvs/src/share/termtypes/termtypes.master,v
retrieving revision 1.45
diff -u -p -r1.45 termtypes.master
--- termtypes.master8 Oct 2011 10:24:38 - 1.45
+++ termtypes.master4 Dec 2011 16:30:12 -
@@ -1666,6 +1666,56 @@ qansi-m|QNX ansi with mouse,
qansi-w|QNX ansi for windows,
xvpa, use=qansi-m,
+ OpenBSD consoles
+#
+# From: Alexei Malinin ; October, 2011.
+#
+# The following terminal descriptions for the AMD/Intel PC console
+# were prepared based on information contained in the OpenBSD-4.9
+# termtypes.master and wscons(4) & vga(4) manuals (2010, November).
+#
+# Added bce based on testing with tack -TD
+# Added several capabilities to pccon+base, reading wsemul_vt100_subr.c -TD
+# Changed kbs to DEL and removed keys that duplicate stty settings -TD
+#
+pccon+keys|OpenBSD PC keyboard keys,
+ kbs=\177, kcub1=\E[D, kcud1=\E[B, kcuf1=\E[C, kcuu1=\E[A,
+ kdch1=\E[3~, kend=\E[8~, kent=^M, kf1=\E[11~, kf10=\E[21~,
+ kf11=\E[23~, kf12=\E[24~, kf2=\E[12~, kf3=\E[13~,
+ kf4=\E[14~, kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~,
+ kf9=\E[20~, khome=\E[7~, kich1=\E[2~, knp=\E[6~, kpp=\E[5~,
+ krfr=^R,
+pccon+sgr+acs0|sgr and simple ASCII pseudographics for OpenBSD PC console,
+ acsc=+>\,<-\^.v0#`+a\:f\\h#i#j+k+l+m+n+o~p-q-r-s_t+u+v+w+x|y#z#{*|!}#~o,
+ sgr=\E[0%?%p1%p3%|%t;7%;m, sgr0=\E[m,
+pccon+sgr+acs|sgr and default ASCII pseudographics for OpenBSD PC console,
+ acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
+ enacs=\E)0$<5>, rmacs=\E(B$<5>,
+ sgr=\E[0%?%p1%p3%|%t;7%;m%?%p9%t\E(0%e\E(B%;$<5>,
+ sgr0=\E[m\E(B$<5>, smacs=\E(0$<5>,
+pccon+colors|ANSI colors for OpenBSD PC console,
+ bce,
+ colors#8, pairs#64,
+ op=\E[m, setab=\E[4%p1%dm, setaf=\E[3%p1%dm,
+pccon+base|base capabilities for OpenBSD PC console,
+ am, km, mc5i, msgr, npc, nxon, xenl, xon,
+ cols#80, it#8, lines#24,
+ bel=^G, clear=\E[H\E[J, cr=^M, cub1=^H, cud1=^J, cuf1=\E[C,
+ cup=\E[%i%p1%d;%p2%dH, cuu1=\E[A, dch=\E[%p1%dP,
+ dch1=\E[P, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
+ el1=\E[1K, home=\E[H, ht=^I, hts=\EH, ich=\E[%p1%d@,
+ il1=\E[L, ind=\ED, nel=\EE, rev=\E[7m, ri=\EM, rmam=\E[?7l,
+ rmso=\E[m, rs2=\Ec$<50>, smam=\E[?7h, smso=\E[7m,
+ tbc=\E[3g, u6=\E[%i%d;%dR, u7=\E[6n,
+pccon0-m|OpenBSD PC console without colors & with simple ASCII pseudographics,
+ use=pccon+base, use=pccon+sgr+acs0, use=pccon+keys,
+pccon0|OpenBSD PC console with simple ASCII pseudographics,
+ use=pccon0-m, use=pccon+colors,
+pccon-m|OpenBSD PC console without colors,
+ use=pccon+base, use=pccon+sgr+acs, use=pccon+keys,
+pccon|OpenBSD PC console,
+ use=pccon-m, use=pccon+colors,
+
NetBSD consoles
#
# pcvt termcap database entries (corresponding to release 3.31)
@@ -22583,5 +22633,8 @@ v3220|LANPAR Vision II model 3220/3221/3
#
# 2011-09-10
# * add xterm+kbs fragment from xterm #272 -TD
+#
+# 2011-11-12
+# * add pccon entries for OpenBSD console (Alexei Malinin)
#
SHANTIH! SHANTIH! SHANTIH!
On Tue, Nov 15, 2011 at 11:16:14PM +, Nicholas Marriott wrote:
> Yeah it's on my todo list :-).
>
>
> On Mon, Nov 14, 2011 at 10:58:10AM +0400, Alexei Malinin wrote:
> > Nicholas Marriott wrote:
> > > ...
> > > I at least would be pretty reluctant to include full terminfo entries as
> > > local changes in OpnBSD. If possible try to get them upstream.
> >
> > Hello, Nicholas.
> >
> > Thomas E. Dickey recently added pccon terminal descriptions
> > to ncurses-current (please see below).
> >
> > Will you update termtypes.master with pccon entries?
> >
> >
> > --
> > Alexei Malinin
> >
> >
> > Original Message
> > Subject:ncurses-5.9-2012.patch.gz
> > Date: Sat, 12 Nov 2011 21:55:49 -0500
> > From: Thomas Dickey
> > Reply-To: dic...@his.com
> > To: Ncurses Mailing List
> >
> >
> >
> > ncurses 5.9 - patch 2012 - Thomas E. Dickey
> >
> >
> > --
> >
> > Ncurses 5.9 is at
> > ftp.gnu.org:/pub/gnu
> >
> > Patches for ncurses 5.9 are in the subdirectory
> > ftp://invisible-island.net/ncurses/5.9
> >
> >
> > --
> > ftp://invisible-island.net/ncurses/5.9/ncurses-5.9-2012.patch.gz
> > patch by Thomas E. Dickey
> > created Sun Nov 13 02:51:43 UTC 2011
> >
> > --
> > Ada95/aclocal.m4 | 44
> > Ada95/configure | 963 +++---
> > NEWS | 26
> > aclocal.m4
Re: raise max value for tcp autosizing buffer [WAS: misc@ network tuning for high bandwidth and high latency]
* Geoff Steckel [2011-12-04 16:17]: > To generalize this problem: kernel memory is limited. It is > autosized at boot time. that might have been true a decade ago, but not today. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: raise max value for tcp autosizing buffer [WAS: misc@ network tuning for high bandwidth and high latency]
On 12/04/2011 09:10 AM, Claudio Jeker wrote: On Sun, Dec 04, 2011 at 01:35:33PM +0100, Sebastian Reitenbach wrote: On Sunday, December 4, 2011 13:24 CET, Camiel Dobbelaar wrote: On 4-12-2011 13:01, Sebastian Reitenbach wrote: the default maximum size of the tcp send and receive buffer used by the autosizing algorithm is way too small, when trying to get maximum speed with high bandwidth and high latency connections. I have tweaked SB_MAX on a system too, but it was for UDP. When running a busy Unbound resolver, the recommendation is too bump the receive buffer to 4M or even 8M. See http://unbound.net/documentation/howto_optimise.html Otherwise a lot of queries are dropped when the cache is cold. I don't think there's a magic value that's right for everyone, so a sysctl would be nice. Maybe separate ones for tcp and udp. I know similar sysctl's have been removed recently, and that they are sometimes abused, but I'd say we have two valid use cases now. So I'd love some more discussion. :-) since they were removed, and there is this keep it simple, and too many knobs are bad attitude, which I think is not too bad, I just bumped the SB_MAX value. If there is consensus that a sysctl would make sense, I'd also look into that approach and send new patch. SB_MAX is there to protect your system. It gives a upperbound on how much memory a socket may allocate. The current value is a compromize. Running with a huge SB_MAX may make one connection faster but it will cause resource starvation issues on busy systems. Sure you can bump it but be aware of the consequneces (and it is why I think we should not bump it at the moment). A proper change needs to include some sort of resource management that ensures that we do not run the kernel out of memory. How many high speed high latency connections would it take to use a "significant" proportion of kernel memory? Waving hands at the problem: at 500 ms round trip delay, a 1Gb/s interface saturated link = 63MB buffers per direction. A 100Mb/sec link would use 7MB per direction. Multiple sockets on such a link should use a similar amount in total using the autosizing algorithm. If this is approximately correct, documenting a formula might be useful for sysadmins. A system with 512MB physical memory should be able to saturate 2 or 3 100Mb/s links with large delays without seriously depleting kernel memory. It seems unlikely that a small system with multiple saturated 1Gb/s links (or 1 10Gb/s link) could do anything very useful. The pathological case: many sockets each one sequentially saturating the link and then going idle. The current limit does not defend against this. To generalize this problem: kernel memory is limited. It is autosized at boot time. Allowing any kernel subsystem to use a large amount jeopardizes system stability. Does it make sense, philosophically and technically, to allow the sysadmin to add physical memory to the kernel at run time, perhaps limited to (arbitrarily) 50% of physical memory? Geoff Steckel
Re: raise max value for tcp autosizing buffer [WAS: misc@ network tuning for high bandwidth and high latency]
On Sun, Dec 04, 2011 at 01:35:33PM +0100, Sebastian Reitenbach wrote: > On Sunday, December 4, 2011 13:24 CET, Camiel Dobbelaar > wrote: > > > On 4-12-2011 13:01, Sebastian Reitenbach wrote: > > > the default maximum size of the tcp send and receive buffer used by the > > > autosizing algorithm is way too small, when trying to get maximum speed > > > with high bandwidth and high latency connections. > > > > I have tweaked SB_MAX on a system too, but it was for UDP. > > > > When running a busy Unbound resolver, the recommendation is too bump the > > receive buffer to 4M or even 8M. See > > http://unbound.net/documentation/howto_optimise.html > > > > Otherwise a lot of queries are dropped when the cache is cold. > > > > I don't think there's a magic value that's right for everyone, so a > > sysctl would be nice. Maybe separate ones for tcp and udp. > > > > I know similar sysctl's have been removed recently, and that they are > > sometimes abused, but I'd say we have two valid use cases now. > > > > So I'd love some more discussion. :-) > > since they were removed, and there is this keep it simple, and too many > knobs are bad attitude, which I think is not too bad, I just bumped the > SB_MAX value. > If there is consensus that a sysctl would make sense, I'd also look into > that approach and send new patch. SB_MAX is there to protect your system. It gives a upperbound on how much memory a socket may allocate. The current value is a compromize. Running with a huge SB_MAX may make one connection faster but it will cause resource starvation issues on busy systems. Sure you can bump it but be aware of the consequneces (and it is why I think we should not bump it at the moment). A proper change needs to include some sort of resource management that ensures that we do not run the kernel out of memory. -- :wq Claudio
1st step for dpb support of really distant hosts
Currently, dpb assumes the package files are available over NFS.
If you want to distribute a build over distant hosts, where NFS is not
practical, that's a big problem.
This is the 1st step to solving that problem: this allows "make package"
to actually build the package under the WKRDIR of the current port if
NO_PACKAGE_REPOSITORY=Yes
and also provides PKGFILES to know where the packages have been built.
After that, well, after make package, distant dpb would need to show the
pkgnames, we need an actual scp job to copy the packages over, and then
run the link part on the local host (e.g., make package is enough).
Distant hosts would need to have a correct PKG_PATH to get the packages back
from the master host, which might be a bit expensive...
Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1149
diff -u -p -r1.1149 bsd.port.mk
--- bsd.port.mk 2 Dec 2011 15:14:20 - 1.1149
+++ bsd.port.mk 4 Dec 2011 13:55:12 -
@@ -721,38 +721,62 @@ ${_v}${_s} ?= ${${_v}}
_PACKAGE_LINKS =
NO_ARCH ?= no-arch
-_PKG_REPO = ${PACKAGE_REPOSITORY}/${MACHINE_ARCH}/all/
_TMP_REPO = ${PACKAGE_REPOSITORY}/${MACHINE_ARCH}/tmp/
_CACHE_REPO = ${PACKAGE_REPOSITORY}/${MACHINE_ARCH}/cache/
-PKGFILE = ${_PKG_REPO}${_PKGFILE${SUBPACKAGE}}
.for _S in ${MULTI_PACKAGES}
_PKGFILE${_S} = ${FULLPKGNAME${_S}}.tgz
-. if ${PKG_ARCH${_S}} == "*" && ${NO_ARCH} != ${MACHINE_ARCH}/all
-_PACKAGE_COOKIE${_S} = ${PACKAGE_REPOSITORY}/${NO_ARCH}/${_PKGFILE${_S}}
-. else
-_PACKAGE_COOKIE${_S} =
${PACKAGE_REPOSITORY}/${MACHINE_ARCH}/all/${_PKGFILE${_S}}
-. endif
+PKGFILE${_S} = ${_PKG_REPO}${_PKGFILE${_S}}
.endfor
+PKGFILE = ${_PKG_REPO}${_PKGFILE${SUBPACKAGE}}
+
.for _S in ${BUILD_PACKAGES}
-. if ${PKG_ARCH${_S}} == "*" && ${NO_ARCH} != ${MACHINE_ARCH}/all
+_PACKAGE_COOKIES += ${_PACKAGE_COOKIES${_S}}
+_PACKAGE_COOKIE += ${_PACKAGE_COOKIE${_S}}
+PKGFILES += ${PKGFILE${_S}}
+.endfor
+
+NO_PACKAGE_REPOSITORY ?= No
+
+.if ${NO_PACKAGE_REPOSITORY:L} == "yes"
+_PKG_REPO = ${WRKDIR}/pkg/
+. for _S in ${MULTI_PACKAGES}
+_PACKAGE_COOKIE${_S} = ${WRKDIR}/pkg/${_PKGFILE${_S}}
+. endfor
+. for _S in ${BUILD_PACKAGES}
+_PACKAGE_COOKIES${_S} += ${_PACKAGE_COOKIE${_S}}
+_PACKAGE_COOKIES += ${_PACKAGE_COOKIES${_S}}
+_PACKAGE_COOKIE += ${_PACKAGE_COOKIE${_S}}
+. endfor
+.else
+
+_PKG_REPO = ${PACKAGE_REPOSITORY}/${MACHINE_ARCH}/all/
+
+. for _S in ${MULTI_PACKAGES}
+.if ${PKG_ARCH${_S}} == "*" && ${NO_ARCH} != ${MACHINE_ARCH}/all
+_PACKAGE_COOKIE${_S} = ${PACKAGE_REPOSITORY}/${NO_ARCH}/${_PKGFILE${_S}}
+.else
+_PACKAGE_COOKIE${_S} =
${PACKAGE_REPOSITORY}/${MACHINE_ARCH}/all/${_PKGFILE${_S}}
+.endif
+. endfor
+
+. for _S in ${BUILD_PACKAGES}
+.if ${PKG_ARCH${_S}} == "*" && ${NO_ARCH} != ${MACHINE_ARCH}/all
_PACKAGE_LINKS += ${MACHINE_ARCH}/all/${_PKGFILE${_S}}
${NO_ARCH}/${_PKGFILE${_S}}
_PACKAGE_COOKIES${_S} +=
${PACKAGE_REPOSITORY}/${MACHINE_ARCH}/all/${_PKGFILE${_S}}
-. endif
+.endif
_PACKAGE_COOKIES${_S} += ${_PACKAGE_COOKIE${_S}}
-. if ${PERMIT_PACKAGE_FTP${_S}:L} == "yes"
+.if ${PERMIT_PACKAGE_FTP${_S}:L} == "yes"
_PACKAGE_COOKIES${_S} +=
${PACKAGE_REPOSITORY}/${MACHINE_ARCH}/ftp/${_PKGFILE${_S}}
_PACKAGE_LINKS += ${MACHINE_ARCH}/ftp/${_PKGFILE${_S}}
${MACHINE_ARCH}/all/${_PKGFILE${_S}}
-. endif
-. if ${PERMIT_PACKAGE_CDROM${_S}:L} == "yes"
+.endif
+.if ${PERMIT_PACKAGE_CDROM${_S}:L} == "yes"
_PACKAGE_COOKIES${_S} +=
${PACKAGE_REPOSITORY}/${MACHINE_ARCH}/cdrom/${_PKGFILE${_S}}
_PACKAGE_LINKS += ${MACHINE_ARCH}/cdrom/${_PKGFILE${_S}}
${MACHINE_ARCH}/all/${_PKGFILE${_S}}
-. endif
-_PACKAGE_COOKIES += ${_PACKAGE_COOKIES${_S}}
-_PACKAGE_COOKIE += ${_PACKAGE_COOKIE${_S}}
-PKGFILE${_S} = ${_PKG_REPO}${_PKGFILE${_S}}
-.endfor
+.endif
+. endfor
+.endif
.if empty(SUBPACKAGE) || ${SUBPACKAGE} == "-"
FULLPKGPATH ?= ${PKGPATH}${FLAVOR_EXT:S/-/,/g}
Re: raise max value for tcp autosizing buffer [WAS: misc@ network tuning for high bandwidth and high latency]
On Sunday, December 4, 2011 13:24 CET, Camiel Dobbelaar wrote: > On 4-12-2011 13:01, Sebastian Reitenbach wrote: > > the default maximum size of the tcp send and receive buffer used by the > > autosizing algorithm is way too small, when trying to get maximum speed > > with high bandwidth and high latency connections. > > I have tweaked SB_MAX on a system too, but it was for UDP. > > When running a busy Unbound resolver, the recommendation is too bump the > receive buffer to 4M or even 8M. See > http://unbound.net/documentation/howto_optimise.html > > Otherwise a lot of queries are dropped when the cache is cold. > > I don't think there's a magic value that's right for everyone, so a > sysctl would be nice. Maybe separate ones for tcp and udp. > > I know similar sysctl's have been removed recently, and that they are > sometimes abused, but I'd say we have two valid use cases now. > > So I'd love some more discussion. :-) since they were removed, and there is this keep it simple, and too many knobs are bad attitude, which I think is not too bad, I just bumped the SB_MAX value. If there is consensus that a sysctl would make sense, I'd also look into that approach and send new patch. Sebastian > > -- > Cam
Re: raise max value for tcp autosizing buffer [WAS: misc@ network tuning for high bandwidth and high latency]
On 4-12-2011 13:01, Sebastian Reitenbach wrote: > the default maximum size of the tcp send and receive buffer used by the > autosizing algorithm is way too small, when trying to get maximum speed with > high bandwidth and high latency connections. I have tweaked SB_MAX on a system too, but it was for UDP. When running a busy Unbound resolver, the recommendation is too bump the receive buffer to 4M or even 8M. See http://unbound.net/documentation/howto_optimise.html Otherwise a lot of queries are dropped when the cache is cold. I don't think there's a magic value that's right for everyone, so a sysctl would be nice. Maybe separate ones for tcp and udp. I know similar sysctl's have been removed recently, and that they are sometimes abused, but I'd say we have two valid use cases now. So I'd love some more discussion. :-) -- Cam
raise max value for tcp autosizing buffer [WAS: misc@ network tuning for high bandwidth and high latency]
Hi, the default maximum size of the tcp send and receive buffer used by the autosizing algorithm is way too small, when trying to get maximum speed with high bandwidth and high latency connections. I tested to get the best speed with a connection between Germany and Canada, ping times around 180ms. On the site in Germany, I have 155MBit Internet uplink, but the card in the test box, only negotiated 100MBit, so actually 100MBit uplink to the Internet. (Why it only negotiated 100MBit, is not the topic here...) On the site in Canada, I have even more than 155MBit Internet uplink. The maximum size of the buffer is defined in sys/sys/socketvar.h: #define SB_MAX (256*1024) With this value, I got download speeds, downloading on the Canadian box from the host in Germany, average of about 1.5MB/s, which is definitely not optimal. Doubling the value (512*1024), I got average speeds around 2.5-3MB/s. Doubling the value again to (1024*1024) I got average speeds of about 5-6MB/s. Doubling the value again to (2048*1024) I got average speeds of about 8MB/s. On the same box in Germany, I had a second harddisk with Linux OpenSUSE 11.2 installed. There, even with tweaking the buffers, I never got more than 4 MB/s average transfer speed. But that may be because I did not found the right values to use. The tcp buffer autosizing algorithm is at the end of sys/netinet/usrreq.c. As far as I understand the comments and the code right, it should be safe to raise the value. The buffer size is scaled up and down, depending on its fill level, and if the receiver can ack packets in a given time. Also, in case of low memory, the buffer is reset to small value. Therefore I think it should also be safe on busy servers with many connections on high speed LANs. But since I'm by far not a network stack expert, I might missing something. so the patch raises SB_MAX to (2048*1024) which seemed to be the best for my use case so far. I also tested higher values, but that did not gained me anything. I did not found a good network card that has gigabit, and good transfer rates, so I was unable to utilize the full 155MBit on my side here in Germany. so the value I propose might still be too small for even faster connections. so please test, comment, or even OK? cheers, Sebastian Index: sys/sys/socketvar.h === RCS file: /cvs/src/sys/sys/socketvar.h,v retrieving revision 1.50 diff -u -r1.50 socketvar.h --- sys/sys/socketvar.h 4 Jul 2011 22:53:53 - 1.50 +++ sys/sys/socketvar.h 4 Dec 2011 11:29:58 - @@ -104,7 +104,7 @@ short sb_flags; /* flags, see below */ u_short sb_timeo; /* timeout for read/write */ } so_rcv, so_snd; -#defineSB_MAX (256*1024) /* default for max chars in sockbuf */ +#defineSB_MAX (2048*1024) /* default for max chars in sockbuf */ #defineSB_LOCK 0x01/* lock on data queue */ #defineSB_WANT 0x02/* someone is waiting to lock */ #defineSB_WAIT 0x04/* someone is waiting for data/space */
Avis d'information régionale
Le Programme de votre Région Bonjour, Je me permets de vous contacter pour vous informer que le Programme Régional d'Optimisation de la Consommation et du Pouvoir d'Achat des Ménages concerne désormais plus de 7000 communes de France Métropolitaine. Leurs résidents et les salariés des entreprises qui y sont domiciliées ont droit à une aide à la consommation dans les plus grandes Enseignes : Fnac.com, PIXmania, Thomas Cook, Monoprix, Leroy Merlin et bien d'autres... - Des réductions de prix négociées en direct avec les Enseignes. - Le remboursement partiel de vos achats (jusqu'à 20%). Y avez-vous droit ? Voir les communes éligibles au Programme Si votre Commune est éligible, vous pourrez vous inscrire gratuitement et sans engagement. En savoir plus sur le Programme de votre région A très bientôt, Vincent Langlois Votre responsable régional Programme Régional d'Optimisation de la Consommation et du Pouvoir d'Achat des Ménages Vous recevez cet email car votre commune est peut-être éligible au Programme. En application de la loi du 6 janvier 1978 relative à l'informatique, aux fichiers et aux libertés, vous disposez des droits d'opposition, d'accès et de rectification des données vous concernant.
