Have done some long term testing of the FT8 extension in versions 1.586 and 1.587. This has been carried out on 28074 kHz during local daylight hours with plenty of activity. Most of the time the FT8 extension has produced 20-30 decodes in each sequence. I made two test using v 1.586 and the behaviour was more or less the same: when running the extension, the size of the hash table increased until it reached 99 or 100% after a couple of hours. At that point the KiwiSDR receiver froze, not even the admin pages were available. Using PUTTY, I could log into the BB and issue a reboot command to restore operation.
First test I did using v 1.587 had the same behaviour as using v1.586 the receiver froze after a couple of hours with hash table size at 99%. The second attempt with v 1.587 behaved slightly different. Initially the hash table size increased to 75% and then slowly reduced to 66%. After that it again started to increase and ended at 100% and receiver freeze after about 3 hours. The dip in hash table size coincided with a period when I was the only user on the receiver. Most other times, there has been a lot of other users active on the receiver.
Perhaps the total load on the receiver affects the size of the hash table?
I used the existing FT8 callsign hashtable (from the original ft8_lib code) as a callsign upload rate limiter for pskreporter.info I made the hashtable larger and a few other changes, but otherwise unchanged.
It's possible there's a bug. Let me simulate the hashtable full condition and see if I can trigger the problem. It sounds like the code is going into a loop. Thanks for the detailed report.
Yeah, lol, that hash code is completely wrong. Or my co-opting it for use with pskreporter is wrong depending on how you look at it.
That hash code depends on that fact that the age eviction rate is high enough it always keeps the hashtable from filling up. Otherwise adding new hash entries to a full hashtable loops!
But there seems to be an interaction issue between FT8 and WSPR on BBAI/AI64 Kiwis. So don't run FT8 on AI/AI64 Kiwis running the WSPR extension for now (either manually or via autorun).
Remember that you can disable extensions individually on the admin page, extensions tab (local connections exempt). This is for example how you could prevent a public BBAI Kiwi using WSPR autorun from being crashed by users using FT8.
Well, I don't know. I had two crashes right in a row on a BBAI running FT8+WSPR simultaneously. But now I've run for 2 hours straight without a problem. So this might be less of an issue than I thought. Still, if you're having trouble this might be the cause.
Today been testing the v 1.588 version of FT8 extension for over 10 hours with no stability issues despite heavy load from other users. After about 5 hours, the hash table size stabilized at 98-100% and remained at that level for the rest of the test.
Comments
Have done some long term testing of the FT8 extension in versions 1.586 and 1.587. This has been carried out on 28074 kHz during local daylight hours with plenty of activity. Most of the time the FT8 extension has produced 20-30 decodes in each sequence. I made two test using v 1.586 and the behaviour was more or less the same: when running the extension, the size of the hash table increased until it reached 99 or 100% after a couple of hours. At that point the KiwiSDR receiver froze, not even the admin pages were available. Using PUTTY, I could log into the BB and issue a reboot command to restore operation.
First test I did using v 1.587 had the same behaviour as using v1.586 the receiver froze after a couple of hours with hash table size at 99%. The second attempt with v 1.587 behaved slightly different. Initially the hash table size increased to 75% and then slowly reduced to 66%. After that it again started to increase and ended at 100% and receiver freeze after about 3 hours. The dip in hash table size coincided with a period when I was the only user on the receiver. Most other times, there has been a lot of other users active on the receiver.
Perhaps the total load on the receiver affects the size of the hash table?
I used the existing FT8 callsign hashtable (from the original ft8_lib code) as a callsign upload rate limiter for pskreporter.info I made the hashtable larger and a few other changes, but otherwise unchanged.
It's possible there's a bug. Let me simulate the hashtable full condition and see if I can trigger the problem. It sounds like the code is going into a loop. Thanks for the detailed report.
Yeah, lol, that hash code is completely wrong. Or my co-opting it for use with pskreporter is wrong depending on how you look at it.
That hash code depends on that fact that the age eviction rate is high enough it always keeps the hashtable from filling up. Otherwise adding new hash entries to a full hashtable loops!
Fix coming soon..
v1.588 fixes the looping issue.
But there seems to be an interaction issue between FT8 and WSPR on BBAI/AI64 Kiwis. So don't run FT8 on AI/AI64 Kiwis running the WSPR extension for now (either manually or via autorun).
Remember that you can disable extensions individually on the admin page, extensions tab (local connections exempt). This is for example how you could prevent a public BBAI Kiwi using WSPR autorun from being crashed by users using FT8.
Well, I don't know. I had two crashes right in a row on a BBAI running FT8+WSPR simultaneously. But now I've run for 2 hours straight without a problem. So this might be less of an issue than I thought. Still, if you're having trouble this might be the cause.
Today been testing the v 1.588 version of FT8 extension for over 10 hours with no stability issues despite heavy load from other users. After about 5 hours, the hash table size stabilized at 98-100% and remained at that level for the rest of the test.
Thank you very much John & Kārlis for this nice upgrade! :)