Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[sam sokolik]

I have converted a matsuura using a mesa 7i80 (plus some smart serial 
daughter boards)  and it has been running flawlessly.  It really is 
amazing.  (I am using a motherboard with 2 nics...)  And this was one of 
peters first 7i80's.  When setting up the machine - it would be left on 
with linuxcnc up for weeks on end.  No realtime or hardware errors.

I never thought I would see linuxcnc over Ethernet...

sam

On 10/26/2016 8:15 AM, Peter C. Wallace wrote:
> On Tue, 25 Oct 2016, Chris Albertson wrote:
>
>> Date: Tue, 25 Oct 2016 22:12:14 -0700
>> From: Chris Albertson <albertson.ch...@gmail.com>
>> Reply-To: "Enhanced Machine Controller (EMC)"
>>  <emc-users@lists.sourceforge.net>
>> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
>> Subject: Re: [Emc-users] following along in my what if musings about ther new
>>  oramge pi 2e
>>
>> Does anyone here know of one verified case where a packet was dropped by a
>> switch?   This just does not happen
>>
>> Also, if you place a second Ethernet dongle on the Pi, the dongle and the
>> built-in port share a serial bus.  This is not really an issue but it you
>> don't like the idea of a multiplexed bus, you can't avoid it.
>>
>> Switches are not like routers they work at the Ethernet packet level and
>> only read the first few bits of each packet then cut it through fro input
>> FIFO to output FIFO. It is done in special hardware
> Small sample but I've run 4 of our Ethernets cards at 1 KHz through a switch
> for a week 24/7 without a single dropped packet
>
>
>> On Tue, Oct 25, 2016 at 8:39 AM, Przemek Klosowski <
>> przemek.klosow...@gmail.com> wrote:
>>
>>> On Mon, Oct 24, 2016 at 11:18 PM, Chris Albertson
>>> <albertson.ch...@gmail.com> wrote:
>>>> Let's say we have two computers and each is sending UDP packets to two
>>>> different Mesa cards.   I can't see how those packets would ever be on
>>>> the same physical cable, assuming a switched network.   Each computer
>>>> has its own cable to the switch.  The switch will read the packets and
>>>> place them on different outbound ports each with its own cable going
>>>> to the different Mesa boards.The UDP packets can't collide
>>> In theory, no. In practice, they all use the internal switch bus, and
>>> you are depending on the implementation details of a random network
>>> switch chip from a far-away country. Maybe they can switch fine on the
>>> first simultaneous arrival but can't sustain repeated collisions, or
>>> whatever. You just have to test it, and it's not quite easy-you'd have
>>> to set up four (or 2*N) independent Ethernet stations with very
>>> tightly coordinated on-wire packet streams.
>>>
>>> 
>>> --
>>> The Command Line: Reinvented for Modern Developers
>>> Did the resurgence of CLI tooling catch you by surprise?
>>> Reconnect with the command line and become more productive.
>>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>>> http://sdm.link/telerik
>>> ___
>>> Emc-users mailing list
>>> Emc-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>>
>>
>>
>> -- 
>>
>> Chris Albertson
>> Redondo Beach, California
>> --
>> The Command Line: Reinvented for Modern Developers
>> Did the resurgence of CLI tooling catch you by surprise?
>> Reconnect with the command line and become more productive.
>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>> http://sdm.link/telerik
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
> Peter Wallace
> Mesa Electronics
>
> (\__/)
> (='.'=) This is Bunny. Copy and paste bunny into your
> (")_(") signature to help him gain world domination.
>
>
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Peter C. Wallace]

On Tue, 25 Oct 2016, Chris Albertson wrote:

> Date: Tue, 25 Oct 2016 22:12:14 -0700
> From: Chris Albertson <albertson.ch...@gmail.com>
> Reply-To: "Enhanced Machine Controller (EMC)"
> <emc-users@lists.sourceforge.net>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Subject: Re: [Emc-users] following along in my what if musings about ther new
> oramge pi 2e
> 
> Does anyone here know of one verified case where a packet was dropped by a
> switch?   This just does not happen
>
> Also, if you place a second Ethernet dongle on the Pi, the dongle and the
> built-in port share a serial bus.  This is not really an issue but it you
> don't like the idea of a multiplexed bus, you can't avoid it.
>
> Switches are not like routers they work at the Ethernet packet level and
> only read the first few bits of each packet then cut it through fro input
> FIFO to output FIFO. It is done in special hardware

Small sample but I've run 4 of our Ethernets cards at 1 KHz through a switch 
for a week 24/7 without a single dropped packet


>
> On Tue, Oct 25, 2016 at 8:39 AM, Przemek Klosowski <
> przemek.klosow...@gmail.com> wrote:
>
>> On Mon, Oct 24, 2016 at 11:18 PM, Chris Albertson
>> <albertson.ch...@gmail.com> wrote:
>>> Let's say we have two computers and each is sending UDP packets to two
>>> different Mesa cards.   I can't see how those packets would ever be on
>>> the same physical cable, assuming a switched network.   Each computer
>>> has its own cable to the switch.  The switch will read the packets and
>>> place them on different outbound ports each with its own cable going
>>> to the different Mesa boards.The UDP packets can't collide
>>
>> In theory, no. In practice, they all use the internal switch bus, and
>> you are depending on the implementation details of a random network
>> switch chip from a far-away country. Maybe they can switch fine on the
>> first simultaneous arrival but can't sustain repeated collisions, or
>> whatever. You just have to test it, and it's not quite easy-you'd have
>> to set up four (or 2*N) independent Ethernet stations with very
>> tightly coordinated on-wire packet streams.
>>
>> 
>> --
>> The Command Line: Reinvented for Modern Developers
>> Did the resurgence of CLI tooling catch you by surprise?
>> Reconnect with the command line and become more productive.
>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>> http://sdm.link/telerik
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>
>
>
> -- 
>
> Chris Albertson
> Redondo Beach, California
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Mark]

On 10/26/2016 01:12 AM, Chris Albertson wrote:
> Does anyone here know of one verified case where a packet was dropped by a
> switch?   This just does not happen
>
> Also, if you place a second Ethernet dongle on the Pi, the dongle and the
> built-in port share a serial bus.  This is not really an issue but it you
> don't like the idea of a multiplexed bus, you can't avoid it.
>
> Switches are not like routers they work at the Ethernet packet level and
> only read the first few bits of each packet then cut it through fro input
> FIFO to output FIFO. It is done in special hardware

