Dynalink DL-WRX36 Askey RT5010W IPQ8072A technical discussion

I had a similar issue and I posted it here in this forum. In my case, although I was not able to reach the router/AP, I was still able to access the internet via Wifi. It should be noted that I had the dynalink unit configured as an access point alone.
I finally resolved it by resetting it and reapplying the saved configuration archive. I think you may need to press and hold the reset button and plug in the power cable while still holding the reset button.

I hope this helps. If not, I believe serial console is the next step.

.b292 didn't gave me any errors, but when testing iperf3 speed in a location separated by 2 walls from router, it always gives less speed than the correct calibrated BDF used in snapshot. Even if .b292 uses higher or the same Tx power.
Near the router there was no difference I could see. (~1.5Gbits)
Far from the router, behind 2 walls, .b292=~700 to 800Mbits, snapshot default BDF=~850 to 980Mbits.

So I'm back to the default BDF with the correct calibration.
Will wait for a Tx power fix.

One thing I notice is that WRX36 has dual-band antennas and ax3600 has single band antennas. Don't know if there's any difference when setting/reading Tx power becuse of this.

1 Like

Interesting conversation with AI, its seems that fio benchmark is limited by schedulit governor

is this good benchmark ?

root@OpenWrt:~# fio --name=random-read-test --filename=/dev/sda --rw=randread --bs=4k --ioengine=libaio --iodepth=32 --numjobs=1 --size=1G --runtime=60s --ti
me_based --output-format=normal
random-read-test: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=32
fio-3.34
Starting 1 thread
Jobs: 1 (f=1): [r(1)][100.0%][r=18.2MiB/s][r=4647 IOPS][eta 00m:00s]
random-read-test: (groupid=0, jobs=1): err= 0: pid=4945: Tue May  9 20:11:40 2023
  read: IOPS=4530, BW=17.7MiB/s (18.6MB/s)(1062MiB/60001msec)
    slat (usec): min=5, max=107440, avg=208.87, stdev=696.68
    clat (usec): min=8, max=634734, avg=6842.87, stdev=9707.13
     lat (usec): min=224, max=634976, avg=7051.74, stdev=9855.55
    clat percentiles (msec):
     |  1.00th=[    6],  5.00th=[    7], 10.00th=[    7], 20.00th=[    7],
     | 30.00th=[    7], 40.00th=[    7], 50.00th=[    7], 60.00th=[    7],
     | 70.00th=[    7], 80.00th=[    7], 90.00th=[    8], 95.00th=[    8],
     | 99.00th=[    8], 99.50th=[   10], 99.90th=[   13], 99.95th=[   14],
     | 99.99th=[  634]
   bw (  KiB/s): min=  432, max=20672, per=100.00%, avg=18140.39, stdev=2578.98, samples=119
   iops        : min=  108, max= 5168, avg=4535.08, stdev=644.77, samples=119
  lat (usec)   : 10=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
  lat (msec)   : 2=0.01%, 4=0.01%, 10=99.58%, 20=0.37%, 100=0.01%
  lat (msec)   : 250=0.01%, 500=0.01%, 750=0.02%
  cpu          : usr=5.23%, sys=15.01%, ctx=271369, majf=0, minf=64
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=100.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.1%, 64=0.0%, >=64=0.0%
     issued rwts: total=271853,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=32

Run status group 0 (all jobs):
   READ: bw=17.7MiB/s (18.6MB/s), 17.7MiB/s-17.7MiB/s (18.6MB/s-18.6MB/s), io=1062MiB (1114MB), run=60001-60001msec

Disk stats (read/write):
  sda: ios=270660/2, merge=0/0, ticks=51335/0, in_queue=51336, util=99.48%

The benchmark results you provided indicate the performance of the random read test performed on your SSD. Here are some key metrics from the output:

  • IOPS: 4530 (Input/Output Operations Per Second)
  • Bandwidth: 17.7 MiB/s (18.6 MB/s)
  • Latency: The latency distribution is displayed, including various percentiles (e.g., 1.00th, 5.00th, 10.00th, 20.00th, etc.), indicating the response time in microseconds (usec) and milliseconds (msec).
  • CPU usage: The CPU utilization during the benchmark, showing the percentage of time spent in user mode (usr), system mode (sys), and the number of context switches (ctx).

