Re: NET_TCP_SPLIT removal

[Xiang Xiao]

I agreed with Greg that it's bad to give the user a broken feature,
especially for a complex feature like networking.

On Wed, Oct 13, 2021 at 10:51 AM Gregory Nutt  wrote:

> Similarly, I have also advocated the option to disable READ AHEAD
> buffering.  A stack that cannot buffer a packet is not reliable:  If the
> read operation is not in place and waiting for an incoming packet, then the
> packet will be dropped dropped in that case.  Pretty hard to design a
> reliable stack with that kind of behavior.
>
> Again, the counter argument for retaining the option to disable READ AHEAD
> buffering (as with WRITE buffering) is only because it would prevent
> minimum systems that cannot afford a pool of IOBs.
>
> Is it better to have a quality network stack?  Or a small but unreliable
> stack?
>
> On Tue, Oct 12, 2021 at 8:35 PM Gregory Nutt  wrote:
>
> > For people that need some background, this Wikipedia article may be
> > helpful:  https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment.  The
> > SPLIT packet change is intended to work around issues when the unbuffered
> > send is used with a peer that supports RFC 1122.
> >
> > In the unbuffered send case, the send operation blocks until the packet
> is
> > sent and ACKed.  Per RFC 1122, the peer may delay sending the ACK for up
> to
> > 500 Msec.  So the performance of the unbuffered send is abysmal when
> > sending to an RFC 1122 client.
> >
> > The split basically breaks each TCP send into two packets.  RFC 1122 does
> > *require* that an ACK be sent after two packets are received.  If you are
> > seeing different behavior, then those peers are not conforming to RFC
> > 1122.  Perhaps there is some other standard.
> >
> > I think that the unbuffered send logic is generally very bad and I have
> > suggested removing it in the past.  The buffered send performance is much
> > better.  We decided to retain the unbuffered send only because it does
> use
> > less memory since no write buffering is required.
> >
> > I am not 100% sure of this, but I still think that it would be better to
> > remove the unbuffered TCP send logic rather than remove the packet split
> > logic.  I don't see how removing the split makes the unbuffered send
> > better.  It does not fix anything and certainly breaks the RFC 1122 case.
> > The unbuffered TCP send behavior is bad without the split and, according
> to
> > your PR, it is also bad with the split.  But my feeling is not strong so
> > just take that as my 2 cents worth.
> >
> > Greg
> >
> > On Tue, Oct 12, 2021 at 8:10 PM Takashi Yamamoto
> >  wrote:
> >
> >> hi,
> >>
> >> i submitted a PR to remove NET_TCP_SPLIT.
> >> https://github.com/apache/incubator-nuttx/pull/4660
> >>
> >> i'm posting this here because a feature removal should be reviewed by
> >> wider audience.
> >> especially, if you are relying on it, please speak up.
> >>
> >
>

RE: NET_TCP_SPLIT removal

[Alin.Jerpelea]

I think that we should not provide broken features unless they are experimental 

-Original Message-
From: Xiang Xiao  
Sent: den 14 oktober 2021 10:49
To: dev@nuttx.apache.org
Subject: Re: NET_TCP_SPLIT removal

I agreed with Greg that it's bad to give the user a broken feature, especially 
for a complex feature like networking.

On Wed, Oct 13, 2021 at 10:51 AM Gregory Nutt  wrote:

> Similarly, I have also advocated the option to disable READ AHEAD 
> buffering.  A stack that cannot buffer a packet is not reliable:  If 
> the read operation is not in place and waiting for an incoming packet, 
> then the packet will be dropped dropped in that case.  Pretty hard to 
> design a reliable stack with that kind of behavior.
>
> Again, the counter argument for retaining the option to disable READ 
> AHEAD buffering (as with WRITE buffering) is only because it would 
> prevent minimum systems that cannot afford a pool of IOBs.
>
> Is it better to have a quality network stack?  Or a small but 
> unreliable stack?
>
> On Tue, Oct 12, 2021 at 8:35 PM Gregory Nutt  wrote:
>
> > For people that need some background, this Wikipedia article may be
> > helpful:  
> > https://urldefense.com/v3/__https://en.wikipedia.org/wiki/TCP_delaye
> > d_acknowledgment__;!!JmoZiZGBv3RvKRSx!tialRaWS8SoruDjFpeabVMLOKhTRX0ZmTGHapT0vQAy6pb66jXy7suu4AR6CokSoPw$
> >  .  The SPLIT packet change is intended to work around issues when the 
> > unbuffered send is used with a peer that supports RFC 1122.
> >
> > In the unbuffered send case, the send operation blocks until the 
> > packet
> is
> > sent and ACKed.  Per RFC 1122, the peer may delay sending the ACK 
> > for up
> to
> > 500 Msec.  So the performance of the unbuffered send is abysmal when 
> > sending to an RFC 1122 client.
> >
> > The split basically breaks each TCP send into two packets.  RFC 1122 
> > does
> > *require* that an ACK be sent after two packets are received.  If 
> > you are seeing different behavior, then those peers are not 
> > conforming to RFC 1122.  Perhaps there is some other standard.
> >
> > I think that the unbuffered send logic is generally very bad and I 
> > have suggested removing it in the past.  The buffered send 
> > performance is much better.  We decided to retain the unbuffered 
> > send only because it does
> use
> > less memory since no write buffering is required.
> >
> > I am not 100% sure of this, but I still think that it would be 
> > better to remove the unbuffered TCP send logic rather than remove 
> > the packet split logic.  I don't see how removing the split makes 
> > the unbuffered send better.  It does not fix anything and certainly breaks 
> > the RFC 1122 case.
> > The unbuffered TCP send behavior is bad without the split and, 
> > according
> to
> > your PR, it is also bad with the split.  But my feeling is not 
> > strong so just take that as my 2 cents worth.
> >
> > Greg
> >
> > On Tue, Oct 12, 2021 at 8:10 PM Takashi Yamamoto 
> >  wrote:
> >
> >> hi,
> >>
> >> i submitted a PR to remove NET_TCP_SPLIT.
> >> https://urldefense.com/v3/__https://github.com/apache/incubator-nut
> >> tx/pull/4660__;!!JmoZiZGBv3RvKRSx!tialRaWS8SoruDjFpeabVMLOKhTRX0ZmT
> >> GHapT0vQAy6pb66jXy7suu4AR6OGCrEqw$
> >>
> >> i'm posting this here because a feature removal should be reviewed 
> >> by wider audience.
> >> especially, if you are relying on it, please speak up.
> >>
> >
>

Re: FreeBSD / BSD

[Tomasz CEDRO]

On Thu, Oct 14, 2021 at 2:28 AM Nathan Hartman wrote:
> On Tue, Oct 12, 2021 at 12:49 PM Gregory Nutt wrote:
> > > Matias N. made some progress before;
> > > Unified device interface, callback based initialization and devicetree
> > > (DTS) · Issue #3031 · apache/incubator-nuttx (github.com)
> > > 
> > > [RFC] Using devicetree (DTS) to improve board support · Issue #1020 ·
> > > apache/incubator-nuttx (github.com)
> > > 
> >
> > The conversation that I was trying to initiate here is NOT whether these
> > features are good or bad, but to propose a way to create a feature road
> > map for the OS.  Through the established voting process we can determine
> > in advance whether features are needed by the community or not.
>
> I think we need 2 CWIKI pages: Wish List and Road Map.
>
> In Wish List, everyone can go and propose whatever features they'd
> like to see someday. There's no guarantee any of them will be
> implemented, but could serve to get the ideas flowing.
>
> Wish List ideas that gain traction become a [DISCUSS] thread where
> details are hashed out and arguments made, leading to a [VOTE].
>
> Items voted Yes move from Wish List to Road Map.
>
> Items voted No go to /dev/null.
>
> Rinse and repeat :-)

