So my memory is not always that great with stuff like this ( that i hardly use )
Host side you would do somethign like "sudo iperf -s" - this starts a listening server - default port. client side ( BBB ) you'd use "sudo iperf -C 192.168.7.x" Once that test is done, you swap server to the BBB, and client to the host, etc . . . Anyway not sure sudo is necessary, i think it was for me but . . .memory fails. Just watch the video or find some decent text instructions to make sure what im saying here is correct . . .as I barely ever use this tool. On Tue, Dec 9, 2014 at 3:48 AM, William Hermans <[email protected]> wrote: > I used iperf, which is a package in debian > > $ apt-cache search iperf > > You can find realy simplified instructions on how to use it on youtube. > Windows instructions but the commands should be exactly the same ( minus > the *.exe bit ). > > On Tue, Dec 9, 2014 at 3:43 AM, ivo welch <[email protected]> > wrote: > >> >> Nope. It's linux on metal. An i3 HP Notebook. >> >> I need to figure out how to benchmark throughput on usb0 network speed. >> On Dec 9, 2014 5:56 PM, "William Hermans" <[email protected]> wrote: >> >>> Never really tested g_serial speeds myself, but I can tell you that >>> g_ether is better than 100Mbit. Somewhere around 170Mbit and even better >>> for some people. So long as you use a real Linux host. Anyhow, my point is >>> the hardware is fast enough. >>> >>> >>> I will say is that *if* your Linux desktop is actually in a Windows >>> virtual machine, your performance issues have nothing to do with the BBB + >>> software, and everything thing to do with the virtual machine + Windows. >>> >>> On Mon, Dec 8, 2014 at 11:36 PM, ivo welch <[email protected]> wrote: >>> >>>> >>>> I am looking for more information on running "Serial over USB" from a >>>> linux desktop host to the BBB device. Some information on the web seems >>>> out of date, at least on debian 7.7. other information is very helpful. I >>>> am summarizing here some of what I have learned myself first: >>>> >>>> a sending desktop linux can send information to the BBB over >>>> /dev/ttyACM0. >>>> a recipient BBB linux can receive information on /dev/ttyGS0 . >>>> this is part of the g_multi kernel module and thus works out of >>>> the box on debian 7.7. >>>> >>>> this can be tested as >>>> >>>> bbb# cat /dev/ttyGS0 >>>> >>>> desktop# echo "hello" > /dev/ttyACM0 >>>> >>>> and the bbb should now echo "hello". the comm is buffered, although I >>>> am not sure on which side (desktop or bbb). this is obvious from looking >>>> at the desktop immediately after a fresh boot: >>>> >>>> desktop# cat /dev/ttyACM0 >>>> >>>> which will still return the log in information from the boot on the >>>> first use. after the buffer is full, the device blocks and waits. >>>> >>>> information about the port settings can be found (and potentially set, >>>> though I don't think anything is needed) with >>>> >>>> stty -F /dev/ttyGS0 -a >>>> >>>> however, I believe that some of this are just "pretend you are rs232" >>>> wrong. this is because I just wrote a little perl program that sends >>>> 1Mbyte into the device and then closes. this takes about 1.5 seconds. >>>> This would suggest a raw speed of about 7 Mbaud, a little bit faster than >>>> the 9.6 Kbaud that stty tells me. I am guessing that the "serial port over >>>> USB" uses the USB 1.1 "full-speed" protocol that caps out at 12 Mbaud. I >>>> believe hi-speed 480 Mbaud connections require block operations. >>>> >>>> the serial comm speed is interesting to compare to the usb mass storage >>>> speed. A dd from the desktop host to the mounted BBB mass-storage device >>>> partition over USB produces 21 Mbaud. so, the serial connection is about >>>> 1/3 of what the BBB is capable of over hi-speed USB mass storage. the eMMC >>>> limits out at about 70Mbaud local, which is itself about three times the >>>> speed of the mass storage driver over the USB 2.0 connection. (and remember >>>> that USB 2.0 is itself limited to 480Mbaud. I also tried to measure >>>> the speed over the usb0 ethernet with dd and netcat [nc] to see how close >>>> this could get, but I failed.) >>>> >>>> hope this helps. >>>> >>>> * one question: I have lost some information sent forth and back, which >>>> I believe is due to the bbb issuing (from /var/log/syslog) a >>>> [email protected] time over, scheduling restart >>>> is it possible to force ttyGS0 to always be available, and never to >>>> want to restart? >>>> >>>> * I may write a different driver that sits on top of the mass storage >>>> driver and communicates over a small shared storage area. it's a crazy >>>> idea, but it could be faster than serial-over-usb if I know that I will be >>>> dealing in blocks of 512 bytes and relatively easy to debug and >>>> synchronize. >>>> >>>> >>>> -- >>>> 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 a topic in the >>> Google Groups "BeagleBoard" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/beagleboard/pjJjlqXLLKM/unsubscribe. >>> To unsubscribe from this group and all its topics, 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.
