Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
New Ventana 4.8.1.0.9239
#1
http://files.star-os.com/

This is for the Ventana only.  I have focused on it in order to maximize my efforts.  There is a saying about chasing more than 1 rabbit and you will not catch either of them.

I have imported some patches for improved stability.  I see 60 mbps to 70 mbps.  Please use this version moving forward.  I have run iperf tests in bidirectional mode (simultaneous tx and rx) using 2 cards in the following configurations:

1. 2 cards at 2 GHz to 2 War1B clients.  Channel 2 and Channel 10.  Each test gives 60 to 70 mbps for a total of 120 to 140 mbps.
2. 2 cards at 2 GHz to 3 War1B clients.  Channel 6.  Each test varies but the total is between 40 and 60 mbps
3. 2 cards, 1 at 2 GHz and 1 at 5 GHz to War1B clients.  Channel 2 and Channel 132.  The 2 GHz test gives 60 to 70 mbps and the 5 GHz test gives 40 to 50 mbps for a total of 80 to 110 mbps;

I have run each test for in excess of 24 hours and, in my environment at least, they have been solid.  Note that all the clients were NOT using this version but instead a mix of older releases.  This shows that the Clients are not an issue with the stall problem and that the War1B is an excellent Client.

I have re-purposed the ping watchdog so that it functions as a watchdog that activates rather than a reboot.  NOTE: This means that if you were using the ping watchdog to reboot it will now not do that, and instead will do a radio activate.  This seems like a better solution than a full reboot.

One issue which is annoying but not a showstopper, is that the ssh session will sometimes quit or stall.


.png   2018-05-09_21-47-01-Ventana.png (Size: 231.5 KB / Downloads: 5)

.png   2018-05-10_10-41-11-War1B-AP-9230.png (Size: 95.6 KB / Downloads: 6)

.png   2018-05-11_22-26-19-2GHz-5GHz-Test.png (Size: 228.58 KB / Downloads: 5)
Reply
#2
(05-13-2018, 11:39 PM)lonnie Wrote: http://files.star-os.com/

This is for the Ventana only.  I have focused on it in order to maximize my efforts.  There is a saying about chasing more than 1 rabbit and you will not catch either of them.

I have imported some patches for improved stability.  I see 60 mbps to 70 mbps.  Please use this version moving forward.  I have run iperf tests in bidirectional mode (simultaneous tx and rx) using 2 cards in the following configurations:

1. 2 cards at 2 GHz to 2 War1B clients.  Channel 2 and Channel 10.  Each test gives 60 to 70 mbps for a total of 120 to 140 mbps.
2. 2 cards at 2 GHz to 3 War1B clients.  Channel 6.  Each test varies but the total is between 40 and 60 mbps
3. 2 cards, 1 at 2 GHz and 1 at 5 GHz to War1B clients.  Channel 2 and Channel 132.  The 2 GHz test gives 60 to 70 mbps and the 5 GHz test gives 40 to 50 mbps for a total of 80 to 110 mbps;

I have run each test for in excess of 24 hours and, in my environment at least, they have been solid.  Note that all the clients were NOT using this version but instead a mix of older releases.  This shows that the Clients are not an issue with the stall problem and that the War1B is an excellent Client.

I have re-purposed the ping watchdog so that it functions as a watchdog that activates rather than a reboot.  NOTE: This means that if you were using the ping watchdog to reboot it will now not do that, and instead will do a radio activate.  This seems like a better solution than a full reboot.

One issue which is annoying but not a showstopper, is that the ssh session will sometimes quit or stall.



Lonnie, 
I wish this resolved the issues but i loaded new firmware changed setting on other AP so clients roamed over to ventana all good then ran a throughput test on one of the clients and boom reset all clients (13) roamed back to war1b AP- logs below. 

Feb  8 23:56:52 hostapd: wpci3: STA 78:d3:8d:d2:f9:-- IEEE 802.11: associated (aid 10)                     │
Feb  8 23:56:52 hostapd: wpci3: STA 78:d3:8d:d2:fa:-- IEEE 802.11: associated (aid 11)                     │
Feb  8 23:56:52 hostapd: wpci3: STA 78:d3:8d:d2:f9:-- IEEE 802.11: associated (aid 12)                     │
Feb  8 23:56:52 hostapd: wpci3: STA 78:d3:8d:d2:fa:-- IEEE 802.11: associated (aid 13)                     │
Feb  8 23:58:28 kernel: phy3: Performing hard card reset                                                   │
Feb  8 23:58:29 admin: wifi: phy3: card stalled (PCI error, or too much noise) - restarting device         │
Feb  8 23:58:29 kernel: sh (9479): drop_caches: 3                                                          │
Feb  8 23:58:30 kernel: device wpci3 left promiscuous mode                                                 │
Feb  8 23:58:30 kernel: br0: port 2(wpci3) entered disabled state                                          │
Feb  8 23:58:32 kernel: IPv6: ADDRCONF(NETDEV_UP): wpci3: link is not ready                                │
Feb  8 23:58:35 pingwd: System is busy; pinging has been deferred.                                         │
Feb  8 23:58:36 kernel: device wpci3 entered promiscuous mode                                              │
Feb  8 23:58:36 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wpci3: link becomes ready                           │
Feb  8 23:58:36 kernel: br0: port 2(wpci3) entered listening state                                         │
Feb  8 23:58:36 kernel: br0: port 2(wpci3) entered listening state                                         │
Feb  8 23:58:40 kernel: sh (10628): drop_caches: 3                                                         │
Feb  8 23:58:41 pingwd: System is no longer busy, continuing.                                              │
Feb  8 23:58:51 kernel: br0: port 2(wpci3) entered learning state                                          │
Feb  8 23:59:06 kernel: br0: topology change detected, sending tcn bpdu                                    │
Feb  8 23:59:06 kernel: br0: port 2(wpci3) entered forwarding state

I would love to get to the bottom of this bus so far no go!!
Reply
#3
As usual I cannot duplicate this here. I do however notice that the unit did not fail, but did an activate in the presence of noise.

During the activate time all the other clients moved to the other active AP. I am going to try and make the noise recover less intensive. It seems that Openwrt merely does a simple hardware reset of the radio card, which should happen very quickly and probably would not even lose a connection.

I am studying the code now and will have a test release hopefully by tomorrow.

Noise is inevitable, but the unit should only give errors indications and not crash. That is my goal in all of this.
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Ventana throughput numbers tony 37 35,256 02-12-2015, 08:04 AM
Last Post: lonnie

Forum Jump:


Users browsing this thread: 1 Guest(s)