On 01/20/2015 01:49 PM, Jan Stanstrup wrote: > Thank you for your answer. > I have spend some hours now to look into your suggestion but I have > not been able to find anything on how to set the server side buffer size. > I found something on tcp buffers that apparently can be changed > with /proc/sys/net/core/rmem_max /proc/sys/net/core/wmem_max but I > have no idea if that is relevant. I tried lowering that by a factor of > 10 but it made no difference. It even stalled faster it seems (could > be random. it doesn't stall at the same point every time). > > But to me it is a disk read issue. It cannot be right that you cannot > read a 4GB file on a BBB as was the case with my read test in my first > post. If that is the case I am very disappointed about the product. > > > > > On Monday, 19 January 2015 17:36:33 UTC+1, William Hermans wrote: > > you may want to look into making smaller ( much smaller ) file > buffers for the ftp / sftp servers you're using on the beaglebone > side. It's been a while, so I could tell you how specifically, but > it should be something you can look up with an internet search or two. > > On Sat, Jan 17, 2015 at 8:27 AM, <[email protected]> wrote: > > Hi. > > I am running ubuntu on BBB and I have an external HDD attached > over USB. > > I am having trouble reading large files on the external disks > over sftp and ftp. I tried different ftp clients but the > result is the same. After reading some of the file, typically > a few GB, the cpu uses 100% CPU and the speed drops to > practically nothing. > > I believe I have traced the problem to be an issue of reading > from the disk. If I make a large file: > dd if=/dev/zero of=file.txt count=1024 bs=4000000 > (which is not a problem apparently) > > and then read it using > time sh -c "dd if=file.txt bs=4k" > It will in a few minutes jump to use 100% CPU and in many > instances crash the ssh session with: > "The client has disconnected from the server. Reason: > Message Authentication Code did not verify (packet #222795). > Data integrity has been compromised. " > > > I found some discussion > (https://bbs.archlinux.org/viewtopic.php?id=112846&p=4 > <https://bbs.archlinux.org/viewtopic.php?id=112846&p=4>) of > what seems to be a similar issue where they suggest to > set /sys/kernel/mm/transparent_hugepage/defrag to madvise. But > I don't know how to try that on the BBB or if it is even relevant. > > Any idea about how to resolve this nasty problem? > -- > 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 > <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout.
also just so you know that was all found in the ftp sftp man pages.. -- 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.
