ddennerline
Active Member
I had originally started to reply to a post that indicated Elk was interrupt driven and polling is inefficient. Therefore polling cannot be implemented. I keep hearing comments that M1XSP modules cannot implement polling effectively. I am not privy to M1XSP internal architecture, but I thought I would open up this thread with hope that other people (perhaps more knowledgeable than I) can throw darts at argument below. I know that polling has been requested for Z-Wave and also for other lighting/load technologies. Interrupt driven lighting does have the benefit of lower status/response latency.
Without getting into a gigantic academic/theoretical debate, polling is not inefficient. Polling can be more efficient that interrupt driven I/O. RouteBricks.org (http://routebricks.org/papers/rb-sosp09.pdf) has some interesting facts and describes how Clustered Router (greater than 10GB) is designed using COTS (Common-off-the-shelf) hardware. This whole polling is inefficient mantra provides a opening for not addressing a system’s design as a whole. The issue is not black-n-white. Input event processing (i.e., receive queuing) architecture depends on many different factors: communication hardware, sharing of CPU, interrupt latency, CPU speed, thermal character, and physical link error rates.
A back-of-the-napkin calculation for a modern 8051 microcontroller. It's possible to (http://www.keil.com/dd/docs/datashts/actel/core8051_ds.pdf):
baud = 9,600
bits/byte = 8
chars/sec = 1200
full duplex = 2400
cpu = 25,000,000
ipc = 0.5
instruction/sec = 12,500,000
character/instruction = 5,208
average command size = 16
commands/sec = 326
I suspect it’s possible to support a 64 node network using exclusively polling if there are few retransmissions required (i.e., the layer2 physical medium is reliable). As the baud rate increases, the hardware/CPU must increase too. There may be other bottlenecks such as size of RS-232 transmit/receive queue that would need to be considered.
Without getting into a gigantic academic/theoretical debate, polling is not inefficient. Polling can be more efficient that interrupt driven I/O. RouteBricks.org (http://routebricks.org/papers/rb-sosp09.pdf) has some interesting facts and describes how Clustered Router (greater than 10GB) is designed using COTS (Common-off-the-shelf) hardware. This whole polling is inefficient mantra provides a opening for not addressing a system’s design as a whole. The issue is not black-n-white. Input event processing (i.e., receive queuing) architecture depends on many different factors: communication hardware, sharing of CPU, interrupt latency, CPU speed, thermal character, and physical link error rates.
A back-of-the-napkin calculation for a modern 8051 microcontroller. It's possible to (http://www.keil.com/dd/docs/datashts/actel/core8051_ds.pdf):
baud = 9,600
bits/byte = 8
chars/sec = 1200
full duplex = 2400
cpu = 25,000,000
ipc = 0.5
instruction/sec = 12,500,000
character/instruction = 5,208
average command size = 16
commands/sec = 326
I suspect it’s possible to support a 64 node network using exclusively polling if there are few retransmissions required (i.e., the layer2 physical medium is reliable). As the baud rate increases, the hardware/CPU must increase too. There may be other bottlenecks such as size of RS-232 transmit/receive queue that would need to be considered.