my colleagues were complaining that our sms-gateway took too long to send messages (approx. 25 seconds), so I started looking at how to improve it.

first step was to take advantage of the tunables available:

delaytime = 1 [FalcomTango] baudrate = 115200 send_delay = 0

especially delaytime makes a lot of difference, 5 seconds on average.

next step was to upgrade to the beta version, which improves this quite a bit! thanks, Keke.
it will still wait for a quite long time between/after each command, on average 100 ms, which adds up. I reduced the poll interval to 25 ms but increased the number of timeouts correspondingly except in the case where it just checks for unexpected output from the modem.

Patch

at this stage sending an SMS takes ~8 seconds. the last step is to replace the FalcomTango modems with more modern modems which respond *much* more quickly to each command.

You have used the delaytime setting, and it speeds up polling of message files. It may also raise the server load, as this setting is used for polling incoming messages too, for each modem process.

There is also another setting available, delaytime_mainprocess, and it affects only to spooling. If incoming messages are not very important (of speed in seconds), delaytime could be 5 or 10, and delaytime_mainprocess could be 1. Then new files are found in one second, and as soon as they are spooled to queues, modem processes will get the continue signal. Delay is then breaked and suitable modem will start the job immediately.

I would like to know what was the exact increase in speed with your patch when you tested it, and I mean the actual sending time, not the total time from the creation of the file. With loglevel 7 and logtime_ms the difference should be visible in the log. Also use a new setting log_response_time which currently is not in the main documentation.

The patched version did not work with Telnet modem, but the idea is good. Thank you for that.

I'm not sure what is the benefit with faster polling when overall timeout is still the same. I therefore made an implementation where faster polling is applied when modem process knows what to expect as an answer, and as soon as the expected answer is received, program flow continues. This makes results which look remarkable. However, speed of sending SMS highly depends on the GSM network and Service Center, but of course waiting for example 10 or 25 ms instead of 200 ms is better, in particular when this is saved up with each command.

The next version 3.1.16beta2 has a modem setting poll_faster, which defaults to 5. This means that when expected answer is known, single sleeping is 20 ms and number of timeouts is multiplied by 5. Users can then adjust the value, depending on the speed of the hardware and possibly raising CPU load. Some configuration settings can be used to determine what is the best value for each setup. With network modem I noticed that higher factor made no sense, but with some USB stick even more than 20 was good and modem process was very fast.

I will release 3.1.16beta2 in the next few days.