SmartFusion2 SoC

On Thu, 15 Oct 2015 02:00:27 -0400, rickman <gnuarm@gmail.com> wrote:

>On 10/15/2015 1:36 AM, Paul Rubin wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> What all can you do using UDP instead of TCP?  Can you serve up web
>>> pages?  The primary reason for using TCP is the reliability from what
>>> I understand.  But if this is a local, point to point connection that
>>> should not be an issue, no?
>>
>> HTTP (used for serving web pages) is a protocol that runs over TCP, so
>> no you can't serve web pages with UDP.  UDP is typically used for low
>> latency or realtime protocols (say VOIP) where you if you drop a packet
>> here or there, you want to keep going rather than try to recover it.
>> Some people decide to add a reliability layer over UDP and end up doing
>> a bad reimplementation of TCP, so if you want TCP it's better to just
>> use it.  There are some very lightweight TCP stacks out there, but as
>> Dimiter says, you lose performance if you don't have enough ram to
>> buffer several large-ish packets.
>>
>> I do expect UDP to be pretty reliable within a LAN segment unless
>> there's a ton of congestion.
>
>I don't think that HTTP *requires* TCP does it?  Isn't that why the ISO 
>model done in layers?  Can't HTTP be sent over other transport and 
>session layers?  If the link is highly reliable, such as a USB 
>interface, can't UDP serve as well as TCP?  Or are there other issues 
>involved?


TCP/IP is not OSI.

While OSI does provide some (limited) ability to swap out protocol
layers, mainly because the semantics of the layers are somewhat more
abstractly defined, but you're generally not going to be able to swap
connection-mode for connectionless-mode transport layers under an
application.  For two different connection-mode layers, you have a
good shot, but not between the different classes.

That being said, there's no reason one could not create a UDP-based
HTTP (such a spec would require reinventing much of what TCP does -
the HTTP spec does require a reliable transport, for example), or even
one for OSI CONS/TP3 (and that would be fairly easy), but the current
specs do *not* actually do that.  So HTTP cannot run over anything
other than TCP, since the bindings for running HTTP over anything
other than TCP have not been written.  Nor have they been widely
implemented, which is the real problem.  If you wanted to serve web
pages over UDP, even if there were a protocol defined, it's not
implemented by any browsers.

Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> I have never been particularly impressed with SNMP, but I haven't had
>> much need of it.  ...  (However, I agree that UDP is the appropriate
>> choice here, rather than TCP.  They got that bit right.)
>
> I didn't realize SNMP was used much any more, except in weird old
> legacy-descended devices.  I thought newer stuff tends to have embedded
> web servers instead of SNMP.
>


It is still used very widely. Embedded
web servers are fine for your SOHO router
but you wouldn't want to configure thousands of them in
that way.

What's supplanted it are things like XML and JSON. As
the Internet protocol suite has moved from being a
commons to being a showcase for this
company or that company's pet project, it's
become ... quieter.

I brought it up only to illustrate some
design choices made in its development.

-- 
Les Cargill

Paul Rubin wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> In one case, I measured five minutes before the failure
>> was signaled by the stack.
>
> It can be longer than that.  If you need to detect disconnections
> quicker than that, simplest is build a heartbeat into your protocol.

Yep. So we're back to duplicating over TCP what
you have to do anyway for UDP.

> Each end is required to send a message every few seconds and the other
> end times out if the message doesn't arrive within a slight delay of
> when it's expected.
>

Exactly.

-- 
Les Cargill

Robert Wessel wrote:
<snip>
>
> That being said, there's no reason one could not create a UDP-based
> HTTP (such a spec would require reinventing much of what TCP does -
> the HTTP spec does require a reliable transport, for example), or even
> one for OSI CONS/TP3 (and that would be fairly easy), but the current
> specs do *not* actually do that.  So HTTP cannot run over anything
> other than TCP, since the bindings for running HTTP over anything
> other than TCP have not been written.  Nor have they been widely
> implemented, which is the real problem.  If you wanted to serve web
> pages over UDP, even if there were a protocol defined, it's not
> implemented by any browsers.
>

