HG is slow

[Gene]

Seem to work.
I replaced the lines:
(https://github.com/genielabs/HomeGenie/blob/master/MIG/Support%20Libraries/XTenLib/XTenManager.cs#L395)

Code: [Select]

                            else if ((readData[0] == (int)X10CommandType.PLC_Poll)) // && readdata.Length > 2)
                            {
                                statusRequestOk = true;
                                sendQueue.Enqueue(new byte[] { 0xC3 }); // reply to poll

with:

Code: [Select]

                            else if ((readData[0] == (int)X10CommandType.PLC_Poll) && readData.Length == 1)
                            {
                                statusRequestOk = true;
                                sendQueue.Enqueue(new byte[] { 0xC3 }); // reply to poll
                            }
                            else if ((readData[0] == (int)X10CommandType.PLC_Poll))
                            {

g.

[bkenobi]

I replaced the code and recompiled.  It does appear to run quicker.  Interestingly, one time, the code seemed to work way too fast (~0.75 seconds), but that seems to be an outlier.  The new times indicate the average time is now between 1.3 and 1.4 seconds plus overhead after the send.  I used the stopwatch and found the change occurs in just over 2 seconds (2.2 or so seconds).  This is a huge improvement!

The one thing that stands out about the code that's being printed to the log is that HG seems to send 4 characters (2 sets of 2 digit hex) whereas AHP seems to be sending 8 characters (4 sets of 2 digit hex). 

HG will send:

Code: [Select]

04 E9
06 E2and

Code: [Select]

04 E9
06 E3
AHP will send:

Code: [Select]

5A 02 00 E9
5A 02 01 E2and

Code: [Select]

5A 02 00 E9
5A 02 01 E3


[Gene]

Hi Ben,

HG and AHP transmit the same number of bytes. What are you seeing is just extra bytes from the CM interface that tells the software what kind of data is being received (RF, PLC, MACRO etc...) and the length of the received data (02).

Cheers,
g.

[bkenobi]

That makes sense.  I still think it's possible to squeeze a little more speed out since mocha was able to perform the task in under 2 seconds (though it was not consistent as I recall).

[bkenobi]

I just reviewed my findings during earlier testing with Mochad posted in this thread since I couldn't locate my local documentation.  It looks like Mochad runs the 2 command test in 2.1-2.2 seconds.  It looks to me as though HG is running basically the same speed at around 2.2 seconds.  It would be great if another half second could be squeezed out of this, but I'm not sure if that is possible.  Mochad seems to be as lean as things can get and if HG is matching that, then it's unlikely we could do any better without a X10 software programmer telling us a "perfect" solution.

[bkenobi]

I was just thinking about the maximum speed of either Mochad or HG running on Raspi and wondering if this has to do with either the Raspi or the USB drivers being used.  If it's drivers slowing things down, that would require either something integrated into the Linux kernel itself probably.  But, if it's Raspi, could overclocking help?  I've seen people running XBMC et. al. running up to 1GHz pretty regularly with only additional cooling fins.  Would a higher clock rate increase the USB performance though?  I really have no experience with how the clock speed affects bus transfer rate so this is a serious question.

Also, I'll try running this test on a Windows 7 machine to see if the speed is the same.  If so, then the Raspi itself shouldn't be the limitation.