EHS6T - transfer rate over GPRS issues | Telit Cinterion IoT Developer Community
April 10, 2015 - 1:23pm, 3245 views
Hi all,
I'm aiming to use the EHS6T terminal in an application that would transfer large chunks of data and speed is a factor. I'm using at commands directly, sending them over serial link.
I've followed the tutorials and successfully managed to establish a data connection over TCP/IP, but the data transfer seems to be having issues.
I tried the transparent mode and noticed that if I send a small packet of data, it always arrives to the other end with a 4-5 second delay. If I send another packet just after, it seems to be forcing the first packet to arrive faster, but the second is still placed on 4-5 second delay. If I send huge chunks of data, the transfer seems to be stable and going up to desired speeds (about 11.5 kB/s, as serial of 115200 allows) - everything is sent in proper except for the very last packet which, again, seems to arrive 4-5 seconds later. It doesn't seem it's a flow control issue - more like a that there's some packetization timeout employed by the terminal, but I cannot seem to find anything about it in documentations. It doesn't seem that the parameter "timer" used in at^siss, address has any impact on it. Does anyone have an idea what I may be missing?
I also tried sending the data via at commands, without transparent mode, but it's going a lot slower (around 4.5 kB/s) using the same environment. There seems to be about 150-200 msec delay between the moment in which the 1460 data chunk is sent and receiving OK notification in a single at^sisw call. Is this the actual time of sending, meaning that the terminal first accepts the data, buffers it, then starts sending it and returns OK only after the data's been sent to the network? By comparison, the time between OK and ^SISW that indicates that the terminal is ready to accept the next at^sisw call seems 10 ***** smaller. Is it the limitation of the terminal or I'm missing something?
I don't believe it's a network transfer speed issue as I'm able to have over 10 kB/s while streaming, but maybe it's still related to the how the operator sends notifications back to the terminal.
I dumbed down the configuration to be as plain as possible to avoid setting any parameter that would interefere. Here's my listing:
ate0
at^sics=1,conType,"GPRS0"
at^sics=1,apn,"some_apn"
at^sics=1,inactTO,"20"
at^siss=1,srvType,"Socket"
at^siss=1,conId,1
at^siss=1,address,"socktcp://***.***.***.***:yyyy;etx"
Thanks!
Hello,
Interesting and very detailed observations.
Have you tested it also with some other GSM/UMTS device or network provider for comparison? This would answer the question if this is module or network behaviour. I guess that you are able to verify the packets on the other end of transmission.
I think that this might be caused by the network as well. The backbone network can have larger TCP segments sizes or MTU for IP packets. Maybe there is some kind on waiting for more data implemented.
GPRS signalling also brings some overhead in comparison to cable connection especially on start of data transmission but this might not be the case here.
Sending data with AT commands ***** some more layers to be involved than in transparent mode so it will probably always be slower than transparent mode.
Best regards,
Bartłomiej
Could it be caused by the Nagle Algoritme?
http://en.wikipedia.org/wiki/Nagle%27s_algorithm
Hi,
Thank you for the comments.
It doesn't seem like a network issue. I've tested it with SIM cards from two different operators and also on BGS5T and the last packet delay problem persists. We've also been using H24 Telit modems and have not ran into this kind of problems (these modems also have a transparent mode and also use Nagle algorithm to packetize outgoing data).
I understand that AT commands will be slower than transparent mode, but even if the terminal is actually sending data with each at^sisw without buffering them somehow, the delay seems a lot. It takes around 300 ms to send a 1460 packet at baud rate 115200 (******** the time it takes to send it to the modem and get OK reply), meaning that the time to send and acknowledge a packet through the network seems longer than it actually takes to transfer it through the cable. Maybe GPRS could slow it down like that, but not 3G (the terminal indicates that it has 3G connectivity, but maybe it requires some additional configuration regardless - I did experiment with different QoS settings, but it didn't change things).
I tried different timer settings for Nagle algorithm and it didn't improve. 5 seconds seem to be a awful lot of time for it, considering the maximum timer setting is 500 ms.
Best regards,