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 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.
