D-Link Forums
D-Link VPN Router => DSR-250N => Topic started by: roadapathy on October 22, 2018, 05:52:50 PM
-
I noticed the 250N is very slow- the interface, that is. I have been compiling Kernels from Kernel.org as an amatuer for about 20 years. I found some settings in the config that I believe should be changed and may be slowing the entire router down:
I don't ever enable this and it seems odd to have it enabled on a production machine.
CONFIG_DEBUG_KERNEL=y
My experience with KPROBES are that it increases overhead in a big way. I would never enable these on any system.
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_CLK=y
"Kprobes allows you to trap at almost any kernel address and
execute a callback function. register_kprobe() establishes
a probepoint and specifies the callback. Kprobes is useful
for kernel debugging, non-intrusive instrumentation and testing.
If in doubt, say "N"."
Oprofile for sure slows the system down and a lot. These seem really wrong for a production system!
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_MARKERS=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
"OProfile is a profiling system capable of profiling the
whole system, include the kernel, kernel modules, libraries,
and applications.
If unsure, say N."
I don't think you want this on a production
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
These all hit performance and I'd question whether some were needed.
CONFIG_STACKTRACE=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_TRACING_SUPPORT=y
"
This option causes the kernel to create a /proc/pid/stack for
every process, showing its current stack trace.
It is also used by various kernel debugging features that require
stack trace generation.
Symbol: STACKTRACE [=n]" *** DEFAULT HERE IS N
You can do a
cat /sys/block/sda/queue/scheduler
and
echo "deadline" /sys/block/sda/queue/scheduler
to find the best IO scheduler for the specific memory you're hosting on the device. I found this information here:
https://blog.codeship.com/linux-io-scheduler-tuning/
Although I have played around with IO schedulers, I haven't pinned down which work the best for SSD vs HDD (yet).
You could use hdparm to test the disk IO
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_FREEZER=y
I hope this helps. My router is great but it does seem slower than it shout be- especially restarting and the web menu.
-
Thanks for posting.
How do you implement this? Would help to let some know how you do this actually.
-
I have no idea because this has to be compiled and it's an older Kernel. I was hoping somebody at Dlink could produce it and then give us a firmware update.
-
I presume that probably won't happen. Unless it's a official update to new stuff, D-Link doesn't release special updates.
-
If I could figure it out, I'd do it because the router is dog slow and it shouldn't be.
-
The source is all provided and if we could add our own Kernel, this router could run like a top. I just don't know if making a mistake bricks this unit or if it has a backup bios. That is the real issue. If that's the case, I won't even try it. Instead, I'd have down Dlink to push it through. It's in their best interest. This model still sells on Amazon.
-
D-Link posts GPL for there supported products here:
tsd.dlink.com.tw (http://tsd.dlink.com.tw)
They leave any customization that users want up to users to compile there own stuff...
Also it's possible the follow on Revs may have these already.