My documentation is still at the Naval Research Lab in Washington DC (we 
had to document all our issues and how we fixed them).  I'm sure if you 
sent a nice letter to the commander of the Lab, he might send you my 
documented problems with collisions on some of our switched networks.

It does happen.  And Layer Three switches route.

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Chris Albertson]

Real-Time is never defined as "now" you can't have that.   Even if I place
a pulse in a wire it takes time to come out the other end.   Yes, seriously
the speed of light delay through a cable is easy to measure with modest
equipment.   I have an application here at home were I measure and account
for the time it takes for a signal to move down 50 feet of coax cable.
There is always delay.

A better definition of real time is that events at happen on a schedule and
the system is designed so the schedule is not violated.  Or not violated in
a manner that would hurt the application.This is very different from
just being fast.   You can define a real-tine system as one that is always
"on time".  Being on time is not the same as being fast.  In fact one good
way to make sure you are on time is to make good use of buffers and queues.
   An example from real life is that you can be on time for an appointment
be getting to the address a few minute early then waiting at the curb until
a few seconds before the appointment time. In this case the curb is a kind
of queue where you wait.Reclocking is a common technique where data are
sent across a cable to be buffered at the far end then clocked out of the
buffer.

If you look at any real time operating system (RTOS) one of the primitive
functions is always a queue of some kind.  You can't get much done inside
of any complex system without queues.

Without reading the VHDL source code we don't know what is happening inside
the Mesa card but I strongly suspect the data in those UDP packets is
getting re-clocked and the exact time when a packet arrives hardly matters.
As long as they arrive at the curb BEFORE the appointed time so to speak we
are OK.   LinuxCNC seems to be designed around tasks that get executed on a
fixed periodic schedule.  In these kinds of systems as long as the data
"gets there" before the net execution cycle it does not mater when it
arrived.  Scanning the VHDL source I see many times where the system
waits for a"raising edge" before going on and doing something.  That
"waiting at the cub analogy might apply.  If so then minor jitter in
arrival time would not matter at all.  Need to read the source code to know
for sure.




A queue is not real time.  Real time is *now* not when the queue decides
> to send.  Losing packets in a critical environment is not a good thing.
> Let's suppose a limit is hit and the controller calls for a stop in one
> packet.  Oops, that packet got dropped.  And the machine bangs into the
> physical stops.  Not a good thing.  If you are going to use UDP for
> critical situations, you're best off using a direct connect, getting rid
> of the latency of the LAN and talking directly to the Mesa card.
>
> Mark
>
> 
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>



-- 

Chris Albertson
Redondo Beach, California
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Chris Albertson]

Does anyone here know of one verified case where a packet was dropped by a
switch?   This just does not happen

Also, if you place a second Ethernet dongle on the Pi, the dongle and the
built-in port share a serial bus.  This is not really an issue but it you
don't like the idea of a multiplexed bus, you can't avoid it.

Switches are not like routers they work at the Ethernet packet level and
only read the first few bits of each packet then cut it through fro input
FIFO to output FIFO. It is done in special hardware

On Tue, Oct 25, 2016 at 8:39 AM, Przemek Klosowski <
przemek.klosow...@gmail.com> wrote:

> On Mon, Oct 24, 2016 at 11:18 PM, Chris Albertson
>  wrote:
> > Let's say we have two computers and each is sending UDP packets to two
> > different Mesa cards.   I can't see how those packets would ever be on
> > the same physical cable, assuming a switched network.   Each computer
> > has its own cable to the switch.  The switch will read the packets and
> > place them on different outbound ports each with its own cable going
> > to the different Mesa boards.The UDP packets can't collide
>
> In theory, no. In practice, they all use the internal switch bus, and
> you are depending on the implementation details of a random network
> switch chip from a far-away country. Maybe they can switch fine on the
> first simultaneous arrival but can't sustain repeated collisions, or
> whatever. You just have to test it, and it's not quite easy-you'd have
> to set up four (or 2*N) independent Ethernet stations with very
> tightly coordinated on-wire packet streams.
>
> 
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>



-- 

Chris Albertson
Redondo Beach, California
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Nicklas Karlsson]

> ...
> Initiallly the hm2_eth driver provided no good recovery from dropped packets 
> (it would hang for 100s of MS and cause a cascade of linuxcnc errors) but the 
> errors occurred so seldomly that they were not a real problem (One test 
> system 
> had more than a year of uptime 24/7 at a 4 KHz update rate with no dropped 
> packets before it was updated to a linuxcnc version with packket loss 
> handling)

Hostmot is probably good but with ordinary computer I there is erros now and 
then. With recovery it seems to work well but I have not investigated how well.

> ... so occasional random packet loss causes 
> very litte harm)

One missed update of value in control loop should do very little harm.

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Peter C. Wallace]

On Tue, 25 Oct 2016, Stephen Dubovsky wrote:

> Date: Tue, 25 Oct 2016 14:40:46 -0400
> From: Stephen Dubovsky <smdubov...@gmail.com>
> Reply-To: "Enhanced Machine Controller (EMC)"
> <emc-users@lists.sourceforge.net>
> To: "Enhanced Machine Controller (EMC)" <emc-users@lists.sourceforge.net>
> Subject: Re: [Emc-users] following along in my what if musings about ther new
> oramge pi 2e
> 
> All switches do at least store and forward today.  Even the $20 cheap
> ones.  We use ethernet for real time control in some of our products.
> Faster loop time than LinuxCNC.  We use raw ethernet frames so that we
> don't even need the ethernet stack (no DNS/etc needed either.)  We also run
> web services on the same products (ARM based) that run the IP stack and
> coexist peacefully.
>
> Don't run ALL the computers in your office and the real-time network on the
> same switch.  real time stuff on one switch, rest of office on another, and
> one cable between the switches.  The real-time one will never see much
> traffic (except broadcasts.)  We do it.  It works.  We actualy have the
> opposite problem.  If we do even 1khz broadcast packets w/ real-time it
> drives office wifi *NUTS* and crashes.  FWIW, There is no way to do an
> encrypted wifi broadcast.  Everyone has different keys and this the access
> port has a ton of encryption to do (plus it never lets your phones go to
> sleep so the batteries die FAST.)  VLAN tagging solves the broadcast/wifi
> issue but thats no longer a $20 switch.
>
> Watchdog timeouts solve too many missing packet problems.  IEEE1588v2
> solves most jitter problems if timing is critical.  Embedded parts seem to
> all support it now.  We implemented it but have not needed to use the
> actual correction factors yet as our control style is fairly robust against
> jitter (but its there if we ever need it.)
>
> Stephen


