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
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
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 situation
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
>
> 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
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 curren
> 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
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 Nut
> 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 l
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
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 cor
> ,,, 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
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 a
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
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 per
> > 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 t
> 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
> 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
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 Foundatio
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 oper
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 thr
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 throu
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 b
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
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 b
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 r
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
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
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
> > > > (D
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)
> > >
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
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
32 matches
Mail list logo
