In reply to G4OBK:
Time for a status update.
There is a very simple cluster running that a group of alpha testers have been using. It is dumb (oh is it dumb), in that it takes spots from SOTAwatch and outputs them in “cluster format” to anyone who has connected. I’ve had reports back that it’s working with Logger32, xdx, DX4WIN, Band Master and MacLoggerDX. It doesn’t work with HRD and due to the decisions made by HRD’s author it’s unlikely I’ll have time to add support for HRD within any realistic timescale.
There are still two bugs I want to fix. Both these are threading issues (fellow programmers will understand) but they have become considerably less frequent since I made some more changes. However, they still exist and do need fixing.
So my next plan is to roll out testing to more people. There will be a limited number of logins available and it will be first come first served. I’ll publish the connection details later today/tomorrow. Alpha testers should continue to use the details they know not the new ones. With some more load I’m hoping to get to the bottom of the bugs and then we can have a wider rollout.
Eric KU6J’s idea of using a real high performance freeware cluster driven by our own feed is an interesting idea and in the end may prove to be a better solution. There are some simple reasons for not progressing with this right now. Firstly I was actually writing some code for work (multithreaded socket sever) that has some similarities to what is in this cluster code. I’ve been able to write some of what we needed and get paid for it, getting paid to write amateur code is too sweet to pass up! Secondly, the cluster sofwtare Eric found runs on Windows/C# and I don’t have any available hardware free. Maybe, just maybe, it could be run on the same hardware our SOTA database runs on. But we’ve seen the problems we had over the summer when the server was very heavily loaded. It’s running well on the new hardware and has gained Maserati performance compared to before. I don’t want to adversely affect that performance gain TBH. The cluster I’ve produced is written in Python and runs on anything. I’ve tested versions running on Win7, Linux x86. Currently the server is a Linux amd64 virtual machine in a datacentre in Iceland.
To run the full cluster will need a Windows machine with a suitably reliable power feed and internet feed. Virtual low end Linux machines are pennies as there’s no software license fees, it’s why I have a several around the world. Windows machines tend to need more resources and so cost more to buy/run/rent. There is a chance the Windows/C# code will run on Linux with some software called Mono as that replicates the C# support missing from Linux. I haven’t got time to investigate that now but it could be valuable to know. If anyone wants to get involved in these possible solutions then get in touch.
Thanks for the feedback from the alpaha testers, without you etc. etc. Some have been hugely helpful with their serious testing and also very supporttive with encouraging comments.
Thank you for plaudits as well. This kind of software is not hard to write, it’s just like Lego really. All I’ve done is clip together something out of all the basic building blocks floating about out in cyberspace!
Fun time over, back to USB3 virtualisation 
Andy
MM0FMF