Ethernet Polling vs Broadcasting on an Embedded device

Nicholas O. Lindan wrote:
> I think you missed the point.  Drop the cute.  Cute sucks,
> though among the cultured it is said to aspirate.  Ditto
> smileys and exclamation points.

Ouch.


> Engineers who can get meet a customer's _real_ needs with a 
> quality system installed on time and on budget and with no 
> surprises are rare and highly valued.

Ah, yes, reality.  You are quite right, of course, and make many 
excellent points regarding process.  In the end, the customer wants 
their needs met at the lowest cost, and they rarely care about the 'how' 
or whether it piques your personal interests.

Ditto in corporate life - no matter how much you enjoy the details, the 
executives just want to know what it'll do, when it'll be done, and what 
it'll cost - they emphatically *don't* want to hear the details.

In the Real World, I'd rank a custom solution low on the list against a 
COTS product, primarily due to long-term lifecycle / support costs 
(future features, hidden design flaws, maintenance replacements, etc.) 
After all, the customer is in the cold storage business, not the 'cold 
storage environmentals monitoring widget' business.

However, it *is* loads of fun to dig into the details given the 
opportunity.  Especially when the 'customer requirement' is something 
like "demonstrate various skills by creating a useful but otherwise 
redundant product from scratch".  I.e., technology for technology's sake 
- a rare opportunity in the real world, to be enjoyed by some to its 
fullest.

"Richard H." <rh86@no.spam> wrote

> However, it *is* loads of fun to dig into the details given the 
> opportunity.  Especially when the 'customer requirement' is something 
> like "demonstrate various skills by creating a useful but otherwise 
> redundant product from scratch".

Absolutely.

But for one caveat: "redundant product" ...

Designing a redundant product is a waste of, well, 
just about everything.  Creating pollution but no solution.

Whatever you do should have real novelty.  For that:

 o Figure out what to attack:

   Who's got the money?  
   What makes you tick?

 o Figure out how to attack:
   - a new way
   - a cheaper way
   - a more environmental way
   - a better, faster ... blah, blah, blah
   Settle for attacking just one.

Find a quiet place that will let you and your compatriots sit all 
afternoon nursing a few beers.  Bring a bundle of fibre-tip pens.  
Ask for a stack of napkins.  Keep the bar receipt, it's deductible 
from your income taxes.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
To reply, remove spaces: n o lindan at ix  . netcom . com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/

linuxdude wrote:
> We are in favor of using a client/server model using UDP as
> the communication protocol. The problem is, if all the devices
[...]
> May be TCP/IP might be a better option here. If there is a
> better mechanism it would be very valuable at this stage to
> know about it.

Grant Edwards <grante@visi.com> writes:
> You could add your own ack/retry scheme on top of UDP.

And you could add sliding windows, and selective retransmits, and
support for out-of-band data, and path MTU discovery, and...

If you really need a message-oriented protocol, it's much easier
to layer one on top of TCP than to build a custom reliable datagram
transport on top of UDP.

On 2005-03-01, Eric Smith <eric@brouhaha.com> wrote:
> linuxdude wrote:
>> We are in favor of using a client/server model using UDP as
>> the communication protocol. The problem is, if all the devices
> [...]
>> May be TCP/IP might be a better option here. If there is a
>> better mechanism it would be very valuable at this stage to
>> know about it.
>
> Grant Edwards <grante@visi.com> writes:
>> You could add your own ack/retry scheme on top of UDP.
>
> And you could add sliding windows, and selective retransmits,
> and support for out-of-band data, and path MTU discovery,
> and...
>
> If you really need a message-oriented protocol, it's much
> easier to layer one on top of TCP than to build a custom
> reliable datagram transport on top of UDP.

Why take the easy route?  After all: "it's a research project,
it doesn't _have_ to work." ;)

-- 
Grant Edwards                   grante             Yow!  Mr and Mrs PED, can
                                  at               I borrow 26.7
                               visi.com            

On 28 Feb 2005 14:21:28 -0800, "linuxdude" <easylinux@gmail.com>
wrote:


>1) Should the Server poll the clients (using a TCP/IP or UDP client
>server model) on a constant time interval.
>2) Should the Clients send a broadcast at random interval and let the
>Server listen to them
>3) Should the Client send a multi cast packet of some sort and let the
>Server take care of it.

Well if you use broadcasts you cant route it , as routers are designed
NOT to route broadcasts.


So using broadcasts you will have to have all your sensors on same
physical lan (layer2) as the server.

Carsten

Carsten wrote:
> Well if you use broadcasts you cant route it , as routers are designed
> NOT to route broadcasts.

multicast.

But I think multicast (or broadcast) is lame for a network of weather 
sensors since little traffic is of interest to the average sensor.  The 
real question is polled versus autonomous operation, and the autonomous 
solution ends up requiring time synchronization on the sensors, which 
seems like overkill for a gorified thermometer.  So poll the sensors, 
and if having one master is impractical due to the workload or bandwidth 
requirements, then have submasters polling subdomains of sensors and 
aggregating data for the big kahuna master.

Frankly, though, I'd prototype this using autonomous sensors and 
transferring data with syslog.

Kelly

Wow, thats a lot of information. Thanks to all of you! I am going to
look into every one of the suggestion and see what would be the ideal
solution. Also, I have some new ideas to apply too! POE, going towards
a Rabbit microprocessor with the TCP/IP stack, Custom UDP with ack &
retransmit.

Since, we are still engaged in the brain storming sessions, we still
have lot of time to finalize how the end product will be. But the
ultimate goal is to design something with Ethernet & possibly an
embedded Linux. I am sure it will be a great learning experience for us
& I really appreciate all your help.

LD

"linuxdude" <easylinux@gmail.com> wrote

> Also, I have some new ideas to apply too! POE, going towards
> a Rabbit microprocessor with the TCP/IP stack, Custom UDP with ack &
> retransmit ... embedded Linux.

Maybe not such new ideas after all:

http://demo.zweng.com/

-- 
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
To reply, remove spaces: n o lindan at ix  . netcom . com

Nicholas O. Lindan wrote:
> "linuxdude" <easylinux@gmail.com> wrote
>
> > Also, I have some new ideas to apply too! POE, going towards
> > a Rabbit microprocessor with the TCP/IP stack, Custom UDP with ack
&
> > retransmit ... embedded Linux.
>
> Maybe not such new ideas after all:
>
> http://demo.zweng.com/

That demo is long gone. Here's the new one:
  http://69.104.38.49:8146/

A single RCM3700 is used now.
  http://www.rabbitsemiconductor.com/products/CoreModules/index.shtml

More demos:
  http://www.rabbitsemiconductor.com/products/dc/demos/index.shtml