Please! This is not to start a debat over if BETA should be used in production.
We have a few AP's in high noise and heavy load locations. After reading the threads on DISABLE-CSMA I am very interested in trying this in a production site for testing.
The hardware is RB532a 1-XR2 with a 120d sector.
45 users
My test would be to change out the existing router with a BETA release 7 router and DISABLE-CSMA and enable Nstrer with polling.
I will be happy to report my findings but just wanted to see if this has been tested in an AP type environment.
Hey, man, if you are fully aware that it's beta and understand all of the possible ramifications of your decision, then by all means, go for it.
If you do try this, I would be very interested in hearing about your results myself. We have a very heavily loaded AP that we tried using Nstreme on (in 2.9, not 3.x-beta), and cannot get it to work reliably. (I posted about this here.) I am talking with support about it right now, and am hoping they manage to figure it out. Thus far, it doesn't look like they have found a "smoking gun" in our configuration, though I still wouldn't rule out "user error."
It would be interesting to me to find out whether any of the changes or improvements they have made to Nstreme in 3.x directly affect our situation and those that are similar to ours (highly-loaded PtMP APs). Unfortunately, on this particular AP, I do not at this time feel comfortable myself trying to run the beta code as it services a local hospital as well as acts as a backhaul for another location with some other high-profile clients on it.
As far as the Disable-CSMA option, at least one person ran some tests in a lab and came up with these results which you may find interesting (as well as depressing). These tests were run using 3.0-beta5, though, and the issue may have since been addressed in beta7. Unfortunately, the thread itself was never resolved, and it is not clear to me whether the original poster ever bothered to open up a ticket with support about it, so nothing may ever have been done about it, if it is in fact a real problem to begin with.
I have been and will continue to be watching these proceedings concerning Nstreme's future and the "disable-csma" option with a keen eye.
-- Nathan
If you do try this, I would be very interested in hearing about your results myself. We have a very heavily loaded AP that we tried using Nstreme on (in 2.9, not 3.x-beta), and cannot get it to work reliably. (I posted about this here.) I am talking with support about it right now, and am hoping they manage to figure it out. Thus far, it doesn't look like they have found a "smoking gun" in our configuration, though I still wouldn't rule out "user error."
It would be interesting to me to find out whether any of the changes or improvements they have made to Nstreme in 3.x directly affect our situation and those that are similar to ours (highly-loaded PtMP APs). Unfortunately, on this particular AP, I do not at this time feel comfortable myself trying to run the beta code as it services a local hospital as well as acts as a backhaul for another location with some other high-profile clients on it.
As far as the Disable-CSMA option, at least one person ran some tests in a lab and came up with these results which you may find interesting (as well as depressing). These tests were run using 3.0-beta5, though, and the issue may have since been addressed in beta7. Unfortunately, the thread itself was never resolved, and it is not clear to me whether the original poster ever bothered to open up a ticket with support about it, so nothing may ever have been done about it, if it is in fact a real problem to begin with.
I have been and will continue to be watching these proceedings concerning Nstreme's future and the "disable-csma" option with a keen eye.
-- Nathan
I loaded clean install on version 3beta7 on x86 box in a heavy use production environment running 62 VLAN's and Hotspot.
Asus MB W Intel P4 3GHz
1024Mb DDR Memory
1 - 4gig IDE HDD for ROS
1 - 200gig IDE HDD for web cache proxy
4 - Intel Pro 10/100/1000 nic cards
ether1 and ether2 were setup to load balance between 2 different service providers.
ether3 set up with 62 VLAN's each running individual hotspot / dhcp server
ether4 set up with flat network running hotspot / dhcp server
Using ROS 2.9.42 on same configured machine everything works with very little to no issues.
Using ROS 3b7
Simple Queues did not function properly.
Radius server sets user max rx/tx speed in Simple Queues upon login. Although the queues were added they did not seem to work as many users were able to run at much faster speeds than they were alloted.
Under light load the system ran well other than the problem with the queues.
Under heavy load of 150+ concurrent users, the box locked up and stopped responding about 7-9 times per day. Each time a hard reboot was required to restore service and gain access back to the unit.
After running system for 3 days with these issues we downgraded the system to 2.9.42 and have since had no further issues for past 11 days even under 300+ concurrent user loads.
Perhaps others have had better luck using version 3 in a production environment but it was to unstable for our use and had to be downgraded.
Asus MB W Intel P4 3GHz
1024Mb DDR Memory
1 - 4gig IDE HDD for ROS
1 - 200gig IDE HDD for web cache proxy
4 - Intel Pro 10/100/1000 nic cards
ether1 and ether2 were setup to load balance between 2 different service providers.
ether3 set up with 62 VLAN's each running individual hotspot / dhcp server
ether4 set up with flat network running hotspot / dhcp server
Using ROS 2.9.42 on same configured machine everything works with very little to no issues.
Using ROS 3b7
Simple Queues did not function properly.
Radius server sets user max rx/tx speed in Simple Queues upon login. Although the queues were added they did not seem to work as many users were able to run at much faster speeds than they were alloted.
Under light load the system ran well other than the problem with the queues.
Under heavy load of 150+ concurrent users, the box locked up and stopped responding about 7-9 times per day. Each time a hard reboot was required to restore service and gain access back to the unit.
After running system for 3 days with these issues we downgraded the system to 2.9.42 and have since had no further issues for past 11 days even under 300+ concurrent user loads.
Perhaps others have had better luck using version 3 in a production environment but it was to unstable for our use and had to be downgraded.