Google offers a thing called QUIC that supposedly
addresses this.

-- 
Les Cargill

Les Cargill <lcargill99@comcast.com> writes:
> It is still used very widely. Embedded web servers are fine for your
> SOHO router but you wouldn't want to configure thousands of them in
> that way.  What's supplanted it are things like XML and JSON.

Right, stuff tends to have XML or JSON API's now.  Think of OpenStack etc.

Paul Rubin wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> It is still used very widely. Embedded web servers are fine for your
>> SOHO router but you wouldn't want to configure thousands of them in
>> that way.  What's supplanted it are things like XML and JSON.
>
> Right, stuff tends to have XML or JSON API's now.  Think of OpenStack etc.
>

You may or may not have the opportunity ( and it's old and busted ) ,
but I recommend understanding SNMP at a fairly deep level because all
the issues with transactions at a distance are  included in it.

Because when you provision a node, it's transactions as-if you
were posting to a general ledger. It's all one thing.

For example, if you post XML to a node to configure it,
what happens when *one* element is out of sorts? You should
roll back the entire thing as if it never happened.

It's funny, but a lot of the instabilities I've
run into on projects were exactly this issue.  I'd done
work related to financial transactions for a short stint
before that.

Every time I have to reboot my home router because the
firmware people didn't understand this, I grind my
teeth a little :)

-- 
Les Cargill

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, but if you've got PC's there, the noise they make adds up.

All I am saying is that there /is/ non-deterministic delays on the
network, even with UDP.  It is lower than with TCP/IP, and you can take
steps to greatly reduce it - but don't make the mistake of suggesting
that you can put two nodes on a network and get real-time-ish behaviour
as long as you use UDP.  On most networks, the difference in throughput,
latency, and maximum timing jitter (the key metric for "real time") is
negligible between UDP and TCP/IP.

> 
>>   To get closer to real-time, you need to make sure that you are working
>> on a closed network - no Windows machines chattering away with endless
>> pointless broadcast telegrams.  And for the lowest overhead and most
>> predictable networking, use Ethernet telegrams directly rather than IP.
>>
> 
> That's fine if you can manage it. It's extremely nonportable and
> somewhat painful. Undfferenitiated sockets are generally better.

It is not /that/ hard.  An Ethernet packet is not harder to make or use
than any other sort of communication packet - you've got a header, a
source and destination MAC address, your payload, and a CRC (usually
filled in by the lower layers, or even the Ethernet MAC hardware).  You
can send and receive them on most systems.

Raw Ethernet packets might not be a good choice for many applications,
but there is no doubt that they give you the lowest overhead and most
predictable behaviour on an Ethernet link.  It is used, for example, for
ATA over Ethernet to get the minimal latency and maximal throughput for
disk access.

> 
>> But as you say, UDP gives you more real-time-ish when you have a simple
>> local network.  In particular, you have full control of things like
>> timeouts, packet ordering, packet fragmentation, acknowledgements and
>> retries.  That means more effort in the application code to keep it all
>> working well, but more flexibility.
>>
>> If you have more complex routing then the mostly predictable nature of
>> UDP is lost anyway, so TCP is usually a better choice since it works
>> smoother with routing setups.
>>
> 
> Right.
> 

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.

> but if you've got PC's there, the noise they make adds up.
>

Even then, it doesn't add up to much, and if you have a
true learning bridge it will be minimal. Of course there
are actual broadcast messages from Windows,
but  you might be able to turn those off.

It's also worth understanding the O/S on the
PeeCees enough to keep this to a minimum.

> All I am saying is that there /is/ non-deterministic delays on the
> network, even with UDP.

Of course!

> It is lower than with TCP/IP, and you can take
> steps to greatly reduce it - but don't make the mistake of suggesting
> that you can put two nodes on a network and get real-time-ish behaviour
> as long as you use UDP.

Agreed. But it's also true that an awful lot in life
works fine win the 10 msec cycle range. For displays,
this may be as slow as 500 msec.

> On most networks, the difference in throughput,
> latency, and maximum timing jitter (the key metric for "real time") is
> negligible between UDP and TCP/IP.
>

