Yeah, I was going to say that there would be a big difference between a connections that has two way comms going over it versus just blasting data in one direction.
On Sat, Mar 12, 2016 at 3:46 PM, Wally Bkg <[email protected]> wrote: > In a "streaming" or servo (or tracking) application latency matters a > lot, bandwidth is usually pre-limited by the sampling rate. Its usually > better to drop or distort a frame than stop and wait for a re-transmission. > > In a soft real-time system a few errors once in a while usually doesn't > create too bad of a glitch, but when using TCP the retry for error > correction can often make the glitch worse. Its all application > dependent, but on a lightly loaded subnet I agree there is usually no > significant difference between UDP and TCP within UDP's limitation (maximum > packet size can be a function of the subnet its on), but for things like > the 6-DOF motion controller I was talking about, using UDP and just > dropping any bad data and "catching up" next sample works far better than > prolonging the glitch to wait for the "correct" data which is by now too > "stale" to care about. > > I've setup systems both ways using which ever was most appropriate > Basically if a decent amount of data buffering is needed in the system, or > you need to cross subnets TCP is almost always the way to go, but if quick > response to changes is required UDP usually works better for soft-real time > applications. > > > On Saturday, March 12, 2016 at 4:08:54 PM UTC-6, 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 . . . >> >> On Sat, Mar 12, 2016 at 12:57 PM, Wally Bkg <[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]. >>> 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. > -- 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.
