Re: Stupid design decisions

From	Don Y <blockedofcourse@foo.invalid>
Newsgroups	comp.arch.embedded
Subject	Re: Stupid design decisions
Date	2017-02-05 15:22 -0700
Organization	A noiseless patient Spider
Message-ID	<o788ft$i7l$1@dont-email.me> (permalink)
References	(9 earlier) <1jb89cl5h0jli3naf1cnadr6bb3b44ga3u@4ax.com> <o71vmm$qm1$1@dont-email.me> <MPG.32ffc5744663f9ea989813@172.16.0.1> <o75bqe$n0q$1@dont-email.me> <MPG.3301a9f1af63c5b1989815@172.16.0.1>

Show all headers | View raw

On 2/5/2017 2:31 PM, Paul wrote:
> In article <o75bqe$n0q$1@dont-email.me>, blockedofcourse@foo.invalid
> says...
>>
>> On 2/4/2017 4:03 AM, Paul wrote:
> .....
>>> I see enough issues with Wifi in houses not working or because three
>>> people are streaming they get buffering (partly due to low broadband
>>> speed). Often the heat efficient houses have foil backed dry wwalling
>>> (plasterboard), making each room into its own Faraday cage. Let alone
>>> the ones with stone walls a foot or more thick.
>>
>> Or, other emanations that cause retransmissions, etc.
>>
>> Note that not all comms can be easily "buffered" without appreciably
>> impacting performance or the UX.  Would you want your VoIP phone to
>> incur a lengthy lag just to ensure a sufficient buffer IN the device
>> to provide continuous speech in the presence of congestion?
>>
>>> If you have a MAINS connected device don't use Wifi use the Mains wiring
>>> you already have to talk yo your base station.
>>
>> Bridging the two legs of the (split) transformer, here, poses challenges
>> for high bandwidth comms when the nodes are on opposite legs.
>>
>> It also suffers from the same congestion that the wireless approach
>> experiences with a "shared medium".
>>
>> Finally, any shared medium makes it problematic to contain the traffic
>> from eavesdroppers *or* malicious attack -- even if that is just a DoS
>> attack.
>
> If you need high bandwidth for smoke detectors, light switches and the
> like then you are doing TOO much!!!

But IoT isn't limited to smoke detectors and light switches.

What do you do when your refrigerator initiates a web search to
determine who has the cheapest MILK, this week?  Then, follows up with
another search for EGGS, KETCHUP, etc.?

Meanwhile, the LCD display that replaces the front door of your
microwave oven is presenting live streaming video -- while your
kids are playing an interactive internet game on the TV in the
living room.

> Most devices do not need to update every ms more like 1s to 30s, with
> response to command probably less than 0.5 second.
>
> What the hell are you expecting to send to all these devices even 1000
> devices on a polled network with base controller can organise when they
> should poll, based on priority smoke detector much higher than light
> switch. If you cannot do all devices in 1 second then the amount of data
> is too big, the biggest part should be some form of GUID and type ID
> the rest of the data should be less than that.

See above.

Or, are you willing to redefine the devices to be allowed to participate
on your IoT network?

> At quick top of head calculation it should be doable in 10Mb link speeds
> which is easily doable on mains. I can get cheap mains networking that
> does 500Mb for streaming video.

Will it run in an apartment house setting where your neighboring
apartments are ALSO using the mains for THEIR devices?  And, the
apartment complex distributes "free CATV" using the same mechanism?

If you can do it with AC mains, then the same sort of non-problem
exists wirelessly.

> This sort of control network should NOT
> need high bandwidth. If it does then you are over specifying the IoT
> processor and its requirements in each node.

I ran 100Mb PoE to all of my nodes.  I regreted not running Gbe but the
hassles of handling the cable were just not worth the trouble in
"old construction".

