Basil Chupin wrote:
OK, I'll go checking what performance one can expect from ntfs-3g but if it worked in USB 2 conditions then why shouldn't it work in USB 3 conditions?
Thought you said it was SATA-3? Anyway, you might try mucking around in proc first you might try lowering /proc/sys/kernel/sched_latency_ns to 10,000,000 (enter it w/o the commas) .. What clock frequency are you running? Are you running tickless? Clock: HZ="$(zcat /proc/config.gz | grep "HZ_.*="|sed 's/CONFIG_HZ_// ; s/=y//')" echo $HZ What type of Pre-emption is your kernel running? zgrep PREEMPT /proc/config CONFIG_TREE_PREEMPT_RCU=y CONFIG_PREEMPT_RCU=y CONFIG_PREEMPT_NOTIFIERS=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_COUNT=y # CONFIG_DEBUG_PREEMPT is not set # CONFIG_PREEMPT_TRACER is not set ---- I don't know if the delayacct tools will help or not. But you could try limiting a 'dd' transfer to 1 core and use 'time' in bash with the TIMEFORMAT set to: "%2Rsec %2Uusr %2Ssys (%P%% cpu)" i.e. in bash: export TIMEFORMAT="%2Rsec %2Uusr %2Ssys (%P%% cpu)" time dd if=/dev/zero of=testfile bs=1M count=16 oflag=direct for testing other way, try: time dd of=/dev/null if=testfile bs=1M count=16 iflag=direct You might find different bs's will work better To limit it to 1 core, use time schedtool -a 3 -e dd ..... (-a 3 runs on cpu 3) (-a 0x3 runs on cpu's 1+2 -- hex is a bit mask decimal is integer) You might play with some of the other SCHED policies if your kernel has them (see schedtool -h) delay accounting can be gotten with 'getdelays' from the delayacct-utils That might give you a few things to try... ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org