Initiallly the hm2_eth driver provided no good recovery from dropped packets 
(it would hang for 100s of MS and cause a cascade of linuxcnc errors) but the 
errors occurred so seldomly that they were not a real problem (One test system 
had more than a year of uptime 24/7 at a 4 KHz update rate with no dropped 
packets before it was updated to a linuxcnc version with packket loss 
handling)

This is in a benign electrical environment and of course packets can be 
corrupted by severe electrical noise so packet loss handling has been added to 
deal with lost read and write packets. Currently not all possible data loss 
situations are handled but I expect that they will be dealt with eventually. 
This requires separate handling (handshaking basically) of messages that 
change remote or linuxCNC state but are not continually retransmitted
(by far  most information sent back and for simply copies state info from 
linuxcnc to the remote or vice versa so occasional random packet loss causes 
very litte harm)

Switches can be used with hm2_eth to allow (currently) up to 4 remote cards
The remote hm2 cards are 100BT so a Gig switch works well as a 
concentrator/distributer with minimal host time usage (the driver separates 
the read and read request functions so there is a gain from overlaped 
operations) Typically there are store/forward delays when you change speed
but it works quite well at 1 KHz and 4 cards


Peter Wallace
Mesa Electronics

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Nicklas Karlsson]

On Tue, 25 Oct 2016 12:33:57 -0600
Charles Buckley  wrote:

> I work in an environment at work where we do a lot of video broadcast over
> IP. That is all UDP multicast. Luckily, it is an environment where single
> dropped packet only corrupts that frame and section and is recovered the
> next base frame (ie, anywhere from 1 to 16 frames).
> 
> The reason we use UDP instead of other protocols is that UDP has no
> handshake. It is unilateral. Other protocols would require some sort of
> variation of a handshake to verify packet integrity. But, we also have an
> inherent safety check in that a lost packet only affects the individual
> frame. It does not propagate past that. In a RT situation with no check
> within the data itself, I would go with the most streamlined an uncluttered
> port and network path.
> 
> I was not part of the discussion, so I do not know how the 7i92H works or
> what sort of data you would send over the network. ...
> ... If you drop a frame, it is not
> the end of the world. ...

Certainly not, usually it is a control loop. It is a lot faster than video, 
maybe around 20 times and there is also feedback sent the other way but amount 
of data sent is a lot less.

Bandwidth and execution power required is relatively low although it must be 
available regularly at a frequency in the order of 1kHz. Not all systems are 
built so that this is available regularly all the time.

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Stephen Dubovsky]

All switches do at least store and forward today.  Even the $20 cheap
ones.  We use ethernet for real time control in some of our products.
Faster loop time than LinuxCNC.  We use raw ethernet frames so that we
don't even need the ethernet stack (no DNS/etc needed either.)  We also run
web services on the same products (ARM based) that run the IP stack and
coexist peacefully.

Don't run ALL the computers in your office and the real-time network on the
same switch.  real time stuff on one switch, rest of office on another, and
one cable between the switches.  The real-time one will never see much
traffic (except broadcasts.)  We do it.  It works.  We actualy have the
opposite problem.  If we do even 1khz broadcast packets w/ real-time it
drives office wifi *NUTS* and crashes.  FWIW, There is no way to do an
encrypted wifi broadcast.  Everyone has different keys and this the access
port has a ton of encryption to do (plus it never lets your phones go to
sleep so the batteries die FAST.)  VLAN tagging solves the broadcast/wifi
issue but thats no longer a $20 switch.

Watchdog timeouts solve too many missing packet problems.  IEEE1588v2
solves most jitter problems if timing is critical.  Embedded parts seem to
all support it now.  We implemented it but have not needed to use the
actual correction factors yet as our control style is fairly robust against
jitter (but its there if we ever need it.)

Stephen

On Tue, Oct 25, 2016 at 11:26 AM, Przemek Klosowski <
przemek.klosow...@gmail.com> wrote:

> On Mon, Oct 24, 2016 at 10:42 PM, Stephen Dubovsky 
> wrote:
> > Why would UDP need resends on a shared ethernet port?  There are no
> > collisions on a full-duplex port & switch (which is pretty much ALL of
> them
> > now-a-days.)  Passive hubs went the way of the dodo.
>
> Of course, but you are assuming an ideal active switch, and that may
> or may not be the case. All the switched ports are sitting on an
> internal bus, whose bandwidth has to be better than N/2*individual
> port bandwidth, because in principle, all port pairs could be active
> at the same time; on a cheap switch that 'bisection' bandwidth may not
> quite be there.  Also, in general, two originators could be trying to
> talk to the same receiving port and collide on it---switches of course
> must implement some form of  'store and forward' to be able to decide
> where to switch the packet to, but cheap switches do not have a deep
> store queue---maybe they can handle one or two packets but not more
> than that. So, in practice, the collisions and dropped packets are
> possible.
>
> 
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Charles Buckley]

I work in an environment at work where we do a lot of video broadcast over
IP. That is all UDP multicast. Luckily, it is an environment where single
dropped packet only corrupts that frame and section and is recovered the
next base frame (ie, anywhere from 1 to 16 frames).

The reason we use UDP instead of other protocols is that UDP has no
handshake. It is unilateral. Other protocols would require some sort of
variation of a handshake to verify packet integrity. But, we also have an
inherent safety check in that a lost packet only affects the individual
frame. It does not propagate past that. In a RT situation with no check
within the data itself, I would go with the most streamlined an uncluttered
port and network path.

I was not part of the discussion, so I do not know how the 7i92H works or
what sort of data you would send over the network. But, if this is a
protocol you are writing or coding around, it is possible to go the video
concept were every x number of packets is a reference frame, which could
sanity check the machine's path. So, for instance, if you were doing some
sort of trajectory plan for something going from X1 Y1 to X2 Y2 in CAD, the
g-code generated  could include reference points along that line, then
broadcast the entire path to the machine. If you drop a frame, it is not
the end of the world. You should not crash the machine in most instances.
(You could trash the part if you drop the boundary points).

