On 18/10/15 23:07, Les Cargill wrote:> David Brown wrote: >> On 18/10/15 20:15, Les Cargill wrote: >>> David Brown wrote: >>>> On 16/10/15 16:10, Les Cargill wrote: >>>>> David Brown wrote: >>>>>> On 16/10/15 03:19, Les Cargill wrote: >>>>>>> Dimiter_Popoff wrote: >>>> <snip> >>>>>>> Tactically, UDP is preferable for real-time-ish things. >>>>>>> This is especially true if the things are local to each other - >>>>>>> say, no the same basically layer 2 network without much routing >>>>>>> in place. >>>>>> >>>>>> There must be an emphasis here on the "real-time-ish" rather than >>>>>> "real >>>>>> time". With UDP, you still have layers of ARP, ICMP, and other >>>>>> details >>>>>> - although it is possible to reduce them greatly with static ARP >>>>>> tables. >>>>> >>>>> >>>>> Once the sockets are established, all that overhead is behind you. >>>> >>>> No, it is not /all/ behind you - just most of it. ARP caches are >>>> regularly refreshed, with re-checks of the IP to MAC pairings. And >>>> unless you are alone on the network, and you have no other connections >>>> or traffic from the nodes you control, there is always other packets >>>> and >>>> broadcasts going on. Small embedded systems don't usually produce much >>>> chatter, >>> >>> >>> In general. That's why it's less of a concern for embedded systems. >>> I at least hope that actual deployment configurations are controlled >>> so it should be relatively simple to measure this and control that as >>> well. >> >> The deployment configuration for embedded systems vary enormously. > > That is a big problem for whoever is deploying them, then.No, that depends entirely on the embedded system in question. For some systems, there should be tight control. But some embedded systems are /supposed/ to be installed anywhere. If you are making an IoT device, as is the current fad, then you have to cope with any sort of network setup and network traffic that the customer has. When you make your internet-connected fridge that talks to an internet-connected freezer and automatically orders milk and ice-cream every second day, then you don't get to dictate what the customer connects to their network. Of course, such a system is far from real-time. I'll leave it to your imagination to think of something that might have critical timing, and might also legitimately have mixes of network equipment.> >> Some >> have careful, controlled environments - others get mixed with everything >> else on a network. In many cases you might /think/ the customer will be >> careful in their network setup, but despite all your specifications and >> documentation, they just plug everything together and assume it will >> work. Remember, the customer is always right - even when they are wrong! >> > > No, the customer is not always right. A customer who can't identify > and act in their own self-interest isn't a customer any > more, they're a problem.My statement was (I thought) obviously a little tongue-in-cheek. But there is some truth in the matter too. If you make a system with several cards that communicate over Ethernet, perhaps controlled by a PC, and it has trouble when the customer connects something else to the network - then /you/ have a problem. Even if you have clearly specified that nothing else shall be connected, if the customer has problems due to an unreasonable (in his eyes) restriction, then /you/ are seen as being inflexible and awkward. A supplier who points to the wording in the contract and refuses to help here is unlikely to get sued - but also unlikely to get repeat custom.> > It think you'll find the world to be moving more that way. >I think it is moving the other way. I have worked in embedded systems design for over twenty years, and I have yet to find a customer who had a /complete/ specification at the outset of the project, and who did not want to change at least a little part of it along the way, or after the development was complete. Of course sometimes the job of the supplier is to tell the customer when he is wrong - but you try to help out in the best way possible. (Billing the customer as appropriate, of course.)
SmartFusion2 SoC
Started by ●October 14, 2015
Reply by ●October 18, 20152015-10-18
Reply by ●October 18, 20152015-10-18
David Brown wrote:> On 18/10/15 23:07, Les Cargill wrote: >> David Brown wrote: >>> On 18/10/15 20:15, Les Cargill wrote: >>>> David Brown wrote: >>>>> On 16/10/15 16:10, Les Cargill wrote: >>>>>> David Brown wrote: >>>>>>> On 16/10/15 03:19, Les Cargill wrote: >>>>>>>> Dimiter_Popoff wrote: >>>>> <snip> >>>>>>>> Tactically, UDP is preferable for real-time-ish things. >>>>>>>> This is especially true if the things are local to each other - >>>>>>>> say, no the same basically layer 2 network without much routing >>>>>>>> in place. >>>>>>> >>>>>>> There must be an emphasis here on the "real-time-ish" rather than >>>>>>> "real >>>>>>> time". With UDP, you still have layers of ARP, ICMP, and other >>>>>>> details >>>>>>> - although it is possible to reduce them greatly with static ARP >>>>>>> tables. >>>>>> >>>>>> >>>>>> Once the sockets are established, all that overhead is behind you. >>>>> >>>>> No, it is not /all/ behind you - just most of it. ARP caches are >>>>> regularly refreshed, with re-checks of the IP to MAC pairings. And >>>>> unless you are alone on the network, and you have no other connections >>>>> or traffic from the nodes you control, there is always other packets >>>>> and >>>>> broadcasts going on. Small embedded systems don't usually produce much >>>>> chatter, >>>> >>>> >>>> In general. That's why it's less of a concern for embedded systems. >>>> I at least hope that actual deployment configurations are controlled >>>> so it should be relatively simple to measure this and control that as >>>> well. >>> >>> The deployment configuration for embedded systems vary enormously. >> >> That is a big problem for whoever is deploying them, then. > > No, that depends entirely on the embedded system in question. For some > systems, there should be tight control. But some embedded systems are > /supposed/ to be installed anywhere. If you are making an IoT device, > as is the current fad, then you have to cope with any sort of network > setup and network traffic that the customer has. When you make your > internet-connected fridge that talks to an internet-connected freezer > and automatically orders milk and ice-cream every second day, then you > don't get to dictate what the customer connects to their network. >It's still a problem. It's just that the people who will be involved in this will ignore it. And this is why the IoT is increasingly shrill and silly. You may be aware that people have hacked cars and airplanes(!) through the "entertainment system" recently. So it's quite the problem, even if the people who sold it didn't think about it. *This being said!* with any luck, I'll be IoTing the heck out of a bunch of stuff within the next few years but only on strictly controlled private media. This is a case where it's not silly at all.> Of course, such a system is far from real-time. I'll leave it to your > imagination to think of something that might have critical timing, and > might also legitimately have mixes of network equipment. >No, you don't have to leave it to my imagination - I've seen it. That's largely why I commented. And frankly, it takes some doing to completely mess this up. Stuff generally works well over a huge variety of options - you might have to relax a timeout or two but that's usually not a serious problem.>> >>> Some >>> have careful, controlled environments - others get mixed with everything >>> else on a network. In many cases you might /think/ the customer will be >>> careful in their network setup, but despite all your specifications and >>> documentation, they just plug everything together and assume it will >>> work. Remember, the customer is always right - even when they are wrong! >>> >> >> No, the customer is not always right. A customer who can't identify >> and act in their own self-interest isn't a customer any >> more, they're a problem. > > My statement was (I thought) obviously a little tongue-in-cheek. But > there is some truth in the matter too. >Sure. No, there kind of isn't. Increasingly, we'll be responsible for it because we're supposed to be the adults here.> If you make a system with several cards that communicate over Ethernet, > perhaps controlled by a PC, and it has trouble when the customer > connects something else to the network - then /you/ have a problem.They have a problem. You're there to help. This is a big difference.> Even if you have clearly specified that nothing else shall be connected,Exactly.> if the customer has problems due to an unreasonable (in his eyes) > restriction, then /you/ are seen as being inflexible and awkward.Well, I'll obviously exhaust all reasonable alternatives first. But at that point, I don't care. I really don't. He's a schmuck. I'll of course have the appropriate audit trail, but it'll go like this: "Do you want it to work?" "Yes." "Then you can't do that." "Why?" "Because it doesn't work. <Z> happens and that's not what you wanted." "Why?" "Because you did it wrong. Check page 13 of the spec. It's right there in black and white. You have to do <x> and <y> to fix it. The number of corporate counsel is <XXX-XXX-XXXX> if you have a problem with this. I'll bend heaven and earth to help you make <x> and <y> happen, but those are necessary prerequisites for the correct operation of the system, you signed off on it and this is not negotiable."> A > supplier who points to the wording in the contract and refuses to help > here is unlikely to get sued - but also unlikely to get repeat custom. >you say that like it's a bad thing. You are welcome to him/her as a customer.>> >> It think you'll find the world to be moving more that way. >> > > I think it is moving the other way. >And I think you'll be surprised.> I have worked in embedded systems design for over twenty years, and I > have yet to find a customer who had a /complete/ specification at the > outset of the project, and who did not want to change at least a little > part of it along the way, or after the development was complete. >I generally don't have any heartburn with that *at all*, but as I read the thread, we're talking about what amounts to them behaving like a five-year-old.> Of course sometimes the job of the supplier is to tell the customer when > he is wrong - but you try to help out in the best way possible.Of course. The scenario I described comes up only after agonizing weeks of diagnosis and problem identification. And it has to be pretty inherent to the identified problem.> (Billing the customer as appropriate, of course.) >I sincerely hope never to have to worry about that again. -- Les Cargill
Reply by ●October 18, 20152015-10-18
On 19.10.2015 г. 04:37, Les Cargill wrote:>>...... When you make your >> internet-connected fridge that talks to an internet-connected freezer >> and automatically orders milk and ice-cream every second day, then you >> don't get to dictate what the customer connects to their network. >> > > It's still a problem. It's just that the people who will be involved in > this will ignore it. And this is why the IoT is increasingly > shrill and silly. > > You may be aware that people have hacked cars and airplanes(!) > through the "entertainment system" recently.This is just because the IoT is widely based on messy stuff like all the FOSS etc. thing and/or half (or less) baked tcp/ip stacks deployed by MCU manufacturers. Virtually nobody making these things knows what exactly they are doing. Try to hack into one of our netmca devices - and good luck with that. They were IoT-ing years before the IoT phrase was coined so I don't know if they do qualify as such.... Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
