This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL1837MOD: WL1837MOD

Part Number: WL1837MOD
Other Parts Discussed in Thread: WL18XXCOM82SDMMC

Hi support

I give you some information about our application/products.
In our application there are two devices (an hand held terminal and a receiver) that communicate in wifi between each other. In particular the 2 devices exchange some very important and critical safety traffic (UDP) and other non safety traffic (UDP, TCP/IP, HTTP, ...): monitoring data, browser, streaming video, ...
The WiFi safety traffic (each device transmits a 200 byte packet every 10 ms in UDP) must be transmitted with the highest priority, must travel as quickly as possible and must be regular and deterministic; the other non safety traffic is not critical, and must be transmitted with lower priority.
We have 2 products:
- a product already in mass production with Atheros AR9462, ath9k driver, ad hoc mode, linux 3.14.28, imx6 solo, 5 GHz frequencies. 
- a new product which is currently in development: linux 4.1, imx6 dual lite, ad hoc mode or WiFi Direct mode, USB or SDIO host interface. For this product we are evaluating WL18xx.
The features that we need on both products are:
- Spectral scan, or automatic channel selection; offline search of the "best" channel. The idea is to search the best (the less congested) channel at setup/configuration time and then run the ad hoc (or WiFi Direct) modality forcing the use of the previously detected best channel.
- QoS run time monitoring functions. Our customer needs to dynamically know how the wifi communication is currently working on 3 levels: good, mean, bad. The driver should dynamically provide some information about the WiFi link quality.
- EDCA (Enhanced Distributed Channel Access). The safety packets must be transmitted with higher priority than the other WiFi traffic.

I have done some tests in a configuration in which there is only one transmitter that tranmsits 200 bytes UDP messages every 10 ms, in infrastructure mode. The test conditions are almost ideal: channel 44 which is free, the CPUs are 80% idle, the two devices are very close.

In general the WiFi communication is enough regular, but sometimes there some delays in the receiver of about 20/30 ms.

I attach 2 oscillosope pictures in which:

  • the green signal is the application that regularly transmits every 10 ms
  • the yellow signal is the irq (WL18xxCOM82SDMMC pin IRQ_3V3) in the transmitter
  • the  light blue signal is the irq (WL18xxCOM82SDMMC pin IRQ_3V3) in the receiver

My question are:

1. are these delays normal ? note that there is no other WiFi traffic on this channel.

2. Is there a way to eliminate these delays ?

3. is EDCA enabled by default ?

thanks

Marco Raiteri

  • Hello,

    Are you running your system with power save enabled?
    If you do than large delays are normal if the station is asleep between beacons.

    Try turning power_save off and see if you see a difference:

    iw wlan0 set power_save off

    BR,
    Eyal
  • Hello

    On my system power save is enabled by default.

    I am running a configuration with an AP and a client with kernel 4.1.39 on imx6

    On the client side I succeed in turning power_save off as you suggested.

    On the AP side when I try to turn power_save off I get this error:

    command failed: Operation not supported (-95)

    Do you have any idea ?

    Is there another way to disable power save ?

    thanks

    Marco

  • It is ok. This command is relevant for station side only.
    an AP is always active.

    Best Regards,
    Eyal
  • Hello
    I have turned power_save off on the station but the system behaviour hasn't changed.
    Do you have any other idea ?
    thanks
    Best Regards,
    Marco
  • UDP traffic is highly dependent on the system (IP stack, Networking etc.) so I am not sure you are seeing a real issue here.
    IT may be that some other process/thread running in the system is causing this delay due to some other system activity.

    If you have an air sniffer capture (wireshark) capturing wlan UDP traffic in the air you can verify if the UDP packets are being delayed over the air or not.

    BR,
    Eyal
  • Hi Eyal,
    we'd like to understand if your idea, that the delay is due to some other system activity, is right.
    This is the output of top on the transmitter:

    root@exorNS01kit:~# top

    top - 17:12:22 up 51 min, 1 user, load average: 0.00, 0.00, 0.32
    Tasks: 114 total, 1 running, 113 sleeping, 0 stopped, 0 zombie
    %Cpu(s): 0.4 us, 4.2 sy, 0.0 ni, 95.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
    KiB Mem : 507596 total, 356588 free, 82024 used, 68984 buff/cache
    KiB Swap: 0 total, 0 free, 0 used. 413400 avail Mem

    PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
    931 root 20 0 28104 1392 1276 S 7.1 0.3 0:03.83 safety_simulato
    926 root 20 0 0 0 0 S 2.3 0.0 0:02.49 kworker/u2:0
    936 root 20 0 3020 1936 1560 R 2.3 0.4 0:00.79 top
    382 root -52 0 0 0 0 S 1.9 0.0 0:46.25 irq/126-s-wl18x
    4 root -2 0 0 0 0 S 1.3 0.0 0:31.15 ktimersoftd/0
    78 root -51 0 0 0 0 S 1.3 0.0 0:34.89 irq/226-mmc0
    3 root 20 0 0 0 0 S 0.3 0.0 0:05.53 ksoftirqd/0
    8 root -2 0 0 0 0 S 0.3 0.0 0:09.07 rcu_preempt
    12 root -2 0 0 0 0 S 0.3 0.0 0:10.60 rcuc/0
    63 root -51 0 0 0 0 S 0.3 0.0 0:08.12 irq/201-20b4000
    380 root -51 0 0 0 0 S 0.3 0.0 0:12.68 irq/126-wl18xx
    910 root 20 0 0 0 0 S 0.3 0.0 0:00.25 kworker/0:2
    917 root 20 0 5404 3760 3332 S 0.3 0.7 0:00.74 sshd
    1 root 20 0 1724 1092 1028 S 0.0 0.2 0:00.76 init
    2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
    6 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
    9 root -2 0 0 0 0 S 0.0 0.0 0:00.00 rcu_sched
    10 root -2 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
    11 root -2 0 0 0 0 S 0.0 0.0 0:00.00 rcub/0
    13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kclksetdelayd
    14 root rt 0 0 0 0 S 0.0 0.0 0:00.00 posixcputmr/0
    15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kcmosdelayd
    16 root rt 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
    17 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 khelper
    18 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kdevtmpfs
    19 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kswork
    20 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 perf
    21 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 writeback
    22 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 crypto
    23 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 bioset
    24 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kblockd
    25 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 ata_sff
    26 root -51 0 0 0 0 S 0.0 0.0 0:00.00 irq/231-21f8000
    28 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 cfg80211
    29 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 rpciod

    Process with PID 931 is my test application; it has normal priority but we don't see a
    meaningful jitter in the transmission at this level with the oscilloscope.
    Process with PID 382 (irq/126-s-wl18x) and PID 380 (irq/126-wl18xx) seem related to the driver and have high priority.
    Is it possible to identify other processes related to the TI driver ?
    If the answer is yes would it be possible to raise their priority ?
    Is it available any documentation about the structure of the TI driver (threads, processes, ...) ?
    Thanks
    BR
    Marco
  • The TI driver is part of the Linux mac80211 layer. Our driver is only a small part of it (lower level which is hardware dependent).
    I am not aware of documentation for the linux mac80211 layer to the level you are asking for.

    Best Regards,
    Eyal