I am not really familiar with CWIKI sorry. I turned all my wiki into
MarkDown files and/or WIKI being part of the repository. Having
separate CWIKI may be easier to use with no mess in the repository, in
that case GitHub offers WIKI and that would be all-in-one-place
approach (easier to find and maintain). In addition GitHub WIKI uses
MD format and it may be easier to copy paste some text into
respository.

GitHub also introduced DISCUSSIONS where wish list ideas could be
introduced, when accepted transferred to WIKI WishList, and then to
the RoadMap if voted up by the developers community. Again this is
all-in-one approach that makes work easier to maintain.

I saw 10.2 release discussion. Release Notes could be part of GH WIKI,
then copy-pasted into release message (uses MD formatting). Also
having ChangeLog file directly in the repository is good for tracking
changes and progress of the project (also uses MD formatting).

> > This prevents misconceptions that arise because a few people are very
> > impassioned and vocal but do not reflect the majority.  This may happen
> > if  the majority are less vocal.  The vocal minority can lead in a path
> > that may not be preferable to the silent majority.  Voting gives a voice
> > to everyone.
> >
> > Similarly we can identify features in advance that ARE needed by the
> > community and make that need visible to potential implementers.
> >
> > If we had such a feature roadmap, we could more easily coordinate the
> > evolution of the OS in an orderly fashion.
>
> Agreed. Furthermore once there's a roadmap that looks reasonable, I'd
> propose to put it on the NuttX website.

Or this could be simply GH WIKI (simpler to maintain closer to the
source code) or copy-paste (more work to maintain).

Have a good day folks :-)

ps/2: Some folks moved away from GitHub to GitLab (open-source) after
Microsoft took over GitHub. Migration is easy, both use MarkDown
formatting. This may be important for risk assessment if someone
considers GH a single point of failure. Both platforms git can be
synchronized too. I am not sure about Issues/Wiki though.

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: FreeBSD / BSD

[Tomasz CEDRO]

On Thu, Oct 14, 2021 at 3:15 PM Tomasz CEDRO wrote:
> On Thu, Oct 14, 2021 at 2:28 AM Nathan Hartman wrote:
> > On Tue, Oct 12, 2021 at 12:49 PM Gregory Nutt wrote:
> > > > Matias N. made some progress before;
> > > > Unified device interface, callback based initialization and devicetree
> > > > (DTS) · Issue #3031 · apache/incubator-nuttx (github.com)
> > > > 
> > > > [RFC] Using devicetree (DTS) to improve board support · Issue #1020 ·
> > > > apache/incubator-nuttx (github.com)
> > > > 
> > >
> > > The conversation that I was trying to initiate here is NOT whether these
> > > features are good or bad, but to propose a way to create a feature road
> > > map for the OS.  Through the established voting process we can determine
> > > in advance whether features are needed by the community or not.

One more thing I forgot to mention.

Democracy as we see today is vulnerable to manipulation by "mass
migration". I saw many good open-source projects being hurt by "new
fancy trends" to the point where solid old developers left the project
and it was taken over by the "progress is achieved by enforcing
changes"^TM* folks simply removing or breaking stuff that has been
there for years and worked well.

In technology world Meritocracy seems better approach. Therefore
Voting Rank seems a reasonable solution. Developers with more commits
should have higher Rank than people that did commit less or anything,
so the voting is balanced by people that have better insight and
understanding of the internals and current implementation. I am not
sure how the formula should look like, I am just throwing the idea
that people who created more should have more to say :-)

*) I heard that "according to Microsoft progress is achieved by
enforcing changes" for the first time from the UI/UX folk that removed
Menu from Toolbar in GIMP around 2008 with no backward compatibility
option, then they put that Menu in a separate Window, and because
there was nothing yet in that window they called it "No Window" ;-)
That broke my current workflow where I had one toolbar for many
windows on many screens but enforced new UX vision that we know today.
Another example is Linux Kernel API change around 2.4.10 (I was using
it since 2.0.36) with every minor release that made me consider that
OS self-incompatible and pushed me towards FreeBSD for good. Another
example is Blender Player removal from 2.90 release with no
alternative or even plan for a replacement. Not to mention JavaScript
world where things change day by day. I just wonder if those people
ever heard about compliance and maintenance, or just want to generate
long term support contracts.

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: FreeBSD / BSD

[Alan Carvalho de Assis]

On 10/14/21, Tomasz CEDRO  wrote:
> On Thu, Oct 14, 2021 at 3:15 PM Tomasz CEDRO wrote:
>> On Thu, Oct 14, 2021 at 2:28 AM Nathan Hartman wrote:
>> > On Tue, Oct 12, 2021 at 12:49 PM Gregory Nutt wrote:
>> > > > Matias N. made some progress before;
>> > > > Unified device interface, callback based initialization and
>> > > > devicetree
>> > > > (DTS) · Issue #3031 · apache/incubator-nuttx (github.com)
>> > > > 
>> > > > [RFC] Using devicetree (DTS) to improve board support · Issue #1020
>> > > > ·
>> > > > apache/incubator-nuttx (github.com)
>> > > > 
>> > >
>> > > The conversation that I was trying to initiate here is NOT whether
>> > > these
>> > > features are good or bad, but to propose a way to create a feature
>> > > road
>> > > map for the OS.  Through the established voting process we can
>> > > determine
>> > > in advance whether features are needed by the community or not.
>
> One more thing I forgot to mention.
>
> Democracy as we see today is vulnerable to manipulation by "mass
> migration". I saw many good open-source projects being hurt by "new
> fancy trends" to the point where solid old developers left the project
> and it was taken over by the "progress is achieved by enforcing
> changes"^TM* folks simply removing or breaking stuff that has been
> there for years and worked well.
>
> In technology world Meritocracy seems better approach. Therefore
> Voting Rank seems a reasonable solution. Developers with more commits
> should have higher Rank than people that did commit less or anything,
> so the voting is balanced by people that have better insight and
> understanding of the internals and current implementation. I am not
> sure how the formula should look like, I am just throwing the idea
> that people who created more should have more to say :-)
>
> *) I heard that "according to Microsoft progress is achieved by
> enforcing changes" for the first time from the UI/UX folk that removed
> Menu from Toolbar in GIMP around 2008 with no backward compatibility
> option, then they put that Menu in a separate Window, and because
> there was nothing yet in that window they called it "No Window" ;-)
> That broke my current workflow where I had one toolbar for many
> windows on many screens but enforced new UX vision that we know today.
> Another example is Linux Kernel API change around 2.4.10 (I was using
> it since 2.0.36) with every minor release that made me consider that
> OS self-incompatible and pushed me towards FreeBSD for good. Another
> example is Blender Player removal from 2.90 release with no
> alternative or even plan for a replacement. Not to mention JavaScript
> world where things change day by day. I just wonder if those people
> ever heard about compliance and maintenance, or just want to generate
> long term support contracts.
>

Although I agree with out about Meritocracy, this is not the "Apache Way".

BTW I think you are talking Blender Game Engine, it became a separated project:

There is more info here:

https://www.youtube.com/watch?v=cBhEgQVpv2M

BR,

Alan

Re: FreeBSD / BSD

[Tomasz CEDRO]

