@Wally, So yeah, I do not think data in one direction over netcat would be much of a problem for this hardware.
*Host PC :* william@eee-pc:~$ nc -l -p 5000 > /home/william/test.log *Beaglebone:* william@beaglebone:~$ dd if=/dev/zero bs=1M count=1000 | nc 192.168.254.162 5000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB) copied, 95.5816 s, *11.0 MB/s* NFS is still faster, but not by a whole lot. On Sat, Mar 12, 2016 at 4:10 PM, William Hermans <[email protected]> wrote: > 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.