Personally, I think it is probably a lot of worry about a side issue. We
broadcast gigs of video via UDP internally where I work every minute and
alarms sound if we drop 3 frames. We rarely see packet drops.

On Tue, Oct 25, 2016 at 10:54 AM, Mark  wrote:

> On 10/25/2016 12:16 PM, Nicklas Karlsson wrote:
> >> True dat.  But why take the chance and not use a direct connection with
> >> a cross-over cable?  Typical UDP traffic in a switched LAN is fairly
> >> fast but not necessarily totally reliable.  And over the years I've seen
> >> plenty of collisions on a switched network for both TCP and UDP.  The
> >> difference being TCP has error correction and will resend the packet.
> > The most usual in real time systems is packets are sent periodically and
> receiver know it will receive packets. If bandwidth should be used to the
> limit UDP is a better choice but with plenty of bandwidth left over TCP
> might be a better choice.
> >
> > Then I do real time systems usually I tolerate some lost packets.
> Usually the old value is not useful then new value is received but if there
> is enough time request resend would be good.
> >
> >
> > I guess the answer is it depend on available bandwidth and delay. You
> also need a mechanism to queue up old data no more needed.
> >
> > In real time systems a queue is usually not good because if there is not
> enough time it will start grow. If newest available data is used perfomance
> may degrade but software will continue to run.
> >
> >
> > Nicklas Karlsson
> Under UDP, the receiver will receive packets, however under the protocol
> it doesn't know if it receives "all" the packets.  UDP is kind of a send
> and forget protocol.  If you want to make sure that all packets are
> received, the only way to go is TCP.  UDP uses less bandwidth than TCP,
> though in reality the difference is quite small.
>
> A queue is not real time.  Real time is *now* not when the queue decides
> to send.  Losing packets in a critical environment is not a good thing.
> Let's suppose a limit is hit and the controller calls for a stop in one
> packet.  Oops, that packet got dropped.  And the machine bangs into the
> physical stops.  Not a good thing.  If you are going to use UDP for
> critical situations, you're best off using a direct connect, getting rid
> of the latency of the LAN and talking directly to the Mesa card.
>
> Mark
>
> 
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Mark]

On 10/25/2016 01:46 PM, Chris Albertson wrote:
> I hate to say it but, a lot of old wives tales here.  What is the
> latency added by a cut through switch?  It's the packet header length
> divided by the Ethernet bit rate.   If you are worried about this kind
> of stuff them you might as well start using shortened cables and wire
> because of speed or light delays of one foot per nanosecond.The
> switch latency translated into movement of the mill comes out to
> micrometers or nanometers.
>
> If you are worried about a switch, then you really need to worry about
> what is on the back side of the Ethernet port on an ARM SBC like the
> Pi.   The USB system and the Ethernet are sharing a serial bus.   So
> Ethernet and all the USB ports share bandwidth. Even  with a second
> ethernet port your UDP packets get queued and have to wait for buss
> access.   You r keyboard, mouse, web surfing packets and UDP data
> going to the mill are all on that same bus.  This s a much bigger deal
> and there is no way around it
>
> But you know what?   The amount of data being send is not very much
> and it works just fine.
>
> Next question yo have two network ports, now the software has to look
> up which port to send each packet, there is now a routing problem the
> software networking stack has to deal with.  Does this added lookup
> add more time and latency?  Of course, typically routing is about 10x
> slower then switching.

Your machine, your money.  Do what you wish.  What looks good in theory 
doesn't always hold true in practice.  Been there, done that for almost 
the last 30 years as a system and network admin.  For the price of a 
dual NIC card and a crossover cable vs a relatively expensive switch 
which minimizes but doesn't eliminate the collision problem as I and 
others have pointed out, I know which direction I'd go.  Packet length 
and bandwidth do not eliminate collisions.  They happen on a network.  
If you are going to use UDP for a critical function, then you need to 
find a way to practically eliminate the chance of that happening.  The 
reliability of depending on a switched network versus a direct 
connection from the computer's NIC to the device isn't even close.

You are already going to have the issue of what's on the back side of 
the ethernet port on the ARM SBC whether you use a switch or a direct 
connection. Now you've added another layer between the computer and the 
device.  Ever have a switch hiccup while nothing else in the network 
does?  Kinda tuff for a crossover patch cord to hiccup unless it's damaged.

Correct - not very much data is being passed around if it's only UDP.  
Toss in TCP to the mix, along with other stuff, and you can end up with 
a relatively busy network.  You do realize layer three switches route 
too, right?  Guaranteed slower to route that traffic than the traffic 
being done on the NIC.  Lookup table on a dual NIC is usually smaller 
than the one on the layer three switch.

Is the ethernet controlled by the RTOS for machine control?  If so, the 
mouse, keyboard and any other extraneous interrupts should be handled 
under that.

There's a reason for some of those "old wive's tales."  In this case, 
they are true.

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Chris Albertson]

I hate to say it but, a lot of old wives tales here.  What is the
latency added by a cut through switch?  It's the packet header length
divided by the Ethernet bit rate.   If you are worried about this kind
of stuff them you might as well start using shortened cables and wire
because of speed or light delays of one foot per nanosecond.The
switch latency translated into movement of the mill comes out to
micrometers or nanometers.

If you are worried about a switch, then you really need to worry about
what is on the back side of the Ethernet port on an ARM SBC like the
Pi.   The USB system and the Ethernet are sharing a serial bus.   So
Ethernet and all the USB ports share bandwidth. Even  with a second
ethernet port your UDP packets get queued and have to wait for buss
access.   You r keyboard, mouse, web surfing packets and UDP data
going to the mill are all on that same bus.  This s a much bigger deal
and there is no way around it

But you know what?   The amount of data being send is not very much
and it works just fine.

Next question yo have two network ports, now the software has to look
up which port to send each packet, there is now a routing problem the
software networking stack has to deal with.  Does this added lookup
add more time and latency?  Of course, typically routing is about 10x
slower then switching.



