errr looks like I was wrong. Many, many dropped RX packets. I was looking at TX. So . . . hmmmm yeah I do not know what to say. This does not affect our end goal though. As the application I'm writing tracks payload sequence numbers, and if any are out of order for the payload, they just get dumped . . .
On Wed, Jun 10, 2015 at 12:01 PM, William Hermans <[email protected]> wrote: > heh keep forgetting to add information . . . Anyway, no dropped packets on > our BBB > > debian@xanbustester:~$ *sudo ifconfig can1* > can1 Link encap:UNSPEC HWaddr > 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 > UP RUNNING NOARP MTU:16 Metric:1 > RX packets:77659246 errors:0 dropped:77659246 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:10 > RX bytes:572774448 (546.2 MiB) TX bytes:0 (0.0 B) > Interrupt:71 > > debian@xanbustester:~$ *cat /etc/dogtag* > BeagleBoard.org Debian Image 2015-03-01 > debian@xanbustester:~$ > *uname -r3.14.39-ti-r61* > > > On Wed, Jun 10, 2015 at 11:56 AM, William Hermans <[email protected]> > wrote: > >> One more thing that comes to mind that could be effecting your dropped >> packets. I'm running cmd line only on our BBB's. Where you're running X ( >> LXDE ? ). >> >> It's been my experience with the BBB is that with X, it can be incredibly >> sluggish, depending on what you're doing. I have always guessed that this >> has to do with the BBB only having 512MB RAM, and X + running apps use up a >> lot of this. Anyway, it is possible that the combination of running X + >> whatever apps you're running is using up so much RAM that socketCAN + >> can-utils apps could be limited in how much RAM can be used for buffering. >> It is also possible that various things could be competing for CPU time. >> >> So, if you must run X, and I'm guessing you must because of the LCD cape. >> Then I would explore how to limit memory and CPU usage while running X. >> e.g. reduce running apps to a minimum, and google around for memory / CPU >> optimization and minimization techniques. >> >> On Wed, Jun 10, 2015 at 9:51 AM, William Hermans <[email protected]> >> wrote: >> >>> Anyway, got to run for a while and do some work. If you have any further >>> questions I can try and answer when I get back. >>> >>> On Wed, Jun 10, 2015 at 9:47 AM, William Hermans <[email protected]> >>> wrote: >>> >>>> Yeah I do not know why, but it does seem you're using different sources >>>> than I used. Here are some "exact steps" I used to create a virtual can >>>> development machine. Note: That the only real differences I did here was >>>> using vcan, instead of a physical canX device. And vcan in this case does >>>> not need bit timing as the log files created have timestamps. >>>> >>>> After many canplayer / candump sessions: >>>> >>>> william@debian-can:~/can-dev$ *sudo ifconfig vcan0* >>>> [sudo] password for william: >>>> vcan0 Link encap:UNSPEC HWaddr >>>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 >>>> UP RUNNING NOARP MTU:16 Metric:1 >>>> RX packets:567011 errors:0 dropped:0 overruns:0 frame:0 >>>> TX packets:567011 errors:0 dropped:0 overruns:0 carrier:0 >>>> collisions:0 txqueuelen:0 >>>> RX bytes:4161973 (3.9 MiB) TX bytes:4161973 (3.9 MiB) >>>> >>>> However, this is in a virtual machine using 4GB RAM, and 4 cores @ >>>> 2.5Ghz. The speed between this virtual machine, and the BBB *is* very >>>> noticeable. You may consider using the same sources to build can-utils, if >>>> you can. They may be newer / more up to date . . .but no guarantee it will >>>> make a difference. Also, you will have to make some changes obviously . . . >>>> >>>> EXACT STEPS: >>>> >>>> william@debian-can:~$ *sudo apt-get install build-essential autoconf >>>> libtool git* >>>> >>>> william@debian-can:~$ *mkdir dev* >>>> william@debian-can:~$ *cd dev* >>>> >>>> william@debian-can:~/dev$ *git clone >>>> https://github.com/linux-can/can-utils.git >>>> <https://github.com/linux-can/can-utils.git>* >>>> Cloning into 'can-utils'... >>>> remote: Counting objects: 1080, done. >>>> remote: Total 1080 (delta 0), reused 0 (delta 0), pack-reused 1080 >>>> Receiving objects: 100% (1080/1080), 294.56 KiB | 106 KiB/s, done. >>>> Resolving deltas: 100% (711/711), done. >>>> >>>> william@debian-can:~/dev$ *cd can-utils* >>>> >>>> william@debian-can:~/dev/can-utils$ *./autogen.sh* >>>> >>>> ---------- >>>> autoreconf >>>> ---------- >>>> >>>> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, >>>> `config/autoconf'. >>>> libtoolize: copying file `config/autoconf/ltmain.sh' >>>> libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `config/m4'. >>>> libtoolize: copying file `config/m4/libtool.m4' >>>> libtoolize: copying file `config/m4/ltoptions.m4' >>>> libtoolize: copying file `config/m4/ltsugar.m4' >>>> libtoolize: copying file `config/m4/ltversion.m4' >>>> libtoolize: copying file `config/m4/lt~obsolete.m4' >>>> libtoolize: Consider adding `-I config/m4' to ACLOCAL_AMFLAGS in >>>> Makefile.am. >>>> configure.ac:9: installing `config/autoconf/config.guess' >>>> configure.ac:9: installing `config/autoconf/config.sub' >>>> configure.ac:22: installing `config/autoconf/install-sh' >>>> configure.ac:22: installing `config/autoconf/missing' >>>> GNUmakefile.am: installing `config/autoconf/depcomp' >>>> >>>> -------- >>>> Finished >>>> -------- >>>> >>>> william@debian-can:~/dev/can-utils$ *./configure* >>>> >>>> william@debian-can:~/dev/can-utils$ *make* >>>> >>>> william@debian-can:~/dev/can-utils$ *sudo make install* >>>> >>>> william@debian-can:~$ *sudo modprobe vcan* >>>> william@debian-can:~$ *sudo ip link add vcan0 type vcan* >>>> william@debian-can:~$ *sudo ip link set vcan0 up* >>>> >>>> william@debian-can:~$ *sudo ifconfig vcan0* >>>> vcan0 Link encap:UNSPEC HWaddr >>>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 >>>> UP RUNNING NOARP MTU:16 Metric:1 >>>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0 >>>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 >>>> collisions:0 txqueuelen:0 >>>> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) >>>> >>>> >>>> william@debian-can:~$ *nc -l -p 5000 > >>>> /home/william/candump-may-14-2015.log* >>>> >>>> *IMPORTANT: command switch -l will log to a file on the device. -L is >>>> necessary to pipe stdout in logfile format to netcat.* >>>> >>>> debian@xanbustester:~$ *candump -L -n 20000 can1,0:0,#FFFFFFFF | nc >>>> 192.168.254.163 5000* >>>> >>>> After a few minutes use du to "test" if the incoming stream is >>>> finished. When it is finished, the file will stop growing. >>>> >>>> william@debian-can:~$ >>>> * du -h candump-may-14-2015.log972K candump-may-14-2015.log* >>>> >>>> william@debian-can:~$ *tail candump-may-14-2015.log* >>>> (1425243434.234750) can1 19F00302#C9000000000000FF >>>> (1425243434.249623) can1 19F0C503#E015031520AD0000 >>>> (1425243434.250165) can1 19F0C503#E17C010000100000 >>>> (1425243434.250783) can1 19F0C503#E200FFFFFFFFFC00 >>>> (1425243434.251412) can1 19F0C503#E300FFFFFFFFFFFF >>>> (1425243434.259494) can1 19F0C503#00150303B2610000 >>>> (1425243434.260026) can1 19F0C503#0110FFFFFF060000 >>>> (1425243434.260629) can1 19F0C503#0200FFFFFFFFFC00 >>>> (1425243434.261197) can1 19F0C503#0300FFFFFFFFFFFF >>>> (1425243434.269461) can1 19F0C502#C015030312610000 >>>> >>>> 1st terminal >>>> william@debian-can:~$ *canplayer vcan0=can1 < candump-may-14-2015.log* >>>> 2nd terminal >>>> william@debian-can:~$* candump vcan0* >>>> >>>> >>>> vcan0 19F0C503 [8] E0 15 03 15 20 AD 00 00 >>>> vcan0 19F0C503 [8] E1 7C 01 00 00 10 00 00 >>>> vcan0 19F0C503 [8] E2 00 FF FF FF FF FC 00 >>>> vcan0 19F0C503 [8] E3 00 FF FF FF FF FF FF >>>> vcan0 19F0C503 [8] 00 15 03 03 B2 61 00 00 >>>> vcan0 19F0C503 [8] 01 10 FF FF FF 06 00 00 >>>> vcan0 19F0C503 [8] 02 00 FF FF FF FF FC 00 >>>> vcan0 19F0C503 [8] 03 00 FF FF FF FF FF FF >>>> vcan0 19F0C502 [8] C0 15 03 03 12 61 00 00 >>>> >>>> On Wed, Jun 10, 2015 at 9:21 AM, superD <[email protected]> wrote: >>>> >>>>> ONE CONCERN HOWEVER... >>>>> >>>>> I notice a lot of packets getting dropped (see pic attached) on >>>>> can0...is that normal? >>>>> >>>>> -- >>>>> 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.
