Hi Forum,
i got a GSM2 click (mikroe.com) cape with a M95 quectel modem running on my beagleBone black. So ppp0 is up and I have internet access. But the connection speed is very slow, ~ 9KB/s although I should have gprs and the modem is initialized with 115200 in the ppp script. Any hint on that would be very appreciated.
Reinhard
peers script:
/dev/ttyO4
115200
hide-password
noauth
defaultroute
replacedefaultroute
noipdefault
usepeerdns
connect “/usr/sbin/chat -v -f /etc/chatscripts/gprs”
gprs chatscript:
‘OK’ ‘AT+CGDCONT=1,“IP”,“bob.at”’
OK-AT-OK “ATDT99**1#”
CONNECT \d\c"
On Tue, 24 Nov 2015 07:18:22 -0800 (PST),
rkelectronicsolutions@gmail.com declaimed the
following:
Hi Forum,
i got a GSM2 click (mikroe.com) cape with a M95 quectel modem running on my
beagleBone black. So ppp0 is up and I have internet access. But the
connection speed is very slow, ~ 9KB/s although I should have gprs and the
modem is initialized with 115200 in the ppp script. Any hint on that would
be very appreciated.
What speed were you expecting?
Worst case assumes 10-bits per "character" (start/stop/8n1
asynchronous) transfer. 115200 would thereby max out at 11520B/s, or
11.52KB/s (decimal) {11.25KB/s binary}
If there is any protocol overhead (ACK/NAK) you have lost a few more
bytes of transfer time. What is the MTU of the link?
Also, what are you actually measuring? Net (user data) throughput? An
Ethernet frame with 1500 byte (octet) payload takes up takes 1530 bytes
(and doesn't include the 12 byte packet gap). Of that 1500 byte payload, an
IP packet has a minimum of 20 bytes header. So... End data would be around
1480 bytes per 1530, or ~96%... 11.52 * 96% => ~11KB/s -- presuming fully
loaded with no resends or ACK/NAK overhead.
I'd suspect you are seeing about the best that you should expect for a
115200 serial interlink. To see something in the 2Mbps range, you'd need a
serial interlink running much faster.
Specifications http://www.quectel.com/product/prodetail.aspx?id=7 state
Max. 85.6kbps (uplink & downlink)
Assuming 10-bit asynch (worst case again), that gives 8.56KB/s. I expect
packetization improves on the 10-bit worst case by replacing all those
start/stop bits with some checksum/CRC algorithm.