You are not logged in.
How to set the lower mac to NO MAC from Python?
I understand that the default setup is DCF.
Offline
This is not possible with the reference code. The NoMAC and DCF applications are separate top-level software projects for the CPU Low MicroBlaze core. The SDK compiles each application to a separate .elf file and there is no way to re-load the .elf via Ethernet.
Many of the behaviors of the DCF can be customized from Python. What DCF features do you want to disable via Python?
Offline
I want to decrease the overhead as much as possible to increase the overall throughput.
I already tried:
node.set_low_to_high_rx_filter(mac_header='ALL', fcs='ALL')
node.set_dcf_param('rts_thresh', 65535)
node.set_dcf_param('short_retry_limit', 10)
node.set_dcf_param('long_retry_limit', 10)
Interestingly, when I do the following, the payload length is still set to 1500 even though I enabled JUMBO FRAME at the NIC driver.
USE_JUMBO_ETH_FRAMES = True
When I run, I get:
"WARNING: Adjusting LTG Payload length from 5000 to 1500 (max)."
Last edited by starlord (2017-Nov-25 09:22:21)
Offline
I checked your suggestions from other posts and I did connect two JUMBO FRAME enabled PCs via a switch and tried to ping. The ping works.
Offline
1500 bytes is the largest supported payload in the current (v1.7.2) 802.11 Tx/Rx PHY cores and MAC code. This is the maximum payload specified by the 802.11 a/n spec.
Offline
Oh Okay. Thank for clearing that up.
Any suggestions on how to further improve the throughput?
P.S. I am already using "node.set_phy_samp_rate(40)"
Offline
If you've disabled any kind of medium access by using NOMAC and you've set the sampling rate to 40MSPS, there aren't any more easy dials to turn to dramatically increase throughput. Any other changes will be big projects (e.g. supporting A-MSDU and A-MPDU aggregation to further reduce overhead, adding MIMO support, etc).
If you don't care about standards compliance (which sounds like the case given that you are using NOMAC and a 2x clocked PHY running at 40MSPS), then you could work on modifying the design to support large payloads without formally implementing the very complicated aggregation schemes in the modern 802.11 standards. This thread might have some useful discussion, but note that any code present in that thread was based on a much older version of the design from 2014.
Offline