On Tue, Oct 25, 2016 at 9:54 AM, Mark  wrote:
> On 10/25/2016 12:16 PM, Nicklas Karlsson wrote:
>>> True dat.  But why take the chance and not use a direct connection with
>>> a cross-over cable?  Typical UDP traffic in a switched LAN is fairly
>>> fast but not necessarily totally reliable.  And over the years I've seen
>>> plenty of collisions on a switched network for both TCP and UDP.  The
>>> difference being TCP has error correction and will resend the packet.
>> The most usual in real time systems is packets are sent periodically and 
>> receiver know it will receive packets. If bandwidth should be used to the 
>> limit UDP is a better choice but with plenty of bandwidth left over TCP 
>> might be a better choice.
>>
>> Then I do real time systems usually I tolerate some lost packets. Usually 
>> the old value is not useful then new value is received but if there is 
>> enough time request resend would be good.
>>
>>
>> I guess the answer is it depend on available bandwidth and delay. You also 
>> need a mechanism to queue up old data no more needed.
>>
>> In real time systems a queue is usually not good because if there is not 
>> enough time it will start grow. If newest available data is used perfomance 
>> may degrade but software will continue to run.
>>
>>
>> Nicklas Karlsson
> Under UDP, the receiver will receive packets, however under the protocol
> it doesn't know if it receives "all" the packets.  UDP is kind of a send
> and forget protocol.  If you want to make sure that all packets are
> received, the only way to go is TCP.  UDP uses less bandwidth than TCP,
> though in reality the difference is quite small.
>
> A queue is not real time.  Real time is *now* not when the queue decides
> to send.  Losing packets in a critical environment is not a good thing.
> Let's suppose a limit is hit and the controller calls for a stop in one
> packet.  Oops, that packet got dropped.  And the machine bangs into the
> physical stops.  Not a good thing.  If you are going to use UDP for
> critical situations, you're best off using a direct connect, getting rid
> of the latency of the LAN and talking directly to the Mesa card.
>
> Mark
>
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 

Chris Albertson
Redondo Beach, California

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Nicklas Karlsson]

> ...
> A queue is not real time.  Real time is *now* not when the queue decides 
> to send.  Losing packets in a critical environment is not a good thing.  

Real time is usually within a certain time span, for example buffer half full 
so it must be emptied before full.

> Let's suppose a limit is hit and the controller calls for a stop in one 
> packet.  Oops, that packet got dropped.  And the machine bangs into the 
> physical stops.  Not a good thing. ...

In a critical system stop happen if packet is not received. Usually I send data 
periodically, have a watchdog and some missed packets are allowed.


Nicklas Karlsson

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Mark]

Because collisions do happen on modern switches, and using UDP with no 
error correction in the protocol would cause those packets involved in a 
collision to be dropped. Switches are another layer of complexity, 
latency and expense when a dual port NIC is the cheapest and most 
reliable way to go if you need to really be sure a UDP packet makes it 
to it's intended destination with no problems, and has it's own 
bandwidth not being chugged down by other network communications and are 
using a dedicated line from the NIC to the device.

Mark

On 10/25/2016 12:56 PM, Chris Albertson wrote:
> My guess is that people are reading 20 year old information, using two
> ports and
> sure enough it works just fine.  So they claim "I used two ports and it 
> worked"
> so the next person does the same and no one thinks about "why".
>
> On Mon, Oct 24, 2016 at 7:42 PM, Stephen Dubovsky  
> wrote:
>> Why would UDP need resends on a shared ethernet port?  There are no
>> collisions on a full-duplex port & switch (which is pretty much ALL of them
>> now-a-days.)  Passive hubs went the way of the dodo.


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Mark]

On 10/25/2016 12:52 PM, Chris Albertson wrote:
> Are you still certain you need two Ethernet ports?   I can't see why
> you need two on a modern switched network.
>
> On Mon, Oct 24, 2016 at 7:05 PM, Mark Johnsen  wrote:
>> On Mon, Oct 24, 2016 at 6:52 PM, Gene Heskett  wrote:
>>
>>> 1. someone said the 7i92H needs its own dedicated ethernet port,
>>> presumably because udp patckets are not subject to any attempts at error
>>> correction resends if other traffic walks on a udp packet.
>>>

Because you really don't want to run critical stuff through a switch 
using UDP.  Much better, safer, and more assured of the packet arriving 
a the destination by using a direct connect with a crossover cable 
between the NIC and the Mesa card.  No worries about network latencies, 
collisions and other problems between the computer and the device in 
question.


Mark


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Chris Albertson]

My guess is that people are reading 20 year old information, using two
ports and
sure enough it works just fine.  So they claim "I used two ports and it worked"
so the next person does the same and no one thinks about "why".

On Mon, Oct 24, 2016 at 7:42 PM, Stephen Dubovsky  wrote:
> Why would UDP need resends on a shared ethernet port?  There are no
> collisions on a full-duplex port & switch (which is pretty much ALL of them
> now-a-days.)  Passive hubs went the way of the dodo.
>
>
> On Mon, Oct 24, 2016 at 10:22 PM, Gene Heskett  wrote:
>
>> On Monday 24 October 2016 22:05:47 Mark Johnsen wrote:
>>
>> > On Mon, Oct 24, 2016 at 6:52 PM, Gene Heskett 
>> wrote:
>> > > Greetings guys; I hope everyone has arrived back home without
>> > > incidents involving bent sheet metal or worse.
>> > >
>> > > 1. someone said the 7i92H needs its own dedicated ethernet port,
>> > > presumably because udp patckets are not subject to any attempts at
>> > > error correction resends if other traffic walks on a udp packet.
>> > >
>> > > So that means I'd need to find an Orange Pi with 2 ethernet sockets
>> > > so two independant paths/addresses can be setup.
>> > >
>> > > None of these low power use cards have that, none that I've found
>> > > have a 2nd port.  Is this a case of just waiting till it does
>> > > happen?  Space considerations for the rj45 socket says it not going
>> > > to be at all likely.
>> > >
>> > > Comments anybody?
>> >
>> > You'd be right on the dual ethernet port option.  Most of the smaller
>> > boards only have one ethernet port, so you have 2 options (that I can
>> > think of).
>> >
>> > One is a USB to Ethernet adapter because those boards have a few USB
>> > ports, or add a USB hub to add more USB ports.
>> >
>> > Here's a USB to ethernet I found for $10:
>> > https://www.amazon.com/gp/product/B00ET4KHJ2/
>> >
>> > In theory that should work.
>>
>> I'll give it a shot. And get the orange pi on order in the morning.
>> Might need a shoehorn before I'm done...
>> >
>> > The other option might be wifi if the board has it built in.   But, if
>> > I recall, you had your systems hardwired, so I'd go for the USB to
>> > ethernet adapter.
>> >
>> > I did see some chinaco boards w/ dual ethernet, but too many unknowns
>> > to try to get those working.
>> >
>> > Mark
>> > --
>> > The Command Line: Reinvented for Modern Developers
>> > Did the resurgence of CLI tooling catch you by surprise?
>> > Reconnect with the command line and become more productive.
>> > Learn the new .NET and ASP.NET CLI. Get your free copy!
>> > http://sdm.link/telerik
>> > ___
>> > Emc-users mailing list
>> > Emc-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/emc-users
>>
>>
>> Cheers, Gene Heskett
>> --
>> "There are four boxes to be used in defense of liberty:
>>  soap, ballot, jury, and ammo. Please use in that order."
>> -Ed Howdershelt (Author)
>> Genes Web page 
>>
>> 
>> --
>> The Command Line: Reinvented for Modern Developers
>> Did the resurgence of CLI tooling catch you by surprise?
>> Reconnect with the command line and become more productive.
>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>> http://sdm.link/telerik
>> ___
>> Emc-users mailing list
>> Emc-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-users
>>
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 