On Thu, Oct 14, 2021 at 4:14 PM Alan Carvalho de Assis wrote:
> On 10/14/21, Tomasz CEDRO  wrote:
> > On Thu, Oct 14, 2021 at 3:15 PM Tomasz CEDRO wrote:
> >> On Thu, Oct 14, 2021 at 2:28 AM Nathan Hartman wrote:
> >> > On Tue, Oct 12, 2021 at 12:49 PM Gregory Nutt wrote:
> >> > > > Matias N. made some progress before;
> >> > > > Unified device interface, callback based initialization and
> >> > > > devicetree
> >> > > > (DTS) · Issue #3031 · apache/incubator-nuttx (github.com)
> >> > > > 
> >> > > > [RFC] Using devicetree (DTS) to improve board support · Issue #1020
> >> > > > ·
> >> > > > apache/incubator-nuttx (github.com)
> >> > > > 
> >> > >
> >> > > The conversation that I was trying to initiate here is NOT whether
> >> > > these
> >> > > features are good or bad, but to propose a way to create a feature
> >> > > road
> >> > > map for the OS.  Through the established voting process we can
> >> > > determine
> >> > > in advance whether features are needed by the community or not.
> >
> > One more thing I forgot to mention.
> >
> > Democracy as we see today is vulnerable to manipulation by "mass
> > migration". I saw many good open-source projects being hurt by "new
> > fancy trends" to the point where solid old developers left the project
> > and it was taken over by the "progress is achieved by enforcing
> > changes"^TM* folks simply removing or breaking stuff that has been
> > there for years and worked well.
> >
> > In technology world Meritocracy seems better approach. Therefore
> > Voting Rank seems a reasonable solution. Developers with more commits
> > should have higher Rank than people that did commit less or anything,
> > so the voting is balanced by people that have better insight and
> > understanding of the internals and current implementation. I am not
> > sure how the formula should look like, I am just throwing the idea
> > that people who created more should have more to say :-)
> >
> > *) I heard that "according to Microsoft progress is achieved by
> > enforcing changes" for the first time from the UI/UX folk that removed
> > Menu from Toolbar in GIMP around 2008 with no backward compatibility
> > option, then they put that Menu in a separate Window, and because
> > there was nothing yet in that window they called it "No Window" ;-)
> > That broke my current workflow where I had one toolbar for many
> > windows on many screens but enforced new UX vision that we know today.
> > Another example is Linux Kernel API change around 2.4.10 (I was using
> > it since 2.0.36) with every minor release that made me consider that
> > OS self-incompatible and pushed me towards FreeBSD for good. Another
> > example is Blender Player removal from 2.90 release with no
> > alternative or even plan for a replacement. Not to mention JavaScript
> > world where things change day by day. I just wonder if those people
> > ever heard about compliance and maintenance, or just want to generate
> > long term support contracts.
> >
>
> Although I agree with out about Meritocracy, this is not the "Apache Way".

Okay :-)


> BTW I think you are talking Blender Game Engine, it became a separated 
> project:
> There is more info here:
> https://www.youtube.com/watch?v=cBhEgQVpv2M

I know this one, its a fork of 2.90+ with BGE rewrite, unfortunately
it is not backward compatible, so I stick to old Blender. Godot /
Armory is the way to go for new stuff. Blender became just a graphics
tool, road is closed for all-in-one scientific simulations with Python
+ 3D + VR + embedded.

https://github.com/UPBGE/upbge/issues/1082
https://github.com/sambler/sambler-redports/tree/master/graphics

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: FreeBSD / BSD

[Gregory Nutt]

Democracy as we see today is vulnerable to manipulation by "mass
migration". I saw many good open-source projects being hurt by "new
fancy trends" to the point where solid old developers left the project
and it was taken over by the "progress is achieved by enforcing
changes"^TM* folks simply removing or breaking stuff that has been
there for years and worked well.


In all Apache projects, decisions are made a democratic vote by members 
of the PPMC (Podling Project Management Committee):  +1 = in favor, -1 = 
opposed, 0 = no opinion.  Normally votes have some hysteresis to avoid 
wild changes; normally 3 more +1 votes than -1 votes are required to get 
a change through.  So it is basically a democratic but one that requires 
close to unanimous agreed.


Hmm... actually I just checked.  That is not true for code modifications 
as we are talking about here.  One -1 vote is a veto and blocks the code 
change:  "A -1 vote by a qualified voter stops a code-modification 
proposal in its tracks. This constitutes a veto, and it cannot be 
overruled nor overridden by anyone." 
https://www.apache.org/foundation/voting.html .  We have not been 
following that rule.


I would probably vote -1 on most code modifications that do not clearly 
benefit the community or that cause excessive turbulence.

Re: FreeBSD / BSD

[Tomasz CEDRO]

On Thu, Oct 14, 2021 at 4:48 PM Gregory Nutt wrote:
> >> Democracy as we see today is vulnerable to manipulation by "mass
> >> migration". I saw many good open-source projects being hurt by "new
> >> fancy trends" to the point where solid old developers left the project
> >> and it was taken over by the "progress is achieved by enforcing
> >> changes"^TM* folks simply removing or breaking stuff that has been
> >> there for years and worked well.
>
> In all Apache projects, decisions are made a democratic vote by members
> of the PPMC (Podling Project Management Committee):  +1 = in favor, -1 =
> opposed, 0 = no opinion.  Normally votes have some hysteresis to avoid
> wild changes; normally 3 more +1 votes than -1 votes are required to get
> a change through.  So it is basically a democratic but one that requires
> close to unanimous agreed.
>
> Hmm... actually I just checked.  That is not true for code modifications
> as we are talking about here.  One -1 vote is a veto and blocks the code
> change:  "A -1 vote by a qualified voter stops a code-modification
> proposal in its tracks. This constitutes a veto, and it cannot be
> overruled nor overridden by anyone."
> https://www.apache.org/foundation/voting.html .  We have not been
> following that rule.
>
> I would probably vote -1 on most code modifications that do not clearly
> benefit the community or that cause excessive turbulence.

Thank you Gregory! Rules seems to be written down already :-)

This -1,0,+1 seems reasonable scale. -1 veto also seems sensible
assuming voter can change it to 0 or +1 after requested modifications
are introduced. At least 3x +1 to accept change is also very good
option.

The "qualified voter" to veto may need some more explanation because
it does not seem to be described in detail who exactly is the
"qualified voter". As stated in Binding Votes section "Who can vote
is, to some extent, a community-specific thing. PMC members have
formally binding votes, but in general communities encourage all their
members to vote, even if their votes are only advisory.".

Being member of PMC / PPMC seems to be the kind of Voting Rank I was
describing.. except it is more bureaucratic / social based rather than
result based.. because it depends on the membership rather than
overall lines of code added to the project.. on the other hand input
to the project may be the door opener to PMC :-)

Assuming core developers are PMC and everyone else can also vote,
while PMC can veto, then solution seems to be in place already :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: FreeBSD / BSD

[Gregory Nutt]

Being member of PMC / PPMC seems to be the kind of Voting Rank I was
describing.. except it is more bureaucratic / social based rather than
result based.. because it depends on the membership rather than
overall lines of code added to the project.. on the other hand input
to the project may be the door opener to PMC :-)


There are committers and PMC members.  The former are purely technical 
in there role and the latter have additional management commitments and 
have binding votes.  In order to be either, you have to have an 
established track record of contribution to the project.


For this reason, the ASF considers itself a meritocracy:

https://www.apache.org/foundation/how-it-works.html#meritocracy
https://blogs.apache.org/foundation/entry/success-at-apache-meritocracy


Assuming core developers are PMC and everyone else can also vote,
while PMC can veto, then solution seems to be in place already :-)

Re: FreeBSD / BSD

[Gregory Nutt]

Being member of PMC / PPMC seems to be the kind of Voting Rank I was
describing.. except it is more bureaucratic / social based rather than
result based.. because it depends on the membership rather than
overall lines of code added to the project.. on the other hand input
to the project may be the door opener to PMC :-)


There are committers and PMC members.  The former are purely technical 
in there role and the latter have additional management commitments 
and have binding votes.  In order to be either, you have to have an 
established track record of contribution to the project.


For this reason, the ASF considers itself a meritocracy:

https://www.apache.org/foundation/how-it-works.html#meritocracy
https://blogs.apache.org/foundation/entry/success-at-apache-meritocracy 


