Just to conclude on this. It seems to be a kernel issue. With the more official debian release it doesn't die. It still uses 100% and is quite slow for reading:
time sh -c "dd if=file.txt bs=4k" 1000000+0 records in 1000000+0 records out 4096000000 bytes (4.1 GB) copied, 1105.02 s, 3.7 MB/s Writing on the other hand is just fine: if=/dev/zero of=file.txt count=1024 bs=4000000 1024+0 records in 1024+0 records out 4096000000 bytes (4.1 GB) copied, 177.923 s, 23.0 MB/s On Tuesday, 20 January 2015 23:38:04 UTC+1, don wrote: > > 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) 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. >>> >> >> -- > 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] <javascript:>. > 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.
