Dear all,
recently the main branch was changed to build the TCP RACK stack
which is a loadable kernel module, by default:
https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
As discussed on the bi-weekly transport call, it would be great if people
could test the RACK
Hi,
On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote:
>
> Dear all,
>
> recently the main branch was changed to build the TCP RACK stack
> which is a loadable kernel module, by default:
> https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
>
> As discuss
On Thu, 16 Nov 2023 13:06:03 +0100, "Herbert J. Skuhra" wrote:
>
> Hi,
>
> On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote:
> >
> > Dear all,
> >
> > recently the main branch was changed to build the TCP RACK stack
> > which is a loadable kernel module, by default:
> > https://cgit
On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra wrote:
>
> OK, I am now running GENERIC-NODEBUG + "options TCPHPTS".
>
> After setting "sysctl net.inet.tcp.functions_default=rack" git no
> longer works:
>
>
Are you using a fresh 15 head or a specific network setup ?
Because I'm not able to rep
On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote:
>
> On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra wrote:
>
> >
> > OK, I am now running GENERIC-NODEBUG + "options TCPHPTS".
> >
> > After setting "sysctl net.inet.tcp.functions_default=rack" git no
> > longer works:
> >
> >
>
> On Nov 16, 2023, at 13:06, Herbert J. Skuhra wrote:
>
> Hi,
>
> On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote:
>>
>> Dear all,
>>
>> recently the main branch was changed to build the TCP RACK stack
>> which is a loadable kernel module, by default:
>> https://cgit.FreeBSD.org/s
> On Nov 16, 2023, at 14:05, Herbert J. Skuhra wrote:
>
> On Thu, 16 Nov 2023 13:06:03 +0100, "Herbert J. Skuhra" wrote:
>>
>> Hi,
>>
>> On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote:
>>>
>>> Dear all,
>>>
>>> recently the main branch was changed to build the TCP RACK stack
>>>
> On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote:
>
> On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote:
>>
>> On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra wrote:
>>
>>>
>>> OK, I am now running GENERIC-NODEBUG + "options TCPHPTS".
>>>
>>> After setting "sysctl net.ine
Hi,
On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
>
> > On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote:
> >
> > On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote:
> >>
> >> On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra
> >> wrote:
> >>
> >>>
> >>> OK,
On Fri, Nov 17, 2023 at 2:31 PM Herbert J. Skuhra wrote:
>
> 1. It even fails with a simple pf.conf:
>pass in all
>pass out all
>
> 2. Fetching port distfiles also failed.
>
> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
>
>
> I can't reproduce it with pfctl too (same i
Hi,
On Fri, Nov 17, 2023 at 02:46:52PM +0100, Olivier Cochard-Labbé wrote:
> On Fri, Nov 17, 2023 at 2:31 PM Herbert J. Skuhra wrote:
>
> >
> > 1. It even fails with a simple pf.conf:
> >pass in all
> >pass out all
> >
> > 2. Fetching port distfiles also failed.
> >
> > 3. If I disable r
> On Nov 16, 2023, at 5:13 PM, tue...@freebsd.org wrote:
>
> Dear all,
>
> recently the main branch was changed to build the TCP RACK stack
> which is a loadable kernel module, by default:
> https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
>
> As discussed on t
> On Nov 19, 2023, at 2:35 AM, Zhenlei Huang wrote:
>
>
>
>> On Nov 16, 2023, at 5:13 PM, tue...@freebsd.org wrote:
>>
>> Dear all,
>>
>> recently the main branch was changed to build the TCP RACK stack
>> which is a loadable kernel module, by default:
>> https://cgit.FreeBSD.org/src/commit
On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>
> Hi,
>
> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> >
> > > On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote:
> > >
> > > On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote:
> > >>
> > >> On
On Thu, 04 Jan 2024 14:57:59 +0100, tue...@fh-muenster.de wrote:
>
> > On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote:
> >
> > On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> >>
> >> Hi,
> >>
> >> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> >>>
> O
> On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote:
>
> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>>
>> Hi,
>>
>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
>>>
On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote:
On Thu, 16 Nov 2023 19:
> On Jan 4, 2024, at 15:22, Herbert J. Skuhra wrote:
>
> On Thu, 04 Jan 2024 14:57:59 +0100, tue...@fh-muenster.de wrote:
>>
>>> On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote:
>>>
>>> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
Hi,
On Fri, 17 Nov 20
On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
>
> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> >
> > Hi,
> >
> > On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> > >
> > > > On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote:
> > > >
> > > >
> On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote:
>
> On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
>>
>> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>>>
>>> Hi,
>>>
>>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> On Nov 1
On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
>
> > On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote:
> >
> > On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
> >>
> >> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> >>>
> >>> Hi,
> >>>
> >>> On
> On Jan 4, 2024, at 21:39, Herbert J. Skuhra wrote:
>
> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
>>
>>> On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote:
>>>
>>> On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
On Fri, 17 Nov 2023 14:31:02 +0100,
> On Jan 5, 2024, at 08:48, tue...@freebsd.org wrote:
>
>> On Jan 4, 2024, at 21:39, Herbert J. Skuhra wrote:
>>
>> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
>>>
On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote:
On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert
On Tue, 06 Feb 2024 23:05:27 +0100, tue...@freebsd.org wrote:
>
> > On Jan 5, 2024, at 08:48, tue...@freebsd.org wrote:
> >
> >> On Jan 4, 2024, at 21:39, Herbert J. Skuhra wrote:
> >>
> >> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
> >>>
> On Jan 4, 2024, at 18:52, Her
Hello,
I'm curious about tcp RACK.
As I do not run on a server background, only a laptop and a rpi4 for
poudriere, git, browsing, some torrent and ssh/sftp connections, will
I see any difference using RACK?
What tests should I do for comparison?
Thanks,
escreveu (quinta, 16/11/2023 à(s) 15:10)
> On 12. Mar 2024, at 14:39, Nuno Teixeira wrote:
>
> Hello,
>
> I'm curious about tcp RACK.
>
> As I do not run on a server background, only a laptop and a rpi4 for
> poudriere, git, browsing, some torrent and ssh/sftp connections, will
> I see any difference using RACK?
> What tests should I
> On 13. Mar 2024, at 08:06, Gary Jennejohn wrote:
>
> On Tue, 12 Mar 2024 20:14:17 +0100
> tue...@freebsd.org wrote:
>
>>> On 12. Mar 2024, at 14:39, Nuno Teixeira wrote:
>>>
>>> Hello,
>>>
>>> I'm curious about tcp RACK.
>>>
>>> As I do not run on a server background, only a laptop and a r
tue...@freebsd.org writes:
> Gary Jennejohn writes:
> > In the article we have option TCPHPTS and option TCP_RACK. But in
> > /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and
> > not option.
> Thanks for reporting, that is a typo in the article. It should
> always read options ins
> On 14. Mar 2024, at 11:04, Dag-Erling Smørgrav wrote:
>
> tue...@freebsd.org writes:
>> Gary Jennejohn writes:
>>> In the article we have option TCPHPTS and option TCP_RACK. But in
>>> /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and
>>> not option.
>> Thanks for reporting, th
Hello all,
On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've
noticed that all operations on OS was increased by 3 to 5 times
longer.
examples:
- firefox took way long time to open
- poudriere testport tooked up to 3 times longer to finished
make.conf:
KERNCONF=GENERIC-NODEBUG
> On 16. Mar 2024, at 08:57, Nuno Teixeira wrote:
>
> Hello all,
>
> On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've
> noticed that all operations on OS was increased by 3 to 5 times
> longer.
> examples:
> - firefox took way long time to open
> - poudriere testport tooked
On Sat, 16 Mar 2024 09:41:13 +0100
tue...@freebsd.org wrote:
> > On 16. Mar 2024, at 08:57, Nuno Teixeira wrote:
> >
> > Hello all,
> >
> > On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've
> > noticed that all operations on OS was increased by 3 to 5 times
> > longer.
> > ex
Followed man tcp_rack:
loader.conf:
tcp_rack_load="YES"
sysctl.conf:
net.inet.tcp.functions_default=rack
poudriere have restricted access to network, usually for fetch distfiles.
escreveu (sábado, 16/03/2024 à(s) 08:41):
>
> > On 16. Mar 2024, at 08:57, Nuno Teixeira wrote:
> >
> > Hello all,
Hello Gary,
Nice that you found this.
tcp_tack manual doesn't mention that we need extra config in kernel
but it loads module and it is shown in sysctl
net.inet.tcp.functions_available without errors.
I will add missing config to GENERIC and see how it goes.
Cheers,
Gary Jennejohn escreveu (
On Sat, 16 Mar 2024 09:49:24 +
Nuno Teixeira wrote:
> Hello Gary,
>
> Nice that you found this.
>
> tcp_tack manual doesn't mention that we need extra config in kernel
> but it loads module and it is shown in sysctl
> net.inet.tcp.functions_available without errors.
>
> I will add missing con
(...)
> These entries are missing in GENERIC:
>
> makeoptions WITH_EXTRA_TCP_STACKS=1
>From
>https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
WITH_EXTRA_TCP_STACKS was dropped.
> options TCPHPTS
That's the missing option in GENERIC that could lead t
> On 16. Mar 2024, at 11:11, Nuno Teixeira wrote:
>
> (...)
>
>> These entries are missing in GENERIC:
>>
>> makeoptions WITH_EXTRA_TCP_STACKS=1
>
> From
> https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
> WITH_EXTRA_TCP_STACKS was dropped.
>
>> options
On Sat, 16 Mar 2024 10:11:22 +
Nuno Teixeira wrote:
> (...)
>
> > These entries are missing in GENERIC:
> >
> > makeoptions WITH_EXTRA_TCP_STACKS=1
>
> From
> https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
> WITH_EXTRA_TCP_STACKS was dropped.
>
> > opti
> > Resuming I only need to add:
> >
> > options TCPHPTS
> >
> > Is this correct?
> >
>
> Yeah, that will probably fix it. According to a comment in
> /usr/src/sys/netinet/tcp_hpts.c it adds a high precision timer
> system for tcp, used by RACK and BBR.
As tuexen said, on main, loader.con
> On 16. Mar 2024, at 11:59, Nuno Teixeira wrote:
>
>>> Resuming I only need to add:
>>>
>>> options TCPHPTS
>>>
>>> Is this correct?
>>>
>>
>> Yeah, that will probably fix it. According to a comment in
>> /usr/src/sys/netinet/tcp_hpts.c it adds a high precision timer
>> system for t
> If you load tcp_rack via kldload, tcphtps get loaded automatically.
> If you load if via /boot/loader.conf, you need to have
> tcphpts_load="YES"
> in addition to
> tcp_rack_load="YES"
As of my tests, loader.conf: tcp_rack_load="YES" loads tcphtps.ko auto:
31 0x81f53000545e0 tcp
> On 16. Mar 2024, at 15:00, Nuno Teixeira wrote:
>
>> If you load tcp_rack via kldload, tcphtps get loaded automatically.
>> If you load if via /boot/loader.conf, you need to have
>> tcphpts_load="YES"
>> in addition to
>> tcp_rack_load="YES"
>
> As of my tests, loader.conf: tcp_rack_load="YES"
> > Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it.
> Please do so...
@main-n268827-75464941dc17 GENERIC-NODEBUG amd64
Ok, I think I have here some numbers related to disk performance being
affected by tcp_rack that somehow is messing with something.
NOTES:
- test [1]
> On 16. Mar 2024, at 20:06, Nuno Teixeira wrote:
>
>>> Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it.
>> Please do so...
>
> @main-n268827-75464941dc17 GENERIC-NODEBUG amd64
>
> Ok, I think I have here some numbers related to disk performance being
> affected by tc
> Just to double check: you only load the tcp_rack. You don't run
> sysctl net.inet.tcp.functions_default=rack
I'm not using sysctl, just loading module.
> What does "poudriere testport net/gitup" do? Only build stuff or does is
> also download something?
>
> What does bonnie++ do?
poudriere is
> On 16. Mar 2024, at 21:29, Nuno Teixeira wrote:
>
>> Just to double check: you only load the tcp_rack. You don't run
>> sysctl net.inet.tcp.functions_default=rack
>
> I'm not using sysctl, just loading module.
And you also don't have
net.inet.tcp.functions_default=rack
in /etc/sysctl.conf
This
Hello,
> > - I can't remember better tests to do as I can feel the entire OS is
> > being slow, without errors, just slow.
> This is interesting. It seems a consequence on loading TCPHPTS, not actually
> using it.
Exactly, just loading module and not using it by setting sysctl.
> I have CCed Dre
I don't have the full context, but it seems like the complaint is a performance
regression in bonnie++ and perhaps other things when tcp_hpts is loaded, even
when it is not used. Is that correct?
If so, I suspect its because we drive the tcp_hpts_softclock() routine from
userret(), in order to
Resending with the patch as an attachment.
Drew
On Sun, Mar 17, 2024, at 11:39 AM, Drew Gallatin wrote:
> I don't have the full context, but it seems like the complaint is a
> performance regression in bonnie++ and perhaps other things when tcp_hpts is
> loaded, even when it is not used. Is th
> On 17. Mar 2024, at 16:39, Drew Gallatin wrote:
>
> I don't have the full context, but it seems like the complaint is a
> performance regression in bonnie++ and perhaps other things when tcp_hpts is
> loaded, even when it is not used. Is that correct?
Correct.
>
> If so, I suspect its becau
Hello,
> I don't have the full context, but it seems like the complaint is a
> performance regression in bonnie++ and perhaps other things when tcp_hpts is
> loaded, even when it is not used. Is that correct?
>
> If so, I suspect its because we drive the tcp_hpts_softclock() routine from
> use
Hello all!
It works just fine!
System performance is OK.
Using patch on main-n268841-b0aaf8beb126(-dirty).
---
net.inet.tcp.functions_available:
Stack D AliasPCB count
freebsd freebsd 0
rack
> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote:
>
> Hello all!
>
> It works just fine!
> System performance is OK.
> Using patch on main-n268841-b0aaf8beb126(-dirty).
>
> ---
> net.inet.tcp.functions_available:
> Stack D AliasPCB count
> f
On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote:
>> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote:
>>
>> Hello all!
>>
>> It works just fine!
>> System performance is OK.
>> Using patch on main-n268841-b0aaf8beb126(-dirty).
>>
>> ---
>> net.inet.tcp.functions_available:
>> Stack
On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote:
> On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote:
>
> >> On 18. Mar 2024, at 12:42, Nuno Teixeira wrote:
> >>
> >> Hello all!
> >>
> >> It works just fine!
> >> System performance is OK.
> >> Using patch on main-n268841-b0aaf8beb126(
I got the idea from
https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf The
gist is that the TCP pacing stuff needs to run frequently, and rather than run
it out of a clock interrupt, its more efficient to run it out of a system call
context at just the point where we return
On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote:
> I got the idea from
> https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf
> The gist is that the TCP pacing stuff needs to run frequently, and
> rather than run it out of a clock interrupt, its more efficient to run
No. The goal is to run on every return to userspace for every thread.
Drew
On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belousov wrote:
> On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote:
> > I got the idea from
> > https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.
On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote:
> Ok I have created
>
> https://reviews.freebsd.org/D44420
>
>
> To address the issue. I also attach a short version of the patch that Nuno
> can try and validate
>
> it works. Drew you may want to try this and validate the optimization does
The entire point is to *NOT* go through the overhead of scheduling something
asynchronously, but to take advantage of the fact that a user/kernel transition
is going to trash the cache anyway.
In the common case of a system which has less than the threshold number of
connections , we access th
Hello all!
Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop
(amd64)!
Thanks all!
Drew Gallatin escreveu (quinta, 21/03/2024 à(s)
12:58):
> The entire point is to *NOT* go through the overhead of scheduling
> something asynchronously, but to take advantage of the fact that a
> On 28. Mar 2024, at 15:00, Nuno Teixeira wrote:
>
> Hello all!
>
> Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop (amd64)!
>
> Thanks all!
Thanks for the feedback!
Best regards
Michael
>
> Drew Gallatin escreveu (quinta, 21/03/2024 à(s) 12:58):
> The entire point is t
Hello all,
@ current 1500018 and fetching torrents with net-p2p/qbittorrent finished
~2GB download and connection UP until the end:
---
Apr 10 11:26:46 leg kernel: re0: watchdog timeout
Apr 10 11:26:46 leg kernel: re0: link state changed to DOWN
Apr 10 11:26:49 leg dhclient[58810]: New IP Address
> On 10. Apr 2024, at 13:40, Nuno Teixeira wrote:
>
> Hello all,
>
> @ current 1500018 and fetching torrents with net-p2p/qbittorrent finished
> ~2GB download and connection UP until the end:
>
> ---
> Apr 10 11:26:46 leg kernel: re0: watchdog timeout
> Apr 10 11:26:46 leg kernel: re0: lin
With base stack I can complete restic check successfully
downloading/reading/checking all files from a "big" remote compressed
backup.
Changing it to RACK stack, it fails.
I run this command often because in the past, compression corruption
occured and this is the equivalent of restoring backup to
(...)
Backup server is https://www.rsync.net/ (free 500GB for FreeBSD
developers).
Nuno Teixeira escreveu (quarta, 10/04/2024 à(s)
13:39):
> With base stack I can complete restic check successfully
> downloading/reading/checking all files from a "big" remote compressed
> backup.
> Changing it t
65 matches
Mail list logo