Chris Albertson
Redondo Beach, California

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Mark]

On 10/25/2016 12:16 PM, Nicklas Karlsson wrote:
>> True dat.  But why take the chance and not use a direct connection with
>> a cross-over cable?  Typical UDP traffic in a switched LAN is fairly
>> fast but not necessarily totally reliable.  And over the years I've seen
>> plenty of collisions on a switched network for both TCP and UDP.  The
>> difference being TCP has error correction and will resend the packet.
> The most usual in real time systems is packets are sent periodically and 
> receiver know it will receive packets. If bandwidth should be used to the 
> limit UDP is a better choice but with plenty of bandwidth left over TCP might 
> be a better choice.
>
> Then I do real time systems usually I tolerate some lost packets. Usually the 
> old value is not useful then new value is received but if there is enough 
> time request resend would be good.
>
>
> I guess the answer is it depend on available bandwidth and delay. You also 
> need a mechanism to queue up old data no more needed.
>
> In real time systems a queue is usually not good because if there is not 
> enough time it will start grow. If newest available data is used perfomance 
> may degrade but software will continue to run.
>
>
> Nicklas Karlsson
Under UDP, the receiver will receive packets, however under the protocol 
it doesn't know if it receives "all" the packets.  UDP is kind of a send 
and forget protocol.  If you want to make sure that all packets are 
received, the only way to go is TCP.  UDP uses less bandwidth than TCP, 
though in reality the difference is quite small.

A queue is not real time.  Real time is *now* not when the queue decides 
to send.  Losing packets in a critical environment is not a good thing.  
Let's suppose a limit is hit and the controller calls for a stop in one 
packet.  Oops, that packet got dropped.  And the machine bangs into the 
physical stops.  Not a good thing.  If you are going to use UDP for 
critical situations, you're best off using a direct connect, getting rid 
of the latency of the LAN and talking directly to the Mesa card.

Mark

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Chris Albertson]

Are you still certain you need two Ethernet ports?   I can't see why
you need two on a modern switched network.

On Mon, Oct 24, 2016 at 7:05 PM, Mark Johnsen  wrote:
> On Mon, Oct 24, 2016 at 6:52 PM, Gene Heskett  wrote:
>
>> 1. someone said the 7i92H needs its own dedicated ethernet port,
>> presumably because udp patckets are not subject to any attempts at error
>> correction resends if other traffic walks on a udp packet.
>>

-- 

Chris Albertson
Redondo Beach, California

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Nicklas Karlsson]

> True dat.  But why take the chance and not use a direct connection with 
> a cross-over cable?  Typical UDP traffic in a switched LAN is fairly 
> fast but not necessarily totally reliable.  And over the years I've seen 
> plenty of collisions on a switched network for both TCP and UDP.  The 
> difference being TCP has error correction and will resend the packet. 

The most usual in real time systems is packets are sent periodically and 
receiver know it will receive packets. If bandwidth should be used to the limit 
UDP is a better choice but with plenty of bandwidth left over TCP might be a 
better choice.

Then I do real time systems usually I tolerate some lost packets. Usually the 
old value is not useful then new value is received but if there is enough time 
request resend would be good.


I guess the answer is it depend on available bandwidth and delay. You also need 
a mechanism to queue up old data no more needed.

In real time systems a queue is usually not good because if there is not enough 
time it will start grow. If newest available data is used perfomance may 
degrade but software will continue to run.


Nicklas Karlsson

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Mark]

On 10/25/2016 11:26 AM, Przemek Klosowski wrote:
> On Mon, Oct 24, 2016 at 10:42 PM, Stephen Dubovsky  
> wrote:
>> Why would UDP need resends on a shared ethernet port?  There are no
>> collisions on a full-duplex port & switch (which is pretty much ALL of them
>> now-a-days.)  Passive hubs went the way of the dodo.
> Of course, but you are assuming an ideal active switch, and that may
> or may not be the case. All the switched ports are sitting on an
> internal bus, whose bandwidth has to be better than N/2*individual
> port bandwidth, because in principle, all port pairs could be active
> at the same time; on a cheap switch that 'bisection' bandwidth may not
> quite be there.  Also, in general, two originators could be trying to
> talk to the same receiving port and collide on it---switches of course
> must implement some form of  'store and forward' to be able to decide
> where to switch the packet to, but cheap switches do not have a deep
> store queue---maybe they can handle one or two packets but not more
> than that. So, in practice, the collisions and dropped packets are
> possible.


Yup.  Exactly.  Happens even on expensive Big Iron Cisco switches as 
well, though not as prevalent as on the cheaper switches.  Though even 
the cheap switches are much better than the old fashioned hubs.

Mark

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Przemek Klosowski]

On Mon, Oct 24, 2016 at 11:18 PM, Chris Albertson
 wrote:
> Let's say we have two computers and each is sending UDP packets to two
> different Mesa cards.   I can't see how those packets would ever be on
> the same physical cable, assuming a switched network.   Each computer
> has its own cable to the switch.  The switch will read the packets and
> place them on different outbound ports each with its own cable going
> to the different Mesa boards.The UDP packets can't collide

