(...)
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
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
> 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:
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
> 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
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
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
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
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
> >
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
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
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
On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote:
> ...
> >> It would be so nice that we can have a sysctl tunnable for this patch
> >> so we could do more tests without recompiling kernel.
> > Thanks for testing!
> >
> > @gallatin: can you come up with a patch that is acceptable for
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 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
>
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
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
>
> 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
On Sun, 17 Mar 2024 11:40:54 -0400
"Drew Gallatin" wrote:
> 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
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
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
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
> 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
On Sun, 19 Nov 2023 04:01:01 +0900
Tomoaki AOKI wrote:
> On Sat, 18 Nov 2023 09:50:43 +0100
> tue...@freebsd.org wrote:
>
> > > On Nov 18, 2023, at 00:37, Tomoaki AOKI wrote:
> > >
> > > On Fri, 17 Nov 2023 18:51:05 +0100
> > > tue...@freebsd.org wrote:
> > >
> > >>> On Nov 17, 2023, at
> 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 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
> > 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
> 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:
> 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
> 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
> > 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,
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.
>
> >
> 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
(...)
> 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
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
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
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,
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.
> >
> 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
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:
> 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,
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
> 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
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 rpi4 for
> > poudriere, git, browsing, some torrent and ssh/sftp
> 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 3/12/24 6:39 AM, 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 do for comparison?
I
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)
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,
> 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
W dniu 17.11.2023 o 00:13, tue...@fh-muenster.de pisze:
On Nov 16, 2023, at 17:50, Marek Zarychta wrote:
W dniu 16.11.2023 o 10:13, tue...@freebsd.org pisze:
Dear all,
recently the main branch was changed to build the TCP RACK stack
which is a loadable kernel module, by default:
> 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
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 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
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 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
> 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
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:
> >>>
>
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 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:
>>
On Sat, 18 Nov 2023 09:50:43 +0100
tue...@freebsd.org wrote:
> > On Nov 18, 2023, at 00:37, Tomoaki AOKI wrote:
> >
> > On Fri, 17 Nov 2023 18:51:05 +0100
> > tue...@freebsd.org wrote:
> >
> >>> On Nov 17, 2023, at 17:06, Johan Hendriks wrote:
> >>>
> >>> I am running the rack stack for
> 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
> On Nov 18, 2023, at 00:37, Tomoaki AOKI wrote:
>
> On Fri, 17 Nov 2023 18:51:05 +0100
> tue...@freebsd.org wrote:
>
>>> On Nov 17, 2023, at 17:06, Johan Hendriks wrote:
>>>
>>> I am running the rack stack for quiet some time now on a baremetal machiene
>>> and never had problems.
>>> Also
On Fri, 17 Nov 2023 18:51:05 +0100
tue...@freebsd.org wrote:
> > On Nov 17, 2023, at 17:06, Johan Hendriks wrote:
> >
> > I am running the rack stack for quiet some time now on a baremetal machiene
> > and never had problems.
> > Also use pf. This is a test machine so not a lot happening on
> On Nov 17, 2023, at 17:06, Johan Hendriks wrote:
>
> I am running the rack stack for quiet some time now on a baremetal machiene
> and never had problems.
> Also use pf. This is a test machine so not a lot happening on it.
>
> Are there any thing we can test? Do we have some test scripts we
I am running the rack stack for quiet some time now on a baremetal
machiene and never had problems.
Also use pf. This is a test machine so not a lot happening on it.
Are there any thing we can test? Do we have some test scripts we can run?
Am 2023-11-17 14:29, schrieb void:
On Thu, Nov 16, 2023 at 10:13:05AM +0100, tue...@freebsd.org wrote:
You can load the kernel module using
kldload tcp_rack
You can make the RACK stack the default stack using
sysctl net.inet.tcp.functions_default=rack
Hi, thank you for this.
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
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
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 Thu, Nov 16, 2023 at 10:13:05AM +0100, tue...@freebsd.org wrote:
You can load the kernel module using
kldload tcp_rack
You can make the RACK stack the default stack using
sysctl net.inet.tcp.functions_default=rack
Hi, thank you for this.
> 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
> 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 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:
>>
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 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
W dniu 16.11.2023 o 10:13, tue...@freebsd.org pisze:
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
That's really good news and
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:
> >
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
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
79 matches
Mail list logo