I know you are familiar with the Linux Foundation from your prior work 
with the Zephyr.  The Linux Foundation and the ASF are both 
not-for-profit organizations, but they different significantly in their 
legal organizations.  I forget the non-project corporation types but 
basically, the Linux Foundation is dedicated to free business 
development.  Projects are controlled through management teams composed 
of businesses, usually by paying a fee and getting power within the 
project based upon the amount that the business paid (Silver, Gold, 
Platinum levels for example).


The ASF is a different kind of not-for-profit organization, it is 
dedicated to the people who use the software project, not to 
businesses.  So for the ASF it is the user community that matters, not 
the businesses that use the software.  An ASF project is controlled by 
individuals in the community that have made significant contributions to 
the project.  You will often hear ASF people say "Community over code."  
(I personally like code more that people, but that is just me).

Re: FreeBSD / BSD

[Gregory Nutt]

 The Linux Foundation and the ASF are both not-for-profit 
organizations, but they different significantly in their legal 
organizations.  I forget the non-project corporation types but 
basically, the Linux Foundation is dedicated to free business 
development.  Projects are controlled through management teams 
composed of businesses, usually by paying a fee and getting power 
within the project based upon the amount that the business paid 
(Silver, Gold, Platinum levels for example).


The ASF is a different kind of not-for-profit organization, it is 
dedicated to the people who use the software project, not to 
businesses.  So for the ASF it is the user community that matters, not 
the businesses that use the software.  An ASF project is controlled by 
individuals in the community that have made significant contributions 
to the project.  You will often hear ASF people say "Community over 
code."  (I personally like code more that people, but that is just me).


Here is the missing details:

Linux Foundation is an IRS 501(c)(6) nonprofit organization and the 
Apache Software Foundation is an IRS 501(c)(3) nonprofit organization.  
According to 
https://www.charitynavigator.org/index.cfm?bay=content.view&cpid=1559:


 * 501(c)(3):  Religious, Educational, Charitable, Scientific,
   Literary, Testing for Public Safety, to Foster National or
   International Amateur Sports Competition, or Prevention of Cruelty
   to Children or Animals Organizations
 * 501(c)(6):  Business Leagues, Chambers of Commerce, Real Estate
   Boards, etc.

Basically community first vs. business first.

Re: FreeBSD / BSD

[Gregory Nutt]

 The Linux Foundation and the ASF are both not-for-profit 
organizations, but they different significantly in their legal 
organizations.  I forget the non-project corporation types but 
basically, the Linux Foundation is dedicated to free business 
development.  Projects are controlled through management teams 
composed of businesses, usually by paying a fee and getting power 
within the project based upon the amount that the business paid 
(Silver, Gold, Platinum levels for example).


The ASF is a different kind of not-for-profit organization, it is 
dedicated to the people who use the software project, not to 
businesses.  So for the ASF it is the user community that matters, 
not the businesses that use the software.  An ASF project is 
controlled by individuals in the community that have made significant 
contributions to the project.  You will often hear ASF people say 
"Community over code."  (I personally like code more that people, but 
that is just me).


Here is the missing details:

Linux Foundation is an IRS 501(c)(6) nonprofit organization and the 
Apache Software Foundation is an IRS 501(c)(3) nonprofit 
organization.  According to 
https://www.charitynavigator.org/index.cfm?bay=content.view&cpid=1559:


  * 501(c)(3):  Religious, Educational, Charitable, Scientific,
Literary, Testing for Public Safety, to Foster National or
International Amateur Sports Competition, or Prevention of Cruelty
to Children or Animals Organizations
  * 501(c)(6):  Business Leagues, Chambers of Commerce, Real Estate
Boards, etc.

Basically community first vs. business first.


One more anecdote then I promise to STFU

As most of you know, Xiaomi sponsored and advocated NuttX to join the 
ASF.  Xiaomi have been great partners and, despite my leeriness of 
businesses, it has been a pleasure working with them.


But a couple of years prior to that, Samsung sponsored NuttX in a 
similar way to join the Linux Foundation.  After a few weeks of 
discussions, I realized that what Samsung was advocating was not in the 
interests of the project but served only Samsung and I discontinued that 
conversation.  One good thing that came from that was a clarification of 
my values and what values are necessary to retain in the project in 
order for me to relinquish control of it to others.  I summarized all of 
those things in the top-level INVIOLABLES.md which is essential the 
"contract" under which I gave the project away.  Most of the items in 
that list are things that Samsung wanted to change:  They did not want 
to follow the standard POSIX/Unix OS interface, they wanted to change 
the coding style, they only wanted to support ARM with GCC under Linux, 
they wanted to rebrand the project to use a Samsung marketing name, ..


That all makes sense if you understand the fundamental differences 
between the Linux Foundation and the ASF.

Re: NET_TCP_SPLIT removal

[Alexander Lunev]

Hi Gregory,

> In the unbuffered send case, the send operation blocks until the
> packet is
> sent and ACKed.  Per RFC 1122, the peer may delay sending the ACK for
> up to
> 500 Msec.  So the performance of the unbuffered send is abysmal when
> sending to an RFC 1122 client.

Why does the send operation block?
As I can see in the source code of the unbuffered send operation, TCP
packets are sent w/o waiting for ACKing each sent packet. The packets
are sent from NuttX until the remote TCP receiver's window covers the
total size of not acknowledged sent data.

> I think that the unbuffered send logic is generally very bad and I
> have
> suggested removing it in the past.  The buffered send performance is
> much
> better.  We decided to retain the unbuffered send only because it
> does use
> less memory since no write buffering is required.

Currently I'm using "unbuffered" send mode as in my case it
surprisingly provides twice as high throughput as "buffered" one.
Though, I initially expected that "buffered" send mode should have
better performance compared to "unbuffered" one.

BTW, could you please say where I could read that discussion about
removing / retaining the unbuffered send in more details?

Best regards,
Alexander Lunev.


On Thu, 2021-10-14 at 16:49 +0800, Gregory Nutt wrote:
> For people that need some background, this Wikipedia article may be
> helpful:  https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment.  
> The
> SPLIT packet change is intended to work around issues when the
> unbuffered
> send is used with a peer that supports RFC 1122.
> 
> In the unbuffered send case, the send operation blocks until the
> packet is
> sent and ACKed.  Per RFC 1122, the peer may delay sending the ACK for
> up to
> 500 Msec.  So the performance of the unbuffered send is abysmal when
> sending to an RFC 1122 client.
> 
> The split basically breaks each TCP send into two packets.  RFC 1122
> does
> *require* that an ACK be sent after two packets are received.  If you
> are
> seeing different behavior, then those peers are not conforming to RFC
> 1122.  Perhaps there is some other standard.
> 
> I think that the unbuffered send logic is generally very bad and I
> have
> suggested removing it in the past.  The buffered send performance is
> much
> better.  We decided to retain the unbuffered send only because it
> does use
> less memory since no write buffering is required.
> 
> I am not 100% sure of this, but I still think that it would be better
> to
> remove the unbuffered TCP send logic rather than remove the packet
> split
> logic.  I don't see how removing the split makes the unbuffered send
> better.  It does not fix anything and certainly breaks the RFC 1122
> case.
> The unbuffered TCP send behavior is bad without the split and,
> according to
> your PR, it is also bad with the split.  But my feeling is not strong
> so
> just take that as my 2 cents worth.
> 
> Greg
> 
> On Tue, Oct 12, 2021 at 8:10 PM Takashi Yamamoto
>  wrote:
> 
> > hi,
> > 
> > i submitted a PR to remove NET_TCP_SPLIT.
> > https://github.com/apache/incubator-nuttx/pull/4660
> > 
> > i'm posting this here because a feature removal should be reviewed
> > by
> > wider audience.
> > especially, if you are relying on it, please speak up.
> > 
> 
> 

Re: FreeBSD / BSD

[Nathan Hartman]

