Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[roadapathy]

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.

[FurryNutz]

Thanks for posting.
How do you implement this? Would help to let some know how you do this actually.

[roadapathy]

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.

[FurryNutz]

I presume that probably won't happen. Unless it's a official update to new stuff, D-Link doesn't release special updates.

[roadapathy]

If I could figure it out, I'd do it because the router is dog slow and it shouldn't be.

[roadapathy]

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.

[FurryNutz]

D-Link posts GPL for there supported products here:
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.