I have 10 IP cameras.  What should they do with their video -- because I
don't want to "over spec'" the requirements for each node!?  Should they all
stream live video OVER THE AC MAINS to a central server that does the
real-time motion detection *and* capture?  Or, send it wirelessly?
If I do motion detection in the local node (by "over spec'ing" the
node's capabilities), that eliminates the PROCESSING requirement on
the remote server -- but, still doesn't eliminate the need to dispatch
the (now compressed!) video to that "repository".  So, there is still
a high bandwidth requirment.

Should the 6 audio channels for each "TV" be dispatched over hard wires to
the 6 speakers "near" each TV?  While the HD video is being dispatched to
the TV -- and, separately, collected from cable/satellite/OTA sources?
If I put smarts in the nodes (beyond simply reproducing lossless, baseband
audio), then I can reduce the bandwidth requirements for THAT audio.
Though, increase the complexity at the source (to mix, compress and transcode
the audio channels accordingly)

And the VoIP service?  etc.

Shared media, IMO, are NOT the answer -- despite being the easiest to
implement (for the consumer).  Instead, you want to be able to contain the
traffic and its bandwidth requirements to resources that you can scale
at will (i.e., add another network drop -- instead of having to petition
for another frequency allocation).

As with storage NEEDS increasing to fill the available disk SPACE, I
expect bandwidth requirements to fill the available bandwidth.

If you want to instill some QoS guarantees to ensure the smoke detectors
get preferential treatment -- or, the VoIP system -- then you complicate
the design of the system and the responsibilities for the user (*he* has
to resolve any competition for scarce resources)

Thread

Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-01-05 21:14 -0600
  Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-01-06 12:27 -0700
  Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-01-06 14:51 -0500
  Re: Stupid design decisions Grant Edwards <invalid@invalid.invalid> - 2017-01-06 20:22 +0000
    Re: Stupid design decisions David Brown <david.brown@hesbynett.no> - 2017-01-08 17:11 +0100
      Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-01-08 17:10 -0500
        Re: Stupid design decisions Dimiter_Popoff <dp@tgi-sci.com> - 2017-01-09 11:30 +0200
          Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-01-09 04:58 -0500
            Re: Stupid design decisions Dimiter_Popoff <dp@tgi-sci.com> - 2017-01-09 13:10 +0200
            Re: Stupid design decisions Clive Arthur <cliveta@nowaytoday.co.uk> - 2017-01-09 11:15 +0000
            Re: Stupid design decisions David Brown <david.brown@hesbynett.no> - 2017-01-09 13:48 +0100
        Re: Stupid design decisions Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2017-02-08 17:40 -0500
      Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-01-10 21:42 -0600
  Re: Stupid design decisions Tim Wescott <seemywebsite@myfooter.really> - 2017-01-06 15:33 -0600
  Re: Stupid design decisions Ed Prochak <edprochak@gmail.com> - 2017-01-30 12:28 -0800
    Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-01-30 13:52 -0700
      Re: Stupid design decisions Grant Edwards <invalid@invalid.invalid> - 2017-01-30 20:55 +0000
        Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-01-30 14:18 -0700
          Re: Stupid design decisions Grant Edwards <invalid@invalid.invalid> - 2017-01-30 21:20 +0000
            Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-01-30 14:31 -0700
              Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-01-30 23:37 -0600
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-01-30 23:20 -0700
                Re: Stupid design decisions Ed Prochak <edprochak@gmail.com> - 2017-01-30 22:29 -0800
                Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-01-31 02:10 -0500
        Re: Stupid design decisions Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-01-30 22:30 +0100
        Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-01-31 02:00 -0500
      Re: Stupid design decisions Ed Prochak <edprochak@gmail.com> - 2017-01-30 22:18 -0800
        Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-01-30 23:36 -0700
        Re: Stupid design decisions jladasky@itu.edu - 2017-01-31 16:01 -0800
          Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-02 09:47 +0000
            Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-02-02 06:35 -0500
              Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-02-02 16:26 -0600
                Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-02-02 19:49 -0500
                Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 01:27 -0600
                Re: Stupid design decisions Les Cargill <lcargill99@comcast.com> - 2017-02-03 07:18 -0600
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-03 10:14 -0700
                Re: Stupid design decisions Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2017-02-03 10:12 -0800
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-03 14:10 -0700
                Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-04 11:15 +0000
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-04 13:52 -0700
                Re: Stupid design decisions Grant Edwards <invalid@invalid.invalid> - 2017-02-05 04:36 +0000
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-04 21:55 -0700
                Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-05 21:39 +0000
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 15:55 -0700
                Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-05 23:38 +0000
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 21:25 -0700
                Re: Stupid design decisions Les Cargill <lcargill99@comcast.com> - 2017-02-04 17:26 -0600
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-04 16:56 -0700
                Re: Stupid design decisions Les Cargill <lcargill99@comcast.com> - 2017-02-03 21:40 -0600
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-03 21:48 -0700
                Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-04 11:03 +0000
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-04 13:00 -0700
                Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-02-05 01:49 -0600
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 10:43 -0700
                Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-05 21:31 +0000
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 15:22 -0700
                Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-05 23:24 +0000
                Re: Stupid design decisions Grant Edwards <invalid@invalid.invalid> - 2017-02-06 03:51 +0000
                Re: Stupid design decisions Paul <paul@pcserviceselectronics.co.uk> - 2017-02-06 10:11 +0000
                Re: Stupid design decisions rickman <gnuarm@gmail.com> - 2017-02-06 20:07 -0500
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 21:08 -0700
                Re: Stupid design decisions mac <acolvin@efunct.com> - 2017-02-04 14:42 +0000
                Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-02-05 02:00 -0600
                Re: Stupid design decisions Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-05 09:11 +0000
                Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-02-05 03:51 -0600
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 11:10 -0700
                Re: Stupid design decisions Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-02-05 22:22 +0000
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 16:01 -0700
                Re: Stupid design decisions Don Y <blockedofcourse@foo.invalid> - 2017-02-05 11:03 -0700
    Re: Stupid design decisions Robert Wessel <robertwessel2@yahoo.com> - 2017-01-30 23:44 -0600

csiph-web