On Thu, Oct 14, 2021 at 12:23 PM Gregory Nutt  wrote:

>
> >
> >>  The Linux Foundation and the ASF are both not-for-profit
> >> organizations, but they different significantly in their legal
> >> organizations.  I forget the non-project corporation types but
> >> basically, the Linux Foundation is dedicated to free business
> >> development.  Projects are controlled through management teams
> >> composed of businesses, usually by paying a fee and getting power
> >> within the project based upon the amount that the business paid
> >> (Silver, Gold, Platinum levels for example).
> >>
> >> The ASF is a different kind of not-for-profit organization, it is
> >> dedicated to the people who use the software project, not to
> >> businesses.  So for the ASF it is the user community that matters,
> >> not the businesses that use the software.  An ASF project is
> >> controlled by individuals in the community that have made significant
> >> contributions to the project.  You will often hear ASF people say
> >> "Community over code."  (I personally like code more that people, but
> >> that is just me).
> >
> > Here is the missing details:
> >
> > Linux Foundation is an IRS 501(c)(6) nonprofit organization and the
> > Apache Software Foundation is an IRS 501(c)(3) nonprofit
> > organization.  According to
> > https://www.charitynavigator.org/index.cfm?bay=content.view&cpid=1559:
> >
> >   * 501(c)(3):  Religious, Educational, Charitable, Scientific,
> > Literary, Testing for Public Safety, to Foster National or
> > International Amateur Sports Competition, or Prevention of Cruelty
> > to Children or Animals Organizations
> >   * 501(c)(6):  Business Leagues, Chambers of Commerce, Real Estate
> > Boards, etc.
> >
> > Basically community first vs. business first.
> >
> One more anecdote then I promise to STFU
>
> As most of you know, Xiaomi sponsored and advocated NuttX to join the
> ASF.  Xiaomi have been great partners and, despite my leeriness of
> businesses, it has been a pleasure working with them.
>
> But a couple of years prior to that, Samsung sponsored NuttX in a
> similar way to join the Linux Foundation.  After a few weeks of
> discussions, I realized that what Samsung was advocating was not in the
> interests of the project but served only Samsung and I discontinued that
> conversation.  One good thing that came from that was a clarification of
> my values and what values are necessary to retain in the project in
> order for me to relinquish control of it to others.  I summarized all of
> those things in the top-level INVIOLABLES.md which is essential the
> "contract" under which I gave the project away.  Most of the items in
> that list are things that Samsung wanted to change:  They did not want
> to follow the standard POSIX/Unix OS interface, they wanted to change
> the coding style, they only wanted to support ARM with GCC under Linux,
> they wanted to rebrand the project to use a Samsung marketing name, ..
>
> That all makes sense if you understand the fundamental differences
> between the Linux Foundation and the ASF.
>
>
They could fork the code and do with the fork whatever they'd like provided
they respect the license, but I certainly hope that (original) NuttX always
remains POSIX-like/Unix-like, with support for multiple architectures,
multiple compilers, ... These features are among the biggest reasons I've
adopted NuttX. Getting rid of them would defeat the whole purpose!

Cheers,
Nathan

Re: NET_TCP_SPLIT removal

[Gregory Nutt]

> Why does the send operation block

It has to, at least for TCP.  The data resides in a user provided buffered
.. that is why it is unbuffered.  In TCP, it may need to retransmit if the
data is not ACKed.  Hence the user buffer must stay intact until the ACK is
received.

The fully buffered logic does not have to wait for the ACK but can return
as soon as the data is copied out of the user buffer.

On Thu, Oct 14, 2021 at 12:54 PM Alexander Lunev
 wrote:

> Hi Gregory,
>
> > In the unbuffered send case, the send operation blocks until the
> > packet is
> > sent and ACKed.  Per RFC 1122, the peer may delay sending the ACK for
> > up to
> > 500 Msec.  So the performance of the unbuffered send is abysmal when
> > sending to an RFC 1122 client.
>
> Why does the send operation block?
> As I can see in the source code of the unbuffered send operation, TCP
> packets are sent w/o waiting for ACKing each sent packet. The packets
> are sent from NuttX until the remote TCP receiver's window covers the
> total size of not acknowledged sent data.
>
> > I think that the unbuffered send logic is generally very bad and I
> > have
> > suggested removing it in the past.  The buffered send performance is
> > much
> > better.  We decided to retain the unbuffered send only because it
> > does use
> > less memory since no write buffering is required.
>
> Currently I'm using "unbuffered" send mode as in my case it
> surprisingly provides twice as high throughput as "buffered" one.
> Though, I initially expected that "buffered" send mode should have
> better performance compared to "unbuffered" one.
>
> BTW, could you please say where I could read that discussion about
> removing / retaining the unbuffered send in more details?
>
> Best regards,
> Alexander Lunev.
>
>
> On Thu, 2021-10-14 at 16:49 +0800, Gregory Nutt wrote:
> > For people that need some background, this Wikipedia article may be
> > helpful:  https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment.
> > The
> > SPLIT packet change is intended to work around issues when the
> > unbuffered
> > send is used with a peer that supports RFC 1122.
> >
> > In the unbuffered send case, the send operation blocks until the
> > packet is
> > sent and ACKed.  Per RFC 1122, the peer may delay sending the ACK for
> > up to
> > 500 Msec.  So the performance of the unbuffered send is abysmal when
> > sending to an RFC 1122 client.
> >
> > The split basically breaks each TCP send into two packets.  RFC 1122
> > does
> > *require* that an ACK be sent after two packets are received.  If you
> > are
> > seeing different behavior, then those peers are not conforming to RFC
> > 1122.  Perhaps there is some other standard.
> >
> > I think that the unbuffered send logic is generally very bad and I
> > have
> > suggested removing it in the past.  The buffered send performance is
> > much
> > better.  We decided to retain the unbuffered send only because it
> > does use
> > less memory since no write buffering is required.
> >
> > I am not 100% sure of this, but I still think that it would be better
> > to
> > remove the unbuffered TCP send logic rather than remove the packet
> > split
> > logic.  I don't see how removing the split makes the unbuffered send
> > better.  It does not fix anything and certainly breaks the RFC 1122
> > case.
> > The unbuffered TCP send behavior is bad without the split and,
> > according to
> > your PR, it is also bad with the split.  But my feeling is not strong
> > so
> > just take that as my 2 cents worth.
> >
> > Greg
> >
> > On Tue, Oct 12, 2021 at 8:10 PM Takashi Yamamoto
> >  wrote:
> >
> > > hi,
> > >
> > > i submitted a PR to remove NET_TCP_SPLIT.
> > > https://github.com/apache/incubator-nuttx/pull/4660
> > >
> > > i'm posting this here because a feature removal should be reviewed
> > > by
> > > wider audience.
> > > especially, if you are relying on it, please speak up.
> > >
> >
> >
>
>

Re: NET_TCP_SPLIT removal

[Gregory Nutt]

> Currently I'm using "unbuffered" send mode as in my case it
> surprisingly provides twice as high throughput  as "buffered" one.
> Though, I initially expected that "buffered" send mode should have
> better performance compared to "unbuffered" one

It should not be faster.  I suspect that is some artifact of a bad
"buffered configuration"  It blocks waiting for ACKs and when communicating
with RFC 1122 peers it cannot send packets faster than twp per second.

The application is also blocked and can do nothing until the ACKs are
received.  So any possible performance benefits from concurrent operation
is lost.  It is generally not a very good implementation without buffering.

Re: NET_TCP_SPLIT removal

[Gregory Nutt]

> > Currently I'm using "unbuffered" send mode as in my case it
> > surprisingly provides twice as high throughput  as "buffered" one.
> > Though, I initially expected that "buffered" send mode should have
> > better performance compared to "unbuffered" one
>
> It should not be faster.  I suspect that is some artifact of a bad
> "buffered configuration" ...
>

