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 <ivo.we...@anderson.ucla.edu> 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" <yyrk...@gmail.com> 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 <ivo...@gmail.com> 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 >>> serial-getty@ttyGS0.service.holdoff 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 beagleboard+unsubscr...@googlegroups.com. >>> 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 >> beagleboard+unsubscr...@googlegroups.com. >> 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 beagleboard+unsubscr...@googlegroups.com. > 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
