Problems accessing File System using MES under High System Load | Thales IoT Developer Community
September 24, 2021 - 11:14am, 1566 views
Hi!
We're running a very demanding, multithreaded software on EHS5T, PLS62W, as well as ELS61 Modules and the problem we're experiencing is the following: Since the last expansion to our software, which increased the load on the system even more (additional RS485-Communication, using different parameters, as well as additional calculations) we're experiencing problems accessing the File System using MES at all, while the software is running.
The problem can be reproduced quite easily:
protected void startApp() throws MIDletStateChangeException {
new Thread(new Runnable(){
public void run() {
while(true)
;
}
}).start();
}
The problem is: i know it could be fixed in this case, by just implementing a Thread.sleep() / Object.wait() inside the loop.
This however, is a luxury, we can't have in our main software, since it has to react in realtime (or as near as possible to that) to different interfaces: Sockets, as well as server sockets, RS485 Communication to multiple devices that must not pause for more than ~5 seconds (at worst!), Logging.
I noticed that any sleep/wait can lead to much longer delays to my threads, than requested and noticed, that it isn't even always my own threads that are being executed in the meantime.
These are time frames, that are not comparable at all to the inaccurateness of Thread.sleep / Object.wait on PC systems, where the inacurracy is only in the millisecond-area.
Here, we are talking about Thread.sleep(60), which can take anywhere from 60ms to 60 seconds (but mostly only up to 10 seconds, which is already a big No-Go though!)...
This problem appears to get much worse, whenever the module fails to access the internet at the moment (in specific states, apparently).
According to a colleague, this problem appears to be worse on PLS62, compared to EHS5, which is something i actually couldn't reproduce myself, since i've been having problems accessing the modules using MES with the software running, for as long as i worked with this kind of hardware.
Please help!
Thanks!
Hello,
It looks like your software is pushing the modules to the limits.
The module itself is a small device with limited resources. And JVM definitely does not have the top priority in the system as there are other processes which need highest priority, for example those related to radio communication and hardware interfaces. I suppose that files transfer with MES has also low priority as it is not time critical and usually only used during the development.
So if it comes to MES I suppose that the best approach would be to stop the application before using it. Changing the application code to speed up the MES performance wouldn't be a good direction as it would have to impact the application performance.
But the question is probably more about the overall performance. The sleep time that you mentioned does not look nice but these delays seem to be the consequence of the system load. sleep() method does not guarantee that the thread will resume exactly after the specified time. It strictly depends on the system load.
Anyway it looks like the application optimizations is strongly desired, if there is still a room for the improvement.
Please make sure that all the resources are being released by the application when no longer used.
How big is the jar file? Obfuscation could also improve the performance.
If the app produces the huge amount of logs you could also think of reducing it.
Best regards,
Bartłomiej
Hi BARTŁOMIEJ!
We're already using obfuscation and have been for a long time - without it, it wouldn't even be possible to install the MIDlet at all anymore because of the size alone.
The settings of the obfuscator are the following:
Regarding Optimization:
1. I did everything this guide recommended
https://docs.oracle.com/javame/8.3/me-dev-guide/java-me-optimization-tec...
2. We're already buffering all write-operations to the file system, in order to do one big write operation instead of several smaller ones, if at all possible.
I guess this is the end of the line for expansions to our software on this hardware.
Thanks for trying to help!
Hello,
You may be right that you are close to the line.
What else comes to my mind is the buffer size while writing big amounts of data to FFS - 64KB is the FFS block size, so choosing this buffer size could be the best for performance as FFS write cycles are quite expensive.
Best regards,
Bartłomiej
Hi Bartlomiej!
That's good to know, but problem is that we can't buffer 64KB in a majority of cases, since our application is required to write to FFS ASAP. Otherwise data may get lost due to power outages, which ideally must not happen at all.
Only thing i can really do is wait for some seconds, after something ***** to be written to FFS, to try and write more data to FFS in one go, in case there is anything else to write in the meantime.
I do this for basically everything that ***** to be written to FFS.
I'd love to be able to buffer more than that, but can't because of the field we're in (payment and security related data...)
Probably you already know everything you need to know and only you can state if there is still any field for further optimization.
Best regards,
Bartłomiej