I will have to send you a program that you can compile.. it uses the TCP
logging device to
pull data..
I will send you details just to you tomorrow (getting late here for me)
R
> On Sep 25, 2019, at 8:10 PM, vm finance wrote:
>
> Hello Randall,
>
> #1: How do I turn on just TCP logging so I
Hmm
yeah I missed that.. VM’s do not work well when intricate timing is involved..
which it is in HPTS at
least.
I would definitely think about opening up rwnd’s as well I know google
mentioned this in
there work with BBR (rwnd’s were too small both send and recv)
R
> On Sep 25, 2019, at 2:23
> On Sep 25, 2019, at 10:22 AM, vm finance wrote:
>
> Hi Randall, Michael,
>
> I'm trying to run some tests between FreeBSD BBR VM and another CentOS VM but
> don't see BBR performing well. FreeBSD (iperf -c) is transmitting to CentOS
> (iperf -s)
>
> Enable BBR ( sysctl -w net.inet.tcp.fun
There should have been some in the patch. Tomorrow I can send you a tar of
the modules/tcp/bbr Dir.
It’s similar to the rack setup if you can’t wait and want to be adventurous
R
Sent from my iPhone
On Sep 19, 2019, at 7:31 PM, vm finance wrote:
Hi Randall,
I already have tcp_bbr.h and bbr.c
Ahh.. Look in your directory.
You did not create the sub’dirs or put rack.c or bbr.c into the right places
When you load the patch (which was updated Sept 17th and should be different
slightly)
you will end up dropping a Makefile and bbr.c and tcp_bbr.h into the local dir
since
for what every r
You can look in the config I sent.. but here is what
I have added to enable BBR and Rack to be built
*
makeoptions WITH_EXTRA_TCP_STACKS=1
options TCPHPTS
options RATELIMIT
**
So you should
1) Apply the current patch in phabricator
2) edit your config and add the above
To get bbr running you will need to change your kernel config.
Are you building i386 or amd64?
After you have successfully did
1) buildworld
2) buildkernel
3) installkernel
(you can look in UPDATING for instructions .. though the file is long :D)
successfully let me know.. and then I will giv
One other note.. I notice his kernel conf he sent does not have
the right things to get BBR even to attempt to build.
I would suggest using that config for the first steps.. then he must add
the additional tcp stacks and the hpts in order to get bbr/rack and any other
extra stack….
But I would s
Thats great idea Michael.
From the look fo the build log I was sent, his blow-up has nothing to do
with the patches.
He should probably
1) Check out a fresh version of head.
2) Follow the instructions in UPDATING to get a clean build.
— make buildworld
— make buildkernel KERNCONF=his-con
There have been several patches pre-this one that provide
the infrastructure to support BBR.
Release 12.0 will *not* have these patches and will *not* compile it.
I have no intention at this point in doing a MFC of this work.. so if you want
to run BBR you need to run Head
R
> On Sep 17, 2019,
Looking at your make file log I can’t really tell what you are doing.
Its not the BBR or Rack code that is blowing up…
Are you cross compiling?
I have done the old fashioned kernel make
i.e.
cd src/sys/amd64/config
config headvm
cd ../compile/headvm
make cleandepend ; make depend; make -j3
looking
I was at 352408.. let me update and try it
R
> On Sep 17, 2019, at 1:10 PM, Randall Stewart wrote:
>
> Hmm
>
> Did you get the patch I updated too this am?
>
> I have built it both with and without the bbr stack and had no issue.. there
> was
> an issue with KTLS before the update t
Hmm
Did you get the patch I updated too this am?
I have built it both with and without the bbr stack and had no issue.. there was
an issue with KTLS before the update though.
I don’t recognize what you have below there though…
R
> On Sep 17, 2019, at 11:47 AM, vm finance wrote:
>
> Got it -
Pacing is provided by tcp_hpts.c. The current linux patches do not have
to have fq.. they built an alternate means of doing pacing into bbr.
In either case our testing has shown that our pacing is more accurate than
either fq or the internal pacer :)
R
> On Sep 17, 2019, at 11:05 AM, vm finance
You should be able to compile it against the current head. I re-doing that now
(had an
issue with my machine and had to roll it back to a backup).
When I put the patch up on Sept 10th it complied with and without BBR on
whatever
was that rev..
Looking in the commit logs that would have been aro
Ok
Lets try this again with my source changed to my @freebsd.net :-)
Now I am also attaching a patch for you Gleb, this will take some poking to
get in to your NF-head since it incorporates some changes we made earlier.
I think this will fix the problem.. i.e. dealing with two locks in the callo
So
All of our timers in TCP do something like
-
INFO-LOCK
INP_WLOCK
if (inp needs to be dropped) {
drop-it
}
do other work
UNLOCK-INP
UNLOCK-INFO
--
And generally the path “inp needs to be dropped” is rarely taken.
So why don’t we change the procedure to
Hans:
After talking with Gleb he tells me part of your test is to kldunload a module.
Now I think that is the source of the problem.
Probably the cleanup code failed to stop the timer and did the remove.. thus
when the timer expires it blows up.
This is not a callout issue.. I think you need to
Hans:
I don’t think you are getting a 1 back from the callout_reset()..
If the pending bit is set, you get a 1 back. But if you have a race where
the arp-timer is blocked on the lock (held by arp resolve) your going to
have the pending bit off.. since before calling the function the callout
code
If you did that it would change the KPI a bit meaning lots
of thrashing in the code.
And on top of that you now would no longer return 0..
You would get 1 it was restarted or -1 it was not running but is now started.
Makes no sense to me sorry..
R
On Dec 10, 2015, at 7:35 AM, Hans Petter Selask
For callout_stop/drain you get
-1 == Callout as already gone off or is not running (usually the latter) else
the caller iks
not using locking properly or did not lock and check the active()
value (which would have returned not active so no stop
would have been needed);
0 == w
Hans:
Though it would not hurt to add your patch, its not possible
for callout_reset() to return anything but 1 or 0.
Only callout_stop(), callout_drain(), callout_async_drain() can return -1.
So I don’t think that this will fix it.
R
On Dec 4, 2015, at 11:34 AM, Hans Petter Selasky wrote:
>>
David
Yep.. we got that wrong.
If 1 is returned by the submit it means the PCB was lost. If 0 is
returned you unlock as usual.
R
On Jul 21, 2015, at 5:59 PM, David Wolfskill wrote:
> On Tue, Jul 21, 2015 at 03:21:16PM -0500, Eric van Gyzen wrote:
>> ...
So it looks like net swi, leaking s
23 matches
Mail list logo