For example, if your configuration does not provide a sufficient number of
IOBs, then the performance of the buffered case will be bad because it will
be constantly blocked waiting for free IOBs.  You really have to carefully
tune the buffering to get the performance you want.

Re: NET_TCP_SPLIT removal

[Alexander Lunev]

Yes, from a user’s point of view the unbuffered send operation is
blocking. I just meant that unbuffered send (the kernel side) does not
wait for each TCP packet to be acknowledged.
E.g. apps/netutils/iperf uses a user buffer with size of 16384 bytes.
While these 16384 bytes are being sent, the performance is fine. The
performance is reduced only at the end of the buffer because the TCP
stack waits for the ACK acknowledging the last segment of the buffer.
I want to say that unbuffered send mode does not look bad to me for
some cases.


On Thu, 2021-10-14 at 13:25 -0600, Gregory Nutt wrote:
> > Why does the send operation block
> 
> It has to, at least for TCP.  The data resides in a user provided
> buffered
> .. that is why it is unbuffered.  In TCP, it may need to retransmit
> if the
> data is not ACKed.  Hence the user buffer must stay intact until the
> ACK is
> received.
> 
> The fully buffered logic does not have to wait for the ACK but can
> return
> as soon as the data is copied out of the user buffer.
> 
> On Thu, Oct 14, 2021 at 12:54 PM Alexander Lunev
>  wrote:
> 
> > Hi Gregory,
> > 
> > > In the unbuffered send case, the send operation blocks until the
> > > packet is
> > > sent and ACKed.  Per RFC 1122, the peer may delay sending the ACK
> > > for
> > > up to
> > > 500 Msec.  So the performance of the unbuffered send is abysmal
> > > when
> > > sending to an RFC 1122 client.
> > 
> > Why does the send operation block?
> > As I can see in the source code of the unbuffered send operation,
> > TCP
> > packets are sent w/o waiting for ACKing each sent packet. The
> > packets
> > are sent from NuttX until the remote TCP receiver's window covers
> > the
> > total size of not acknowledged sent data.
> > 
> > > I think that the unbuffered send logic is generally very bad and
> > > I
> > > have
> > > suggested removing it in the past.  The buffered send performance
> > > is
> > > much
> > > better.  We decided to retain the unbuffered send only because it
> > > does use
> > > less memory since no write buffering is required.
> > 
> > Currently I'm using "unbuffered" send mode as in my case it
> > surprisingly provides twice as high throughput as "buffered" one.
> > Though, I initially expected that "buffered" send mode should have
> > better performance compared to "unbuffered" one.
> > 
> > BTW, could you please say where I could read that discussion about
> > removing / retaining the unbuffered send in more details?
> > 
> > Best regards,
> > Alexander Lunev.
> > 
> > 
> > On Thu, 2021-10-14 at 16:49 +0800, Gregory Nutt wrote:
> > > For people that need some background, this Wikipedia article may
> > > be
> > > helpful:  
> > > https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment.
> > > The
> > > SPLIT packet change is intended to work around issues when the
> > > unbuffered
> > > send is used with a peer that supports RFC 1122.
> > > 
> > > In the unbuffered send case, the send operation blocks until the
> > > packet is
> > > sent and ACKed.  Per RFC 1122, the peer may delay sending the ACK
> > > for
> > > up to
> > > 500 Msec.  So the performance of the unbuffered send is abysmal
> > > when
> > > sending to an RFC 1122 client.
> > > 
> > > The split basically breaks each TCP send into two packets.  RFC
> > > 1122
> > > does
> > > *require* that an ACK be sent after two packets are received.  If
> > > you
> > > are
> > > seeing different behavior, then those peers are not conforming to
> > > RFC
> > > 1122.  Perhaps there is some other standard.
> > > 
> > > I think that the unbuffered send logic is generally very bad and
> > > I
> > > have
> > > suggested removing it in the past.  The buffered send performance
> > > is
> > > much
> > > better.  We decided to retain the unbuffered send only because it
> > > does use
> > > less memory since no write buffering is required.
> > > 
> > > I am not 100% sure of this, but I still think that it would be
> > > better
> > > to
> > > remove the unbuffered TCP send logic rather than remove the
> > > packet
> > > split
> > > logic.  I don't see how removing the split makes the unbuffered
> > > send
> > > better.  It does not fix anything and certainly breaks the RFC
> > > 1122
> > > case.
> > > The unbuffered TCP send behavior is bad without the split and,
> > > according to
> > > your PR, it is also bad with the split.  But my feeling is not
> > > strong
> > > so
> > > just take that as my 2 cents worth.
> > > 
> > > Greg
> > > 
> > > On Tue, Oct 12, 2021 at 8:10 PM Takashi Yamamoto
> > >  wrote:
> > > 
> > > > hi,
> > > > 
> > > > i submitted a PR to remove NET_TCP_SPLIT.
> > > > https://github.com/apache/incubator-nuttx/pull/4660
> > > > 
> > > > i'm posting this here because a feature removal should be
> > > > reviewed
> > > > by
> > > > wider audience.
> > > > especially, if you are relying on it, please speak up.
> > > > 

Re: FreeBSD / BSD

[Tomasz CEDRO]

On Thu, Oct 14, 2021 at 5:48 PM Gregory Nutt wrote:
> > Being member of PMC / PPMC seems to be the kind of Voting Rank I was
> > describing.. except it is more bureaucratic / social based rather than
> > result based.. because it depends on the membership rather than
> > overall lines of code added to the project.. on the other hand input
> > to the project may be the door opener to PMC :-)
>
> There are committers and PMC members.  The former are purely technical
> in there role and the latter have additional management commitments and
> have binding votes.  In order to be either, you have to have an
> established track record of contribution to the project.
>
> For this reason, the ASF considers itself a meritocracy:
>
> https://www.apache.org/foundation/how-it-works.html#meritocracy
> https://blogs.apache.org/foundation/entry/success-at-apache-meritocracy

Bingo! Thank you Gregory :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: FreeBSD / BSD

[Tomasz CEDRO]

On Thu, Oct 14, 2021 at 5:56 PM Gregory Nutt wrote:
> >> Being member of PMC / PPMC seems to be the kind of Voting Rank I was
> >> describing.. except it is more bureaucratic / social based rather than
> >> result based.. because it depends on the membership rather than
> >> overall lines of code added to the project.. on the other hand input
> >> to the project may be the door opener to PMC :-)
> >
> > There are committers and PMC members.  The former are purely technical
> > in there role and the latter have additional management commitments
> > and have binding votes.  In order to be either, you have to have an
> > established track record of contribution to the project.
> >
> > For this reason, the ASF considers itself a meritocracy:
> >
> > https://www.apache.org/foundation/how-it-works.html#meritocracy
> > https://blogs.apache.org/foundation/entry/success-at-apache-meritocracy
>
> I know you are familiar with the Linux Foundation from your prior work
> with the Zephyr.  The Linux Foundation and the ASF are both
> not-for-profit organizations, but they different significantly in their
> legal organizations.  I forget the non-project corporation types but
> basically, the Linux Foundation is dedicated to free business
> development.  Projects are controlled through management teams composed
> of businesses, usually by paying a fee and getting power within the
> project based upon the amount that the business paid (Silver, Gold,
> Platinum levels for example).
>
> The ASF is a different kind of not-for-profit organization, it is
> dedicated to the people who use the software project, not to
> businesses.  So for the ASF it is the user community that matters, not
> the businesses that use the software.  An ASF project is controlled by
> individuals in the community that have made significant contributions to
> the project.  You will often hear ASF people say "Community over code."
> (I personally like code more that people, but that is just me).

I was wondering why Apache not Linux Foundation was chosen for NuttX
and I got the answer even before I asked the question again thank you
Gregory :-) :-) It will be nice to learn and watch both approaches at
work :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: FreeBSD / BSD