For most cases, yes. Indeed, they're nearly identical except
for a handful of pathological cases.


>>
>>>    To get closer to real-time, you need to make sure that you are working
>>> on a closed network - no Windows machines chattering away with endless
>>> pointless broadcast telegrams.  And for the lowest overhead and most
>>> predictable networking, use Ethernet telegrams directly rather than IP.
>>>
>>
>> That's fine if you can manage it. It's extremely nonportable and
>> somewhat painful. Undfferenitiated sockets are generally better.
>
> It is not /that/ hard.  An Ethernet packet is not harder to make or use
> than any other sort of communication packet - you've got a header, a
> source and destination MAC address, your payload, and a CRC (usually
> filled in by the lower layers, or even the Ethernet MAC hardware).  You
> can send and receive them on most systems.
>

In general, the world doesn't want you doing that.

> Raw Ethernet packets might not be a good choice for many applications,
> but there is no doubt that they give you the lowest overhead and most
> predictable behaviour on an Ethernet link.  It is used, for example, for
> ATA over Ethernet to get the minimal latency and maximal throughput for
> disk access.
>
<snip>

-- 
Les Cargill

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.  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!


> 
>> but if you've got PC's there, the noise they make adds up.
>>
> 
> Even then, it doesn't add up to much, and if you have a
> true learning bridge it will be minimal. Of course there
> are actual broadcast messages from Windows,
> but  you might be able to turn those off.

There are always more broadcasts than you would expect.  And whenever
you have a PC, there is (almost) always someone who installs more
software without due consideration.

Often these broadcasts and other traffic are not a problem.  But when
you use the magic phrase "real-time", even if it is "real-time-ish", you
have to think worst-case.

> 
> It's also worth understanding the O/S on the
> PeeCees enough to keep this to a minimum.
> 
>> All I am saying is that there /is/ non-deterministic delays on the
>> network, even with UDP.
> 
> Of course!
> 
>> It is lower than with TCP/IP, and you can take
>> steps to greatly reduce it - but don't make the mistake of suggesting
>> that you can put two nodes on a network and get real-time-ish behaviour
>> as long as you use UDP.
> 
> Agreed. But it's also true that an awful lot in life
> works fine win the 10 msec cycle range. For displays,
> this may be as slow as 500 msec.

Agreed.

Ethernet networks of various sorts are often perfectly good for control
systems, whether you use UDP, TCP/IP, raw Ethernet packets, or anything
else.  All I am saying is that one must be careful about trying to
specify or guarantee some sort of real-time behaviour - using UDP is not
sufficient, and rarely makes a big difference.

> 
>> On most networks, the difference in throughput,
>> latency, and maximum timing jitter (the key metric for "real time") is
>> negligible between UDP and TCP/IP.
>>
> 
> For most cases, yes. Indeed, they're nearly identical except
> for a handful of pathological cases.
> 
> 
>>>
>>>>    To get closer to real-time, you need to make sure that you are
>>>> working
>>>> on a closed network - no Windows machines chattering away with endless
>>>> pointless broadcast telegrams.  And for the lowest overhead and most
>>>> predictable networking, use Ethernet telegrams directly rather than IP.
>>>>
>>>
>>> That's fine if you can manage it. It's extremely nonportable and
>>> somewhat painful. Undfferenitiated sockets are generally better.
>>
>> It is not /that/ hard.  An Ethernet packet is not harder to make or use
>> than any other sort of communication packet - you've got a header, a
>> source and destination MAC address, your payload, and a CRC (usually
>> filled in by the lower layers, or even the Ethernet MAC hardware).  You
>> can send and receive them on most systems.
>>
> 
> In general, the world doesn't want you doing that.

I'm not paranoid - I /know/ the whole world is against me...

Yes, there are complications in using raw Ethernet, such as requiring
extra libraries on Windows or root privileges in Linux, to say nothing
of having to battle network administrators!  But on a closed network,
they are not hard to use.

