On 03/12/2016 05:08 PM, William Hermans wrote:
Hey Walley,
I don't think TCP/IP would be all that much slower than UDP when
transmitting data over the wire on this board. The Beaglebone's
ethernet is incredibly fast for 10/100 fast ethernet. What's more, yes
by comparrison TCP connection can have more latency than UDP
connections but latency does not usually matter. What matters most of
the time is bandwidth. So the connection speed could be the same, it
may just arrive a few milliseconds slower.
But, I'll have to devise some sort of test using netcat to see what's
really up with netcat. That should not be too hard to do. I can say
that NFS comes really close to the interfaced maximum theoretical
speed. But NFS uses neither UDP, or TCP, and if memory serves it
operates on layer2 on some level . . .
You might want to look at the NFS docs a bit more. NFS has used UDP
forever, TCP was only added in version 4 if memory serves, and it had to
be specifically enabled.
Mike
On Sat, Mar 12, 2016 at 12:57 PM, Wally Bkg <[email protected]
<mailto:[email protected]>> wrote:
TCP/IP connection will guarantee no data loss at the cost of
possibly greatly increased latency. I've done such in the past
using UDP which, if client and server are on the same subnet, is
about as deterministic as standard Ethernet gets, but is generally
blocked by default on most firewalls. If the data leaves your
subnet you will need error correction and likely just end up
reinventing TCP badly.
I've done pseudo-simultaneous sampling systems (all the A/D
channels are sampled at the maximum rate once per tick of a slower
timer that sets the system sampling rate) using this method with
the server sending each multi-channel sample to a different system
via UDP for further processing at every tick of the sample
clock. It works very well when the systems are on the same subnet
and the data rate is not too high compared to the network overhead.
If your data rate is low enough the "file system" based solutions
might be easier to code and troubleshoot, but you have extra
overhead from the network transport and the file system layer to
contend with. IMHO the easiest to code, troubleshoot, and
document architecture is the way to go as long as all requirements
can be met.
The UDP client/server solution can be pretty fast -- I've
controlled a 6-DOF motion base (Stewart Platform) with a 100Hz
servo loop where one system calculated the desired motion profile
from user input while another did the matrix calculations to set
the actuator link lengths for the desired motion, and a third
processed the visual scene presented to the user, all talking via
UDP on an isolated network (only these three systems were connected).
On Friday, March 11, 2016 at 11:22:18 AM UTC-6, Dhanesh Kothari
wrote:
Thank you @Wally and @William.
My goal is to send continuous data stream from my system and
my beaglebone should be receiving data serially and than
process the data as per my algorithm without any data loss.
We are using sshfs to mount a directory on beaglebone to our
system.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google
Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google
Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
