Slow sending and receiving

[Emil Kallio]

Hello!

 

Trying to manage FSMS for our Volunteer Fire Fighting department to be used to confirm participiants for our missions.

 

Now I made the first "bigger" test drive and sent messages for 16 persons/cells and asked them to reply. Then the program needed to forward those messages to my cell. Well it took total of 30 minutes from first sent message to last received message and total of 60 messages we're sent and received. When people begin to send messages back I had to reboot the program to start it to forward those messages to me.

 

Looks like there are same problems with other users too so it really seems that there might be a bug in the program in self. I use Windows 7 and Huawei E173 modem.

 

Could really use some help on this one. F/SMS seems to be great program though and would really serve our needs as we don't need and can't afford other SMS programs.

 

Thank You!

Emil

[Emil Kallio]

OK I might have found the problem already! There was a message in Huaweis Mobile Partner program and that might do the problem. Also I turned the reporting off. So let's see how well will it work.

 

I also sent my error reports if admins want to check them out. There was looping this same message and got rid off it by removing the SMS from Mobile Partner.

[Incoming message processor] TRACE [21/03/11 15:43:34] net.frontlinesms.messaging.IncomingMessageProcessor.run(IncomingMessageProcessor.java:123) - Getting incoming message from queue.
[Incoming message processor] TRACE [21/03/11 15:43:34] net.frontlinesms.messaging.IncomingMessageProcessor.processIncomingMessageDetails(IncomingMessageProcessor.java:165) - Got message from queue: 268981400:289833048
[Incoming message processor] DEBUG [21/03/11 15:43:34] net.frontlinesms.messaging.IncomingMessageProcessor.processIncomingMessageDetails(IncomingMessageProcessor.java:170) - Sender [+xxxx7114]
[Incoming message processor] WARN  [21/03/11 15:43:34] net.frontlinesms.messaging.IncomingMessageProcessor.run(IncomingMessageProcessor.java:145) - Error processing message.  It will be queued for re-processing.
org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect result size: expected 1, actual 2

[Alex Anderson]

Hi Emil,

 

Sorry you were having problems, and many thanks for the info about fixing it!  We'll take a look at the problem message and try to implement a fix.

 

Best,

 

Alex

[Emil Kallio]

It seems that checking messages from modem is very slow too. How normal is it? It takes about 15 seconds that program gets the message after modem has got it. (checked by counting time from sending phone got message status report).

 

Then it takes about 30 seconds that message has been forwarded. I'd say this is kinda slow. I have now tried win 7 and win xp, and huawei and sierra gms modems. But when I send just 10-20 bulk messages it seems that my network really can handle 5-6 messages per minute!

 

How does other users experience this?

[Alex Anderson]

Hi Emil,

 

Checking the modem for messages is quite a slow process, (usually taking ~20 seconds), and so this is only triggered every ~30 seconds.  Messages are not sent while trying to receive other messages.

 

If you're sending messages at 5-6/minute, then that's reasonable - as I understand, that's the maximum rate on a GSM network.

 

Would be interesting to hear some other experiences too.

 

Alex

[jacob Schou]

I have also experienced slow transfer rates, I set up a system in Tunesia. (Win 7 32 bit, FLSMS 1.6.16.3, and Huawi E122 USB modem)

It runs on the Orange mobile provider and when I distribute a message to 56 recipients the last message is transmitted after 30 minutes (roughly 2 per minute). I tried to use it for a security alert system, but it is unfortunately too slow for that. I haven't replicated the setup to my home country mobile network provider as i don't have 56 people who would like to be a part of my testbench :-)

My next step will be to change the modem to a serial modem and see if that improves the speed.

Jacob

[Tom Marentette]

Jacob,

 

I'm wondering, have you tried a different USB modem, to see if your SMS sends any faster? I'd be interested to see if the serial modem makes a difference.

 

best,
Tom

[jacob Schou]

Tom

I only have Huawei modems in the office (no longer in Tunesia), however I could try with a mobile phone with a USB cable (just need to identify a model that works) to see if that changes anything.

Regarding the serial modem:

It's hard to find a laptop with serial these days. I have to connect it via a USB to serial adaptor. We'll se if that introduces new challenges :-)

I will get back when I've had time to go through a small testscenario

Cheers Jacob

[Emil Kallio]

Hello!

 

I'm very sorry that I haven't written anything for a while. So we could assume that everything is working fine and they are! =)

 

We have sent and received over 1000 messages since March 2011 and we have only about 15 users in this "ring". And it seems that everyone has been really satisfied to this system.  F/SMS have really helped us in our fire fighting mission alarms. Now our duty officer knows in just few minutes that how many persons are able to take part in mission.

 

But little problem is that when the F/SMS is getting many received messages it gets slow. And the problem seems to be in "check received messages" trigger. As Alex said.

 

Could it be possible to make some changes in the program code so it would stop checking messages for time when there are messages in sending queue? I think that there could (and should) be a priority setting in options for receiving, sending, forwarding and answering e.g.

 

Sincerely

Emil

[Florence Scialom]

Hi Emil,

 

Thanks for getting back in touch! It sounds like a fantastic use of FrontlineSMS you have set up, and I'd love to hear more about the difference it is making to use FrontlineSMS in your work. It also would be great if you'd be interested in potentially writing something about your use of our software for the FrontlineSMS blog? It's really interesting for us to represent the many different ways our software can be used! 

 

With regards to your question on changes to the program code, I will have to ask Alex about this one and he has now left the office for the weekend, but we will be sure to get back to you about this early next week.

 

Many thanks,

Flo

 

 

[Alex Anderson]

Hi Emil,

 

It's definitely worth our considering this and other strategies for juggling sending and receiving in different situations.  Presenting the user with a priority option sounds like a good idea.

 

Thanks for the feedback,

 

Alex