In theory, no. In practice, they all use the internal switch bus, and
you are depending on the implementation details of a random network
switch chip from a far-away country. Maybe they can switch fine on the
first simultaneous arrival but can't sustain repeated collisions, or
whatever. You just have to test it, and it's not quite easy-you'd have
to set up four (or 2*N) independent Ethernet stations with very
tightly coordinated on-wire packet streams.

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Przemek Klosowski]

On Mon, Oct 24, 2016 at 10:42 PM, Stephen Dubovsky  wrote:
> Why would UDP need resends on a shared ethernet port?  There are no
> collisions on a full-duplex port & switch (which is pretty much ALL of them
> now-a-days.)  Passive hubs went the way of the dodo.

Of course, but you are assuming an ideal active switch, and that may
or may not be the case. All the switched ports are sitting on an
internal bus, whose bandwidth has to be better than N/2*individual
port bandwidth, because in principle, all port pairs could be active
at the same time; on a cheap switch that 'bisection' bandwidth may not
quite be there.  Also, in general, two originators could be trying to
talk to the same receiving port and collide on it---switches of course
must implement some form of  'store and forward' to be able to decide
where to switch the packet to, but cheap switches do not have a deep
store queue---maybe they can handle one or two packets but not more
than that. So, in practice, the collisions and dropped packets are
possible.

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Mark]

On 10/25/2016 10:18 AM, Stephen Dubovsky wrote:
> Im fully aware UDP doesn't resend.  But there are no collisions on modern
> ethernet LANs.  No more reason a UDP packet would be corrupted going
> through a (shared) switch as a direct connection.

True dat.  But why take the chance and not use a direct connection with 
a cross-over cable?  Typical UDP traffic in a switched LAN is fairly 
fast but not necessarily totally reliable.  And over the years I've seen 
plenty of collisions on a switched network for both TCP and UDP.  The 
difference being TCP has error correction and will resend the packet.  
The direct connection between the NIC and the Mesa port is a lot better 
and doesn't have the overhead latency of running through the switch.  
For real time signaling you'd want the least amount of latency and any 
possibility of collisions averted. No reason to run it through a switch 
unless you are planning on running multiple machines from a single 
computer, which seems unlikely.  If you need an additional network 
connection for file transfer and the like, add a NIC or use wireless.  
Leave the dedicated machine controller port and connection to machine 
control and put nothing else in between.  A dropped packet from a 
machine control command is a lot worse than a dropped packet from normal 
machine to machine communication.

Mark

Unix System and Network admin for almost 30 years

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Stephen Dubovsky]

Im fully aware UDP doesn't resend.  But there are no collisions on modern
ethernet LANs.  No more reason a UDP packet would be corrupted going
through a (shared) switch as a direct connection.

On Tue, Oct 25, 2016 at 8:23 AM, Mark  wrote:

> On 10/24/2016 10:42 PM, Stephen Dubovsky wrote:
> > Why would UDP need resends on a shared ethernet port?  There are no
> > collisions on a full-duplex port & switch (which is pretty much ALL of
> them
> > now-a-days.)  Passive hubs went the way of the dodo.
>
> UDP won't, and can't do resends.  Unlike TCP there is no error
> correction present in UDP.  When using the UDP protocol it assumes that
> everything goes through perfectly.  Which allows it a lot less overhead
> than TCP.
>
> Mark
>
> 
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Mark]

On 10/24/2016 10:42 PM, Stephen Dubovsky wrote:
> Why would UDP need resends on a shared ethernet port?  There are no
> collisions on a full-duplex port & switch (which is pretty much ALL of them
> now-a-days.)  Passive hubs went the way of the dodo.

UDP won't, and can't do resends.  Unlike TCP there is no error 
correction present in UDP.  When using the UDP protocol it assumes that 
everything goes through perfectly.  Which allows it a lot less overhead 
than TCP.

Mark

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Chris Albertson]

The 7i90hd might work for you.   It uses SPI, not Ethernet.  SPI is
about as fast as Ethernet

I am trying to figure out how a UDP packet might get "walked on" in a
modern Ethernet network.   Back in the days of un-switched networks
that used either 10BaseT hubs (hubs not switches) or that used coaxial
cable then yes I can see that happening.   But a switched network is
different EVERY line is isolated from all the other by the switch.
The switch has memory and queues the packets.

Let's say we have two computers and each is sending UDP packets to two
different Mesa cards.   I can't see how those packets would ever be on
the same physical cable, assuming a switched network.   Each computer
has its own cable to the switch.  The switch will read the packets and
place them on different outbound ports each with its own cable going
to the different Mesa boards.The UDP packets can't collide






On Mon, Oct 24, 2016 at 6:52 PM, Gene Heskett  wrote:
> Greetings guys; I hope everyone has arrived back home without incidents
> involving bent sheet metal or worse.
>
> 1. someone said the 7i92H needs its own dedicated ethernet port,
> presumably because udp patckets are not subject to any attempts at error
> correction resends if other traffic walks on a udp packet.
>
> So that means I'd need to find an Orange Pi with 2 ethernet sockets so
> two independant paths/addresses can be setup.
>
> None of these low power use cards have that, none that I've found have a
> 2nd port.  Is this a case of just waiting till it does happen?  Space
> considerations for the rj45 socket says it not going to be at all
> likely.
>
> Comments anybody?
>
> 2. In playing with this phony vfd today after I got everything bolted
> down again, I find the lack of docs a good sized problem. My test code
> loop to exercise it has a direct reversal in it at one point and I'd
> like to decelerate it to about 25 hertz in 5 to 7.5 seconds from
> whatever speed its turning, switching on the dc brakes at that point to
> bring it to a smooth halt.  Then accelerate smoothly in the other
> direction. It acts like that is what its doing for a straight stop from
> either direction. and the booklet says in can go directly from one to
> the other. However, in trying to speed up the changes, if I just switch
> directions, it gets down to about 25 hz, then jumps off the table about
> an inch, and is then running the other direction at the set speed even
> if the set speed is 120 hz!  No accelleration softening ramp at all.
> This controller has about 8 registers that can be set for various speeds
> where they are in effect, but zero discussion about what they effect in
> this little booklet. So how to go about optimizing those settings?
>
> If anyone has any wisdom to share, I'd sure appreciate it.
>
> Thanks everybody.
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
>
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 

