Go Down

Topic: Gobetwino is running very slow after a few hours - anyone else had this? (Read 2 times) previous topic - next topic


There should not be any problems with running at higher speeds, i don't think it will makes things faster though, as i assume the major slice of time is taken by GoBetwino parsing command and doing the logging / file reading.

I will look at your code as time permits.

The source code it not available yet, for the simple reason that i need to clean it up and translate a very large amount of comments to english. It is my plan to make the code available at some time. Probably after the next update.


How large does your log files get during an "all night session" ?

How large is the file you use with the RFLIN command ?

i'm beginning to suspect that you might experience severe memory fragmentation caused by repeadetly opening large files.


Hi MikMo

There are two type of log files, one of which can grow to a considerable size. A single thermocouple can generate a reading every three seconds, each requiring a string of about 10 characters to be transmitted.  Then GBT adds in the time stamp (about 20 character).

That makes 30 * 24hrs a day * 60mins per hour * 60 secs per min / 3secs  = .9 MB per day

The kiln can be continuously operational for over a week in some circumstances, although typically a firing is less than 24 hours. So a maximum of say 7 MB.

There are up to eight thermocouples, but the data from each thermocouple goes to a separate log.

The file involved with RDFIL will rarely get above 100 records long.

severe memory fragmentation caused by repeadetly opening large files.

Which part of the environment do you suspect of doing the fragmenting? - GBT, Windows, something else?

Hope this helps. I will try and run GBT tonight.



I had a quick look at your code and i can't see anything in there that looks wrong. And it works ok for some times before the problems start.

So right now i have two "suspects" memory fragmentation caused by GoBetwino repeatedly opening large files, (even more suspicious now when you mention multiple log files), and the other suspect is the status and command output textboxes that will grow very large with your usage pattern. Maybe so large that it becomes a problem for Windows (there is a limit to the amount of text a textbox can contain)

The problem with memory fragmentation is that it is difficult to avoid

I will try to make an Arduino sketch that mimics your usage pattern and see how it runs here.

What version of Windows are you running ?


I'm on Windows XP.

Do you recall that I mentioned some repetition of GBT responses in the Output text box - would that symptom tend to favour any of your theories?

You mention the Windows limit. Is there possibly a delay involved from Windows when the text box gets very full,  a delay that affects GBT's ability to service the next incoming request from Arduino, so that it gets behind?

There were two log files were in use when the problem occurred, one as I described previously, and the other a reflection of all traffic between GBT and Arduino, in essence a duplicate (in "user" language) of your own log. It also would get quite large.

However I'm having difficulty in understanding why the size of the log files should make any difference - surely you are simply appending to the end of them. Would size affect the time taken to do that?

I can understand some size issues with respect to the RFLIN command, since presumably you are obliged to read through the file sequentially to access the record I requested. However as I said this file is short, so unlikely to be the culprit?

Thanks for giving it your attention

Go Up