Overall, the benchmark suggests that the SSD achieved an average read bandwidth of 17.7 MiB/s (18.6 MB/s) and a significant number of IOPS. However, it's important to note that benchmark results can vary depending on various factors such as hardware, firmware, and system configuration.

To assess the performance of your SSD, you can compare the benchmark results with the specifications provided by the manufacturer or conduct additional benchmarks to evaluate different aspects of its performance, such as write performance and sequential read/write speeds.

Remember that benchmark results serve as an indicator, and real-world performance can vary depending on the specific workload and usage scenarios.

what was the cpu usage?

According to the benchmark results you provided, the CPU usage during the random read test was as follows:

  • User CPU usage (usr): 5.23%
  • System CPU usage (sys): 15.01%

These values represent the percentage of time spent in user mode and system mode, respectively, during the benchmark. In this case, the user mode CPU usage accounted for 5.23% of the total CPU time, while the system mode CPU usage accounted for 15.01%. The remaining CPU time was likely used by other processes and system tasks.

Please note that CPU usage can vary depending on various factors, including the specific workload, system configuration, and available CPU resources. These values provide an indication of the CPU utilization during the benchmark but may not represent the overall CPU usage of the system.

Question: is it actually normal that Wi-Fi uploading towards the router is significantly slower than downloading, even when sitting just next to the router. ( upload 650mbit, download around 900)
I am not entirely sure but if I remember correctly the speed was quite symmetrical at some point in the past.

One suggestion is to use htop to see if the cpu bottleneck is causing a limitation.

Already checked (cpu has still plenty of space) and the discrepancy between up- and download speed is increasing with distance…

While I get around 800mbit down 7 meters away the upload is around 350mbit.

Yes, there are several factors that can have effect in this. eg download usually is reading and upload is writing. (assuming "towards the router" means that you are transfering files on lan and not on wan side) reading is usually faster. mobile devices use one stream while network cards may use two streams, also mobile devices tend to have a weaker transmit signal than your router. you can try a different channel and see if that makes a difference.


They're the same for me.

The CPU has AES SHA1 SHA2 acceleration. Are the features applied automatically or do I have to build OpenWRT from source?

1 Like

Can someone post a picture of a serial cable for this router? I am not sure whether it is straight USB-> 4pin JST like this, or does it have to have something more in it.

You probably have to install: libopenssl-devcrypto

See:

My solution

3 Likes

I have the same cable.

Replying to myself.
I've reproduced the problem with ARP not getting through (more accurately broadcasts not getting through).
When that happens, setting proxy_arp_pvlan on the wifi interfaces does fix the ARP issue, but that is only a partial fix as multicast and broadcast traffic still isn't correctly received, breaking many other things (mDNS, printing, etc).
I've currently investigating if the patchset at https://lore.kernel.org/linux-wireless/20210720213147.90042-1-jouni@codeaurora.org/T/ makes any difference.

2 Likes

That set is already applied and only for ath11k but people are also experiencing this issue on mediatek platforms so it seems to be a general issue.

3 Likes

A post was split to a new topic: Issues installing Samba4 on snapshot r22594

Thanks @Crect.
Are the patches in a branch?
github.com:openwrt/openwrt.git master does not seem to have the patch applied as of r22894-d53fe5d9ce (~yesterday).

@robimarko

can you help here, by applying perhaps the patches @Crect quoted?. FWIW i'm hitting what seems this exact issue (ARP requests are not forwarded to Wifi Client after some time) in my home setup (a rPI Zero W that gets unreachable but only from other wifi clients after a while)

Thanks in advance

All the best,

António

Those 4addr patches have been backported for ages and are part of 6.1 so that is why you dont see them localy.

thanks for your fast reply && sorry for the noise. something else still going on then. (will try to debug this one of the next weekends)

Thanks for your patience and keep the great work!