[Gregory Nutt]

 > ,,, I certainly hope that (original) NuttX always
> remains POSIX-like/Unix-like, with support for multiple architectures,
> multiple compilers, ... These features are among the biggest reasons I've
> adopted NuttX. Getting rid of them would defeat the whole purpose!

That is why the INVIOLABLES are so critical.  It is only those few
sentences that keep the project on track and faithful to its values.  In a
democratic environment like Apache projects, it could very easily lose its
core values:  Dedication to standards, modular design, community over
business, etc.

Re: FreeBSD / BSD

[Tomasz CEDRO]

On Thu, Oct 14, 2021 at 9:11 PM Nathan Hartman wrote:
> On Thu, Oct 14, 2021 at 12:23 PM Gregory Nutt wrote:
> > >>  The Linux Foundation and the ASF are both not-for-profit
> > >> organizations, but they different significantly in their legal
> > >> organizations.  I forget the non-project corporation types but
> > >> basically, the Linux Foundation is dedicated to free business
> > >> development.  Projects are controlled through management teams
> > >> composed of businesses, usually by paying a fee and getting power
> > >> within the project based upon the amount that the business paid
> > >> (Silver, Gold, Platinum levels for example).
> > >>
> > >> The ASF is a different kind of not-for-profit organization, it is
> > >> dedicated to the people who use the software project, not to
> > >> businesses.  So for the ASF it is the user community that matters,
> > >> not the businesses that use the software.  An ASF project is
> > >> controlled by individuals in the community that have made significant
> > >> contributions to the project.  You will often hear ASF people say
> > >> "Community over code."  (I personally like code more that people, but
> > >> that is just me).
> > >
> > > Here is the missing details:
> > >
> > > Linux Foundation is an IRS 501(c)(6) nonprofit organization and the
> > > Apache Software Foundation is an IRS 501(c)(3) nonprofit
> > > organization.  According to
> > > https://www.charitynavigator.org/index.cfm?bay=content.view&cpid=1559:
> > >
> > >   * 501(c)(3):  Religious, Educational, Charitable, Scientific,
> > > Literary, Testing for Public Safety, to Foster National or
> > > International Amateur Sports Competition, or Prevention of Cruelty
> > > to Children or Animals Organizations
> > >   * 501(c)(6):  Business Leagues, Chambers of Commerce, Real Estate
> > > Boards, etc.
> > >
> > > Basically community first vs. business first.
> > >
> > One more anecdote then I promise to STFU
> >
> > As most of you know, Xiaomi sponsored and advocated NuttX to join the
> > ASF.  Xiaomi have been great partners and, despite my leeriness of
> > businesses, it has been a pleasure working with them.
> >
> > But a couple of years prior to that, Samsung sponsored NuttX in a
> > similar way to join the Linux Foundation.  After a few weeks of
> > discussions, I realized that what Samsung was advocating was not in the
> > interests of the project but served only Samsung and I discontinued that
> > conversation.  One good thing that came from that was a clarification of
> > my values and what values are necessary to retain in the project in
> > order for me to relinquish control of it to others.  I summarized all of
> > those things in the top-level INVIOLABLES.md which is essential the
> > "contract" under which I gave the project away.  Most of the items in
> > that list are things that Samsung wanted to change:  They did not want
> > to follow the standard POSIX/Unix OS interface, they wanted to change
> > the coding style, they only wanted to support ARM with GCC under Linux,
> > they wanted to rebrand the project to use a Samsung marketing name, ..
> >
> > That all makes sense if you understand the fundamental differences
> > between the Linux Foundation and the ASF.
> >
> >
> They could fork the code and do with the fork whatever they'd like provided
> they respect the license, but I certainly hope that (original) NuttX always
> remains POSIX-like/Unix-like, with support for multiple architectures,
> multiple compilers, ... These features are among the biggest reasons I've
> adopted NuttX. Getting rid of them would defeat the whole purpose!
>
> Cheers,
> Nathan

Exactly! This is the kind of situation I had in mind to avoid.. look
how Google or Samsung (Mobiles) became Microsoft (PC) with easily
available but extremely low quality products based on enforced changes
and limited life time (planned obsolescence).. you can tell a
difference when using BSD based Apple products but they are strictly
limited in customization and extremely expensive, also PlayStation
using FreeBSD did not share back the video drivers in any way (that
really suck here to be honest) but well BSD license allows that.

I am using Open-Source for around 23 years since my first PC, before
that I had Amiga (~1994) and Atari (~1988) so I saw some of those
fancy 1..3 years trends and in the long run Open-Source is the only
way to go! :-)

I am really impressed by the Open-Source support from Espressif, thus
my switch towards ESP32-C3 (RISC-V is also Open-Source), they seem to
know how to hire best passionate people out there :-) Also I was
really impressed by Xiami MiBand 5 with color display, smooth
experience, long battery life and such a detailed manufacturing for
such a small price - I did not even know it was based on NuttX.
Chinese folks seems to focus on goals and achievements in the first
place, not the paperwork and bureaucracy, thus their earned success.

I think I may be getting close to my perf

Re: NET_TCP_SPLIT removal

[Alexander Lunev]

When I tested buffered send mode, as I remember, I tried to increase
number of IOBs. It did not affect the performance. Also I observed some
strange spurious changes of receive window size that NuttX TCP side
advertises. As I had better results with unbuffered mode, I started to
use it rather than buffered one. I am going to experiment with buffered
mode again later.

Do I understand correctly, that if I use unbuffered mode with a large
user buffer (say 64 KB), then RFC 1122 still may pause NuttX TCP stack
if an odd number of TCP segments are constructed based on the 64 KB
buffer? Thus 0.5 second delay may occur at the end of 64 KB buffer
during the last segment?

On Thu, 2021-10-14 at 13:36 -0600, Gregory Nutt wrote:
> > > Currently I'm using "unbuffered" send mode as in my case it
> > > surprisingly provides twice as high throughput  as "buffered"
> > > one.
> > > Though, I initially expected that "buffered" send mode should
> > > have
> > > better performance compared to "unbuffered" one
> > 
> > It should not be faster.  I suspect that is some artifact of a bad
> > "buffered configuration" ...
> > 
> 
> For example, if your configuration does not provide a sufficient
> number of
> IOBs, then the performance of the buffered case will be bad because
> it will
> be constantly blocked waiting for free IOBs.  You really have to
> carefully
> tune the buffering to get the performance you want.

Re: NET_TCP_SPLIT removal

[Gregory Nutt]

 > Do I understand correctly, that if I use unbuffered mode with a large
> user buffer (say 64 KB), then RFC 1122 still may pause NuttX TCP stack
> if an odd number of TCP segments are constructed based on the 64 KB
> buffer? Thus 0.5 second delay may occur at the end of 64 KB buffer
> during the last segment

With large user buffers like that there may be some pauses if the IOB
buffers are exhausted.

