Page 1 of 1

SBL2eX Custom Packetization Anomaly

Posted: Mon Jun 14, 2021 6:50 pm
by kcris
We have an SBL2eX set up to use custom packetization using the option for "Number of milliseconds to wait for accumulated characters" set to 60. We have a serial device sending blocks of 18 characters every 20 ms. Looking at the IP packets generated by the SBL2eX, there is a timing anomaly. Most packets are spaced correctly by 60ms. However, on regular intervals, specifically every 4.64 seconds, there is a inter-packet time of 77 ms - 17 ms too long. After each of these events, the expected 60ms interval resumes. Seems like there may be a SW bug? Can you comment?

Re: SBL2eX Custom Packetization Anomaly

Posted: Tue Jun 15, 2021 10:43 am
by TomNB
If your using TCP, anything in the path can break up packets (TCP is a stream, not packet based). My first guess is that it might be that. One way to check is to try on different network configurations, as well as a wireshark packet capture to see if window flow control is active.

Re: SBL2eX Custom Packetization Anomaly

Posted: Tue Jun 15, 2021 11:40 am
by kcris
Tom,

Thanks for your reply. We are using UDP and the network is a simple isolated network, so there is little chance of other devices impacting this, I think. We are using Wireshark to sniff the interface (using a passive tap) directly on the SBL2eX device. The Wireshark trace is how we noticed the timing anomaly.

Re: SBL2eX Custom Packetization Anomaly

Posted: Wed Jun 16, 2021 1:59 pm
by pbreed
Its 60msec of idle time....
So its possible that the 18 chars every 20 msec (way below the 60 msec)
and the packetization you are seeing is a buffer size issue and just happens to be around 60msec.
Unrelated to the 60 msec set idle time interval.
If I'm correct in my guess changing the 60msec setting to 120msec will have zero effect.

I also think that if you set the custom packetization count to 3X18 =54 then you won't see the wrap.

Re: SBL2eX Custom Packetization Anomaly

Posted: Fri Jun 18, 2021 9:33 am
by kcris
Thank you for your reply. We switched to using "Number of characters to accumulate before sending TCP/UDP packet" packetization option for other reasons. In the process, we found that the "Number of milliseconds to wait for accumulated characters (0 waits forever)" option did not work as we expected. From the description in the user's guide, we expected this timer would count down the time since the last packet. Thus, in combination with the "Number of characters..." option, it could be used to flush the queue if an unexpectedly long pause occurred in the serial stream. However, we found via experimentation that the timer is constantly counting regardless of when the last packet was sent. So, for example, if we have the character count option set to 54 and the timer option set to 1000ms (1 sec), we would see a consistent flow of 54 byte packets except every 1 second, a shorter packet would be sent with whatever was in the queue at that moment. Perhaps we are the only ones to misinterpret the user's guide, but I would suggest this could be better explained.