OpenThread
-
|
I have a SED sending data through TCP to a server located through the BR. My problem is that the SED ends up having to retransmit a lot of TCP packets. Reading this #5060, it looks like it is the expected behavior but it looks odd and ends up costing more power and time so I'd like some feedback if possible. Let see what happens just with the SYN/SYN-ACK of the socket opening. In the following BR log, you can see:
Here you can see what is looks like on the server side with all the retransmissions:
Is there a way around this? I feel, at least for my use-case, it is much better to just set this to always openthread/src/core/mac/data_poll_sender.cpp Line 361 in 481a064 |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
|
I kept working on this even though I'm actually not sure if I'm just reinventing the wheel or actually solving a real issue. My previous hack ended up unreliable as sometimes the data poll would actually happen too fast, before the BR had time to get the SYN-ACK and so I would gain nothing. However I found out the concept of the "Fast Poll" and this seems exactly the kind of thing I need. I checked in the openthread tcp stack and it doesn't seem like it does enable fast polling when expecting a tcp reply but I haven't researched that a ton. On my side, I'm using the zephyr tcp stack and it sure doesn't. I think what would need to happen is for the tcp stack to toggle between normal and fast polling depending of the state of the socket. However, as a quick proof of concept I enabled it all the time: diff --git a/src/core/mac/data_poll_sender.cpp b/src/core/mac/data_poll_sender.cpp
index ab1ad0db6..622bb59bc 100644
--- a/src/core/mac/data_poll_sender.cpp
+++ b/src/core/mac/data_poll_sender.cpp
@@ -377,6 +377,10 @@ void DataPollSender::ProcessTxDone(const Mac::TxFrame &aFrame, const Mac::RxFram
{
IgnoreError(SendDataPoll());
}
+ else
+ {
+ SendFastPolls(1);
+ }
exit:
return;
diff --git a/src/core/mac/data_poll_sender.hpp b/src/core/mac/data_poll_sender.hpp
index a30f56362..d3ad678e6 100644
--- a/src/core/mac/data_poll_sender.hpp
+++ b/src/core/mac/data_poll_sender.hpp
@@ -269,7 +269,7 @@ private:
// Poll period under different conditions (in milliseconds).
static constexpr uint32_t kAttachDataPollPeriod = OPENTHREAD_CONFIG_MAC_ATTACH_DATA_POLL_PERIOD;
static constexpr uint32_t kRetxPollPeriod = OPENTHREAD_CONFIG_MAC_RETX_POLL_PERIOD;
- static constexpr uint32_t kFastPollPeriod = 188;
+ static constexpr uint32_t kFastPollPeriod = 10;
static constexpr uint32_t kMinPollPeriod = OPENTHREAD_CONFIG_MAC_MINIMUM_POLL_PERIOD;
static constexpr uint32_t kMaxExternalPeriod = ((1 << 26) - 1); // ~18.6 hours.
With this my transaction with the MQTT server finishes in ~70ms instead of the ~650ms you see in the screenshot of my first post:
This is really the difference between instant and sluggish from a humain point of view. Any idea on this? I'm new to this spec so I might well be trying to solve my problem the wrong way. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for raising this issue. You are correct that we have not done the work to integrate TCP with Data Polling on a Sleepy End Device (SED). I think we'll have to do some more thinking around how best to integrate data poll period adjustments with TCP. While we could have the SED poll more frequently while it is waiting for a TCP ACK, it's not clear how the SED would determine when to poll more frequently when the peer is sending data to it. The challenge is that the SED does not really know when it might receive data from a peer. One thing you could try is by using |
Beta Was this translation helpful? Give feedback.
-
|
I gave the I do a One thing I would point out is that it's not trivial for the application to know exactly when to stop the aggressive polling. This is application specific but at least with zephyr For the moment, on my side, this is good enough, thank you very much. |
Beta Was this translation helpful? Give feedback.
Thanks for raising this issue. You are correct that we have not done the work to integrate TCP with Data Polling on a Sleepy End Device (SED). I think we'll have to do some more thinking around how best to integrate data poll period adjustments with TCP.
While we could have the SED poll more frequently while it is waiting for a TCP ACK, it's not clear how the SED would determine when to poll more frequently when the peer is sending data to it. The challenge is that the SED does not really know when it might receive data from a peer.
One thing you could try is by using
otLinkSetPollPeriod()to set the poll period. Of course, setting the poll period to something small will increase the SEDs…