Oh, and for the record, NFS is actually faster than iSCSI on this hardware as well ;)
On Sat, Mar 12, 2016 at 5:32 PM, William Hermans <[email protected]> wrote: > @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.