> 
>> Raw Ethernet packets might not be a good choice for many applications,
>> but there is no doubt that they give you the lowest overhead and most
>> predictable behaviour on an Ethernet link.  It is used, for example, for
>> ATA over Ethernet to get the minimal latency and maximal throughput for
>> disk access.
>>
> <snip>
> 

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.

> 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.

It think you'll find the world to be moving more that way.

>
>>
>>> but if you've got PC's there, the noise they make adds up.
>>>
>>
>> Even then, it doesn't add up to much, and if you have a
>> true learning bridge it will be minimal. Of course there
>> are actual broadcast messages from Windows,
>> but  you might be able to turn those off.
>
> There are always more broadcasts than you would expect.  And whenever
> you have a PC, there is (almost) always someone who installs more
> software without due consideration.
>

Again - if you do not control configurations, you will suffer. That
is only my problem to the extent I can bill you to straighten it out
or otherwise unsnarl it if I have more of a retainer relationship.


> Often these broadcasts and other traffic are not a problem.  But when
> you use the magic phrase "real-time", even if it is "real-time-ish", you
> have to think worst-case.
>

Yeah, it's a slippery word. But we live in an era where the fastest bus 
is cheap and plentiful, and where a node is is less of an issue than 
it's ever been.

99% of real-time isn't.

>>
>> It's also worth understanding the O/S on the
>> PeeCees enough to keep this to a minimum.
>>
>>> All I am saying is that there /is/ non-deterministic delays on the
>>> network, even with UDP.
>>
>> Of course!
>>
>>> It is lower than with TCP/IP, and you can take
>>> steps to greatly reduce it - but don't make the mistake of suggesting
>>> that you can put two nodes on a network and get real-time-ish behaviour
>>> as long as you use UDP.
>>
>> Agreed. But it's also true that an awful lot in life
>> works fine win the 10 msec cycle range. For displays,
>> this may be as slow as 500 msec.
>
> Agreed.
>
> Ethernet networks of various sorts are often perfectly good for control
> systems, whether you use UDP, TCP/IP, raw Ethernet packets, or anything
> else.  All I am saying is that one must be careful about trying to
> specify or guarantee some sort of real-time behaviour - using UDP is not
> sufficient, and rarely makes a big difference.
>

So I at least manage that with instrumentation in the networking
code. I at very least keep counters and may provide some sort of
log to document such failures.

I do that for my *OWN* testing. Sometimes it gets
turned off for deployment, sometimes it doesn't.

>>
>>> On most networks, the difference in throughput,
>>> latency, and maximum timing jitter (the key metric for "real time") is
>>> negligible between UDP and TCP/IP.
>>>
>>
>> For most cases, yes. Indeed, they're nearly identical except
>> for a handful of pathological cases.
>>
>>
>>>>
>>>>>     To get closer to real-time, you need to make sure that you are
>>>>> working
>>>>> on a closed network - no Windows machines chattering away with endless
>>>>> pointless broadcast telegrams.  And for the lowest overhead and most
>>>>> predictable networking, use Ethernet telegrams directly rather than IP.
>>>>>
>>>>
>>>> That's fine if you can manage it. It's extremely nonportable and
>>>> somewhat painful. Undfferenitiated sockets are generally better.
>>>
>>> It is not /that/ hard.  An Ethernet packet is not harder to make or use
>>> than any other sort of communication packet - you've got a header, a
>>> source and destination MAC address, your payload, and a CRC (usually
>>> filled in by the lower layers, or even the Ethernet MAC hardware).  You
>>> can send and receive them on most systems.
>>>
>>
>> In general, the world doesn't want you doing that.
>
> I'm not paranoid - I /know/ the whole world is against me...
>

You may have to use ... inappropriate privilege levels, you'll
have more liability from one-off code for different platforms,
you run the risk of becoming tied to this network box
or that network box...

But if you have a ring of PIC32 and that's all it'll ever be,
it's fine. Just remember that UDP is the next move
up the stack, and the overhead isn't that much.

> Yes, there are complications in using raw Ethernet, such as requiring
> extra libraries on Windows or root privileges in Linux, to say nothing
> of having to battle network administrators!  But on a closed network,
> they are not hard to use.
>

Right.

<snip>
-- 
Les Cargill