occupying the full
space, and use this solid file for placing your journaling file system
as the content of the solid file (open, lseek, read, write, close).
Best regards,
Alexander Lunev.
On Wed, 2022-01-19 at 18:40 +, TimH wrote:
> FAT seems broken for NOR flash devices. Spent days gett
I have performed the testing. I sent segments with size of 32 bytes in
a loop. NuttX source code is based on SHA-1 =
1e2560267898f413c93c5fb616ddc5b1d4d07184.
As a TCP host I used Linux kernel 4.19.
In case of forcing TCP_QUICKACK option to 1 in Linux I added the
following line after recv():
> More discussion here:
> https://groups.google.com/g/nuttx/c/bh01LHix7nM/m/bL8242BQCwAJ Johnn
> y is a
> pretty knowledgeable guy a references a couple of other RFCs there.
Thank you for the link to the discussion. There is useful additional
info:
RFC 2581 (4.2) says:
> Therefore, while a
> What is a full size packet?
RFC 1122 (4.2.3.4) says:
> the TCP can send a full-sized segment (Eff.snd.MSS
> bytes; see Section 4.2.2.6).
There is an algorithm in Section 4.2.2.6 how Eff.snd.MSS is calculated.
> That is another good reason to remove the unbuffered send.
So far I still think we
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
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
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
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
ay 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.o