But no, in general nothing pauses the buffered send.  It will send data
without receiving any ACKs at all, at least until a timeout occurs (which
it shouldn't).  Otherwise, the presence or lack of ACKs has no effect on
the data transfer.

The only effect of the ACK is (1) to update the ACKed sequence number, and
(2) to free the buffers holding the ACKed data.  Receiving the ACKs is
important only to prevent retransmissions and to prevent running out of IOBs

Re: NET_TCP_SPLIT removal

[Alexander Lunev]

Concerning buffered send mode yes, however I asked about unbuffered
send mode with a large user buffer.

On Thu, 2021-10-14 at 15:13 -0600, Gregory Nutt wrote:
>  > Do I understand correctly, that if I use unbuffered mode with a
> large
> > user buffer (say 64 KB), then RFC 1122 still may pause NuttX TCP
> > stack
> > if an odd number of TCP segments are constructed based on the 64 KB
> > buffer? Thus 0.5 second delay may occur at the end of 64 KB buffer
> > during the last segment
> 
> With large user buffers like that there may be some pauses if the IOB
> buffers are exhausted.
> 
> But no, in general nothing pauses the buffered send.  It will send
> data
> without receiving any ACKs at all, at least until a timeout occurs
> (which
> it shouldn't).  Otherwise, the presence or lack of ACKs has no effect
> on
> the data transfer.
> 
> The only effect of the ACK is (1) to update the ACKed sequence
> number, and
> (2) to free the buffers holding the ACKed data.  Receiving the ACKs
> is
> important only to prevent retransmissions and to prevent running out
> of IOBs

Re: NET_TCP_SPLIT removal

[Gregory Nutt]

> Concerning buffered send mode yes, however I asked about unbuffered
> send mode with a large user buffer.
>
>
> Sorry, I misread that.

>  > Do I understand correctly, that if I use unbuffered mode with a large
> > > user buffer (say 64 KB), then RFC 1122 still may pause NuttX TCP stack
> > > if an odd number of TCP segments are constructed based on the 64 KB
> > > buffer? Thus 0.5 second delay may occur at the end of 64 KB buffer
> > > during the last segment
>

I haven't looked or thought much about the unbuffered case in a long time.
I suppose that for very large user buffers provided in the send, what you
are saying is correct.  There would be no ACK delays until the last segment
is sent and if there is an odd number of segments, you should get the delay
(assuming that CONFIG_NET_TCP_SPLIT is not selected and that the size of
the last segment is at least CONFIG_NET_TCP_SPLIT_SIZE).

But if you send the same 64 KB of data using a small user buffer, then you
would experience that half second delay on every packet.  That is the case
where performance is terrible and CONFIG_NET_TCP_SPLIT should improve that.

Implementing QSPI driver in SPI mode

[Michal Lenc]

Hello all,



some chips from SAME70 family (J21 for example) do not have an SPI driver 
but use QSPI that can be run either in serial memory mode or in Master SPI
mode. The config options in samv7 arch seems to be already prepared for that
as SAMV7_QSPI_IS_SPI is selected for some chips but current sam_qspi.c
implements only serial memory mode. There seems to be no working example of
QSPI working as SPI in NuttX generally (all the implementions seems to be 
written just for the memory access) so I´d like to consult which
implementation is prefered as I am not sure whether some similar discussions
took place in the past.




The QSPI would need to support the SPI interface defined in struct spi_dev_s
in order to ensure compatibility with existing applications and drivers (LCD
displays for example) which use SPI. The option would be to add this
structure next to qspi_dev_s in arch specific drivers (in SAM case here 
https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam
_qspi.c#L159) and implements the specific SPI operations (send, exchange, 
command/data etc.) in that file. The driver would then access either qspi_
dev_s structure or spi_dev_s structure based on the configuration option for
the chip and would operate with that structure. Would this be a suitable
option or were there some other plans regarding implementing SPI functions
to QSPI? Thanks

 
Best regards,
Michal Lenc

Re: Implementing QSPI driver in SPI mode

[Gregory Nutt]

>
> The QSPI would need to support the SPI interface defined in struct
spi_dev_s
> in order to ensure compatibility with existing applications and drivers
(LCD
> displays for example) which use SPI. The option would be to add this
> structure next to qspi_dev_s in arch specific drivers (in SAM case here
>
https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam
> _qspi.c#L159) and implements the specific SPI operations (send, exchange,
> command/data etc.) in that file. The driver would then access either qspi_
> dev_s structure or spi_dev_s structure based on the configuration option
for
> the chip and would operate with that structure. Would this be a suitable
> option or were there some other plans regarding implementing SPI functions
> to QSPI? Thanks

I would be inclined to implement this as a separate SPI driver rather that
to try to make the QSPI driver to both roles.  That would be cleaner and
much less complex.  I think that the amount of code duplication would not
be very much since there is not a lot of overlap in data structures,
interface functions, etc.

INVIOLABLES.md:  "Sometimes Code Duplication is OK"

Re: NET_TCP_SPLIT removal

[Alexander Lunev]

Now I have read RFC 1122 and understood that the existing
CONFIG_NET_TCP_SPLIT algorithm can not help.

RFC 1122 (4.2.3.2) says:
> ...
> A TCP SHOULD implement a delayed ACK, but an ACK should not
> be excessively delayed; in particular, the delay MUST be
> less than 0.5 seconds, and in a stream of full-sized
> segments there SHOULD be an ACK for at least every second
> segment.

The important word there is "full-sized". Full-sized means equal to
MSS. Then splitting a segment into two segments is useless.

E.g. MSS = 512.
- If a user sends 200 bytes, then CONFIG_NET_TCP_SPLIT will create two
segments: 100 and 100 bytes. They are not full-sized. Then the remote
TCP receiver will not send ACK for up to 0.5 seconds.

- If a user sends 1500 bytes, then CONFIG_NET_TCP_SPLIT will create 4
segments: 512, 512, 238 and 238 bytes. The two last segments are not
full-sized. The same issue.


On Thu, 2021-10-14 at 15:45 -0600, Gregory Nutt wrote:
> > Concerning buffered send mode yes, however I asked about unbuffered
> > send mode with a large user buffer.
> > 
> > 
> > Sorry, I misread that.
> >  > Do I understand correctly, that if I use unbuffered mode with a
> > large
> > > > user buffer (say 64 KB), then RFC 1122 still may pause NuttX
> > > > TCP stack
> > > > if an odd number of TCP segments are constructed based on the
> > > > 64 KB
> > > > buffer? Thus 0.5 second delay may occur at the end of 64 KB
> > > > buffer
> > > > during the last segment
> 
> I haven't looked or thought much about the unbuffered case in a long
> time.
> I suppose that for very large user buffers provided in the send, what
> you
> are saying is correct.  There would be no ACK delays until the last
> segment
> is sent and if there is an odd number of segments, you should get the
> delay
> (assuming that CONFIG_NET_TCP_SPLIT is not selected and that the size
> of
> the last segment is at least CONFIG_NET_TCP_SPLIT_SIZE).
> 
> But if you send the same 64 KB of data using a small user buffer,
> then you
> would experience that half second delay on every packet.  That is the
> case
> where performance is terrible and CONFIG_NET_TCP_SPLIT should improve
> that.

Re: NET_TCP_SPLIT removal

[Takashi Yamamoto]

hi,

> I am not 100% sure of this, but I still think that it would be better to
> remove the unbuffered TCP send logic rather than remove the packet split
> logic.

personally i have no objection against the removal of unbuffered send.

but i can understand if someone objects it.
for some situations, maybe for an MSS-aware app, unbuffered send can
work better.

> I don't see how removing the split makes the unbuffered send
> better.

it reduces the code and makes it easier to maintain.

Re: NET_TCP_SPLIT removal

[Gregory Nutt]

The language in the RFC is not clear.  What is a full size packet?  Is that
the MSS which could potentially vary from segment to segment depending on
the sizes of the headers.  Is that the receive window size which could also
vary?  Not clear.

I don't think there is any general way to always send an even number of
full-size packets... whatever that means.  That is another good reason to
remove the unbuffered send.

The algorithm came from uIP 1.0 from around 2001.  Might be interesting to
see what uIP in Contiki did with that in later years.

More discussion here:
https://groups.google.com/g/nuttx/c/bh01LHix7nM/m/bL8242BQCwAJ  Johnny is a
pretty knowledgeable guy a references a couple of other RFCs there.

Re: NET_TCP_SPLIT removal

[Gregory Nutt]

The algorithm came from uIP 1.0 from around 2001.  Might be interesting to
> see what uIP in Contiki did with that in later years.
>

Here is some modified uIP source
https://github.com/adamdunkels/uip/blob/master/uip/uip-split.c

It says it is the original 1.0 source, but it is not.  The original 1.9
source did not support IPv6