Speed of home control protocols . . .
- Thread starter ChrisWalker
- Start date
ChrisWalker
Active Member
Hi rocco,rocco said:
Just to clarify, Z-Wave itself has absolutely no troubles with overlapping messages. There's lots of collision detection built in, and messages are acknowledged as a standard rule. But when it comes to using the Z-Wave RS232 (or USB) interfaces, there are certain spectifications to live by for optimal protocol integration.
This is similar to how most web browesrs work. Generally, they'll download a web page--but will only download a few images on the page at a time. If they tried to open up 50 simultaneous connections to the server to download the 50 images all at once, it would create a lesser experience for the user. The web server, of course, has no problem serving up 50 requests to various users simultaneously.
Chris
Dean Roddey
Senior Member
There is only one thread talking to the controller, as I indicated above. It just doesn't wait for the reply from the module synchronously.
rocco
Active Member
Chris, I didn't mean to imply a problem with ZWave. I've studied ZWave enough to know it can support overlapped I/O. I almost even dropped the $10K to become a ZWave developer.
By "unintended consequences", I thought you might mean difficulties in handling overlapped I/O in Dean's driver. Those could certainly be fixed by Dean. But I was mostly fingering the USB/system drivers and the interface, where Dean's driver may uncover further weaknesses. Only when all of these weaknesses have been addressed will we be able to consider ZWave mature.
I would bet that most of the HomeSeer/ZWave complaints could be resolved with overlapped I/O.
By "unintended consequences", I thought you might mean difficulties in handling overlapped I/O in Dean's driver. Those could certainly be fixed by Dean. But I was mostly fingering the USB/system drivers and the interface, where Dean's driver may uncover further weaknesses. Only when all of these weaknesses have been addressed will we be able to consider ZWave mature.
I would bet that most of the HomeSeer/ZWave complaints could be resolved with overlapped I/O.
ChrisWalker
Active Member
Rocco,rocco said:
I also didn't mean to imply/infer that you were implying anything
I'm curious: what compliants regarding Z-Wave are there, that you would expect would be solved with software implementing Z-Wave overlapped I/O?
Chris
rocco
Active Member
Chris, the most common symptom being reported is that sometimes the status of polled devices come back as "Unknown". This in itself is not a big deal, since an occasional communication problem can be expected. But many users discover this while investigating long latencies in executing commands, on the order of 20 to 30 seconds.
My hypothesis is that the long latency results when a new command has to wait for multiple timeouts and retries to complete on a device that is marginally in/out of range. If the new command did not need to wait (which it wouldn't with overlapped I/O), there would be no extended latencies for unaffected devices.
My hypothesis is that the long latency results when a new command has to wait for multiple timeouts and retries to complete on a device that is marginally in/out of range. If the new command did not need to wait (which it wouldn't with overlapped I/O), there would be no extended latencies for unaffected devices.
Dean Roddey
Senior Member
That's exactly why I do it.
ChrisWalker
Active Member
Okay, I understand what you're seeing. And yes, like you said, that's an implementation issue with existing software that's interfacing with USB Z-Wave controllers or Z-Wave chips.rocco said:
The big thing that bugs me about all that is that Z-Wave gets a bad reputation in spite of its built in (but unused, or halfway implemented) functionality. I'm going to be glad to see that continue to change.
In the end, the important thing is to do what works in your own personal Z-Wave network. Both you and Dean certainly have some intelligent ideas on how to take care of things there.
And Dean, I sincerely apologize--I was just trying to help. I wasn't trying to pick on your software; you're welcome to do whatever you'd like there, but please make sure you test it well, and please work on getting Z-Wave certification on it.
Chris
Dean Roddey
Senior Member
Ok, so how, if you aren't going to have any overlapping I/O, are you going to deal with modules that don't respond. You only have two choices. You have to wait for the longest reasonable time for it to respond, or you give up and move on, in which case you are doing overlapped I/O in effect, because the request is still out there pending and may or may not complete while you are now off talking to another module.
I wasn't offended at all. I don't really get offended except in the most extreme circumstances, in which case you'd have known it.
Spanky
Senior Member
To Zwave controller manufacturers doing switch polling:
As we witnessed at EHX, a secondary controller can not HOG the Zwave network and not leave any time for other controllers to send messages. As Zwave becomes used by more companies more time between controller polls is required.
A secondary controller trying to see how fast it can poll all its switches can shut down the Zwave network for other controllers.
As we witnessed at EHX, a secondary controller can not HOG the Zwave network and not leave any time for other controllers to send messages. As Zwave becomes used by more companies more time between controller polls is required.
A secondary controller trying to see how fast it can poll all its switches can shut down the Zwave network for other controllers.
ChrisWalker
Active Member
Z-Wave certification requires that any product certified for worldwide usage cannot use more than a small percentage of available network bandwidth.WayneW said:
With almost any network (such as TCP/IP), one device can use almost all of the available bandwidth, allowing little bandwidth for any other device. One of the nice things about the Z-Wave standard is that conservative network usage is built into the protocol and protocol recommendations.
This is another one of those reasons to look for the Z-Wave logo (or Z-Wave certification statement) on any "Z-Wave" product you buy for your home.
Regarding polling, it is important to follow the Z-Wave guidelines. For instance, all of our current products allow polling (including the Z-Wave PC SDK), but we have also added lots of intelligence (based on real-world test results using Zensys development hardware) to help ensure that these products (or their derivatives, in the case of the SDK) truly play well with other Z-Wave devices.
[BTW, one issue that isn't commonly addressed is the fact that some users may be running multiple software applications, all simultaneously polling the Z-Wave network.]
Chris
Dean Roddey
Senior Member
But there's an obvious logical contradiction in all that. The requirements are:
1. Reasonably low latency, else two way is not of much use
2. No one controller can use more than a small amount of bandwidth
3. Don't allow unreliable modules to increase latency for everyone else
The constraints are
1. Low bandwidth network
2. Modules that don't send async notifications (and even if they do the controller still has to ping them periodically to make sure they are there unless those modules send "I'm alive" notifications, which also eats up bandwidth
Add those up and they kind of cancel out. If you can't use more than a small amount of bandwidth, but you have to poll since the modules don't tell you what their state is or tha they are alive. Then once the module count gets up over 25 or so, even if you can get responses from 5 modules per second, the worst case latency is now 5 seconds, and the average 2.5. But 5 modules per second is likely to be using more bandwidth than is desirable.
It's a fundamental aspect of the reality of this universe, and you can't just wave your hand and say that the SDK magically changes that equation, or at least if it does you have to explain how it does. I'm not trying to be argumentative, I'm just an engineer type and I can't just let these types of things go by without getting the facts.
1. Reasonably low latency, else two way is not of much use
2. No one controller can use more than a small amount of bandwidth
3. Don't allow unreliable modules to increase latency for everyone else
The constraints are
1. Low bandwidth network
2. Modules that don't send async notifications (and even if they do the controller still has to ping them periodically to make sure they are there unless those modules send "I'm alive" notifications, which also eats up bandwidth
Add those up and they kind of cancel out. If you can't use more than a small amount of bandwidth, but you have to poll since the modules don't tell you what their state is or tha they are alive. Then once the module count gets up over 25 or so, even if you can get responses from 5 modules per second, the worst case latency is now 5 seconds, and the average 2.5. But 5 modules per second is likely to be using more bandwidth than is desirable.
It's a fundamental aspect of the reality of this universe, and you can't just wave your hand and say that the SDK magically changes that equation, or at least if it does you have to explain how it does. I'm not trying to be argumentative, I'm just an engineer type and I can't just let these types of things go by without getting the facts.
Dean Roddey
Senior Member
As to our own bandwidth usage, I don't think it is high. We keep at most 3 outstanding poll requests, and no module is polled more often than 2 seconds since the last reply from it. So if you have 8'ish or less, then the 2 second delay provides the throttling. If you have more than that, then the limitation of only having 3 polls outstanding max provides the throttling. That allows a small system of 5 to 10 modules to have worst case responses in the 3 or 4 second range and average in the 2'ish second range which isn't too bad. But as you go up in module count the latency grows. Though an unresponsive module doesn't bring everything to a halt, it still eats up one of those 3 available slots for the maximum timeout before the slot is taken over and reused for another poll.
I can pick up the remote and do an operation and there's no noticeable delay. There's sometimes a little more delay with CQC's outgoing because it also has to wait to get access to the controller (because the outgoing commands are coming into the driver from a thread farm and those threads have to sync with the driver's poll thread to get it to stop so that the outgoing command can be sent.)
We don't just stick outgoing commands into a queue to be processed asyncrhonously because we want to send an ack/nack back to the client that sent the command.
As to getting our stuff blessed by Zen-Sys, when they make the dev kit affordable enough for us to buy it, we might consider that. But they'd have a time doing it since CQC is a couple orders of magnitude larger than Z-Wave itself and they'd have a bit of work just to learn the product enough that any blessing they give would have any meaning.
I can pick up the remote and do an operation and there's no noticeable delay. There's sometimes a little more delay with CQC's outgoing because it also has to wait to get access to the controller (because the outgoing commands are coming into the driver from a thread farm and those threads have to sync with the driver's poll thread to get it to stop so that the outgoing command can be sent.)
We don't just stick outgoing commands into a queue to be processed asyncrhonously because we want to send an ack/nack back to the client that sent the command.
As to getting our stuff blessed by Zen-Sys, when they make the dev kit affordable enough for us to buy it, we might consider that. But they'd have a time doing it since CQC is a couple orders of magnitude larger than Z-Wave itself and they'd have a bit of work just to learn the product enough that any blessing they give would have any meaning.
ChrisWalker
Active Member
Dean Roddey said:
I'm not going to ask you what your product's exact bandwidth usage is, but have you measured it via RF hardware? Do you know the duty cycle %?
Dean,Dean Roddey said:
Again, I was just trying to offer some help. We have spent a lot of time and a lot of money getting to know the intracacies of how Z-Wave works, both in real-world tests and with the Zensys development hardware. Much of the benefits of that has gone into the Z-Wave PC SDK, so software companies using that will get quite a bit of advantage there.
I respectfully understand your desire to understand more about how Z-Wave works. I also respect and understand Zensys's business model, and the need for software companies to take care of Z-Wave certification using the rapid-development PC SDK, or via a Z-Wave implementation using the Zensys embedded development kit.
I am impressed by the amount you have been able to discern about how Z-Wave works by analyzing communications between some software program and a Z-Wave controller. As for how we take care of the issue at hand, let's just say that we do not use one particular method, but a variety of methods which adapt to different types of installations at different times. This wasn't needed to get Z-Wave to work, but the resulting optimizations do provide a good complement to the Z-Wave network. No particular implementation is "best" or "perfect," but we continue to work hard to provide a good balance based on many, many factors.
Chris