Chris Albertson
Redondo Beach, California

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Stephen Dubovsky]

Why would UDP need resends on a shared ethernet port?  There are no
collisions on a full-duplex port & switch (which is pretty much ALL of them
now-a-days.)  Passive hubs went the way of the dodo.


On Mon, Oct 24, 2016 at 10:22 PM, Gene Heskett  wrote:

> On Monday 24 October 2016 22:05:47 Mark Johnsen wrote:
>
> > On Mon, Oct 24, 2016 at 6:52 PM, Gene Heskett 
> wrote:
> > > Greetings guys; I hope everyone has arrived back home without
> > > incidents involving bent sheet metal or worse.
> > >
> > > 1. someone said the 7i92H needs its own dedicated ethernet port,
> > > presumably because udp patckets are not subject to any attempts at
> > > error correction resends if other traffic walks on a udp packet.
> > >
> > > So that means I'd need to find an Orange Pi with 2 ethernet sockets
> > > so two independant paths/addresses can be setup.
> > >
> > > None of these low power use cards have that, none that I've found
> > > have a 2nd port.  Is this a case of just waiting till it does
> > > happen?  Space considerations for the rj45 socket says it not going
> > > to be at all likely.
> > >
> > > Comments anybody?
> >
> > You'd be right on the dual ethernet port option.  Most of the smaller
> > boards only have one ethernet port, so you have 2 options (that I can
> > think of).
> >
> > One is a USB to Ethernet adapter because those boards have a few USB
> > ports, or add a USB hub to add more USB ports.
> >
> > Here's a USB to ethernet I found for $10:
> > https://www.amazon.com/gp/product/B00ET4KHJ2/
> >
> > In theory that should work.
>
> I'll give it a shot. And get the orange pi on order in the morning.
> Might need a shoehorn before I'm done...
> >
> > The other option might be wifi if the board has it built in.   But, if
> > I recall, you had your systems hardwired, so I'd go for the USB to
> > ethernet adapter.
> >
> > I did see some chinaco boards w/ dual ethernet, but too many unknowns
> > to try to get those working.
> >
> > Mark
> > --
> > The Command Line: Reinvented for Modern Developers
> > Did the resurgence of CLI tooling catch you by surprise?
> > Reconnect with the command line and become more productive.
> > Learn the new .NET and ASP.NET CLI. Get your free copy!
> > http://sdm.link/telerik
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
>
> 
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Danny Miller]

It absolutely requires its own ethernet port, no router either. That's 
because it's a realtime device and having to arbitrate would only make 
unpredictable latency/jitter.

Like others are saying, the link for accessing your LAN probably won't 
even suffer if you use wifi and a USB2.0.

I just used a Edimax Wireless N150 Wifi Nano.   $10.  People use 'em all 
the time for Raspberry Pi.  Immediately worked on Linux.

No speed complaints.

Danny


On 10/24/2016 8:52 PM, Gene Heskett wrote:
> Greetings guys; I hope everyone has arrived back home without incidents
> involving bent sheet metal or worse.
>
> 1. someone said the 7i92H needs its own dedicated ethernet port,
> presumably because udp patckets are not subject to any attempts at error
> correction resends if other traffic walks on a udp packet.
>
> So that means I'd need to find an Orange Pi with 2 ethernet sockets so
> two independant paths/addresses can be setup.
>
> None of these low power use cards have that, none that I've found have a
> 2nd port.  Is this a case of just waiting till it does happen?  Space
> considerations for the rj45 socket says it not going to be at all
> likely.
>
> Comments anybody?
>
> 2. In playing with this phony vfd today after I got everything bolted
> down again, I find the lack of docs a good sized problem. My test code
> loop to exercise it has a direct reversal in it at one point and I'd
> like to decelerate it to about 25 hertz in 5 to 7.5 seconds from
> whatever speed its turning, switching on the dc brakes at that point to
> bring it to a smooth halt.  Then accelerate smoothly in the other
> direction. It acts like that is what its doing for a straight stop from
> either direction. and the booklet says in can go directly from one to
> the other. However, in trying to speed up the changes, if I just switch
> directions, it gets down to about 25 hz, then jumps off the table about
> an inch, and is then running the other direction at the set speed even
> if the set speed is 120 hz!  No accelleration softening ramp at all.
> This controller has about 8 registers that can be set for various speeds
> where they are in effect, but zero discussion about what they effect in
> this little booklet. So how to go about optimizing those settings?
>
> If anyone has any wisdom to share, I'd sure appreciate it.
>
> Thanks everybody.
>
> Cheers, Gene Heskett


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] following along in my what if musings about ther new oramge pi 2e

[Gene Heskett]

On Monday 24 October 2016 22:05:47 Mark Johnsen wrote:

> On Mon, Oct 24, 2016 at 6:52 PM, Gene Heskett  
wrote:
> > Greetings guys; I hope everyone has arrived back home without
> > incidents involving bent sheet metal or worse.
> >
> > 1. someone said the 7i92H needs its own dedicated ethernet port,
> > presumably because udp patckets are not subject to any attempts at
> > error correction resends if other traffic walks on a udp packet.
> >
> > So that means I'd need to find an Orange Pi with 2 ethernet sockets
> > so two independant paths/addresses can be setup.
> >
> > None of these low power use cards have that, none that I've found
> > have a 2nd port.  Is this a case of just waiting till it does
> > happen?  Space considerations for the rj45 socket says it not going
> > to be at all likely.
> >
> > Comments anybody?
>
> You'd be right on the dual ethernet port option.  Most of the smaller
> boards only have one ethernet port, so you have 2 options (that I can
> think of).
>
> One is a USB to Ethernet adapter because those boards have a few USB
> ports, or add a USB hub to add more USB ports.
>
> Here's a USB to ethernet I found for $10:
> https://www.amazon.com/gp/product/B00ET4KHJ2/
>
> In theory that should work.

I'll give it a shot. And get the orange pi on order in the morning.  
Might need a shoehorn before I'm done...  
>
> The other option might be wifi if the board has it built in.   But, if
> I recall, you had your systems hardwired, so I'd go for the USB to
> ethernet adapter.
>
> I did see some chinaco boards w/ dual ethernet, but too many unknowns
> to try to get those working.
>
> Mark
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users