v1.4.0rc1-16 Bug reports and comments

[sirhc]

I know this is just an RC batch right now, but is there going to be QoS/VoIP forwarding support in the final 1.4 version?

Yes QOS is planned for v1.4.1, we were actually just discussing this on a conference call. The question we are deciding is how granular we will allow it to be configured or simply allow it to be turned on and use the standard queuing defaults.

[CVPB]

I know this is just an RC batch right now, but is there going to be QoS/VoIP forwarding support in the final 1.4 version?

Yes QOS is planned for v1.4.1, we were actually just discussing this on a conference call. The question we are deciding is how granular we will allow it to be configured or simply allow it to be turned on and use the standard queuing defaults.

Awesome!

If it matters, I'd highly recommend allowing more granularity if possible. We're in the process of deciding whether to stick with these Netonix switches we've been testing and the QOS is our primary concern at this point. The standard queuing defaults should be more than enough for our network but I'm sure there are others who have much more intensive needs.

Thanks for the reply, definitely liking these Netonix so far.

[sporkman]

My graphs show the CPU has been at 100% since the switch rebooted from the upgrade.

But if you Disable Discovery it settles down?

And we are talking about the Discovery Tab being enabled which causes the CPU spike or the enabling of UDP/CDP/LLDP?

Please detail your environment:
Is this a large flat segment?
How many devices?

Explain your setup please.

Explain what the CPU does if you disable it, maybe post the device Status screen with and without it enabled.

Also maybe post a screen grab of the Linux screen showing CPU usage when it is 100%

These are the types of investigation and results that will help Eric fix it.

Still seeing this here as well on r16:

Code: Select all

 
BusyBox v1.19.4 (2016-04-28 19:18:26 EDT) built-in shell (ash)
 Enter 'help' for a list of built-in commands.
 top - 17:02:37 up 33 min, 0 users, load average: 1.16, 1.20, 1.03
Tasks: 62 total, 3 running, 59 sleeping, 0 stopped, 0 zombie
Cpu(s): 88.8%us, 10.5%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.3%hi, 0.3%si, 0.0%st
Mem: 126348k total, 52224k used, 74124k free, 4360k buffers
Swap: 0k total, 0k used, 0k free, 16440k cached
 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 750 bwayadmi 20 0 6976 5052 556 R 77.3 4.0 28:23.49 discovery probe
 741 bwayadmi 20 0 6976 5052 556 R 4.5 4.0 1:06.18 switch
 752 bwayadmi RT 0 6976 5052 556 S 1.9 4.0 0:36.06 i2c thread
 739 bwayadmi 20 0 2120 636 452 R 1.9 0.5 0:00.17 top
 734 nobody 20 0 2280 672 576 S 1.3 0.5 0:00.55 shellinaboxd
 718 bwayadmi 20 0 7016 1960 1052 S 1.0 1.6 0:04.49 lighttpd
 717 bwayadmi 20 0 7012 1972 1052 S 0.6 1.6 0:05.59 lighttpd

 

-It stays like this, it does not eventually settle down
-On this L3 segment I have 6 devices visible; two local ubnt devices, two remote ubnt devices, one remote netonix and one remote cisco switch
-The other switch only sees 3 devices, same result
-Both the "Ubiquiti" discovery checkbox and the general "Discovery" checkbox below it are checked
-Unchecking "Ubiquiti" and saving does not stop the process from using all cpu
-Unchecking the general "Discovery" checkbox does not stop the process from using all cpu
-Manually killing the process from the shell takes care of it of course... :)
-Rebooting with both discovery boxes unchecked results in normal CPU usage
-Manually enabling just the "Ubiquiti" checkbox results in normal CPU usage (but no devices are discovered)
-Manaully enabling the "Discovery" checkbox results in the CPU spiking (still no devices discovered)

Anything else? Totally repeatable on at least two switches I'm paying attention to...

[sirhc]

You have to disable Discovery then reboot switch or stop the service manually
This will be fixed next release

Next time read through the previous post in the release thread before you report something that may have already been posted/reported or the post just repeats the same thing over and over again and gets too long

Click here and it will take you to the discussion in this thread viewtopic.php?f=17&t=1459&start=120#p12545

[wisp-wand]

Chris, this is the problem with you not running a ticket system, you can't remember who has what issue and where! you have PM'd me on a couple of occasions about this, switch, its location and the issues, as well as follow ups on the forums.

I am in the high EMC (Electric train track, nearby substation NOT FM SITE) since update to RC16 the switch has now been up for 3 days!
Only one instance of i2c error

May 5 14:11:42 switch[1388]: Disabling PoE power on port 3 due to Power Supply Thermal out of specification (heatsink 2 is 118 C)
May 5 14:11:47 switch[1388]: Enabling PoE power (24V) on port 3 due to Power Supply Thermal within specification

I am going to enable some far up ports with POE and then get the switch to shut them down first if it gets these errors, if I can do that and it doesn't crash (looking MUCH better in that regard) I might be able to put some live traffic on it

Running ok so far on my switch at the seemingly heavy EMC site!
I did have to visit site again to recover it though, as it crashed on the previous release, and it did an odd thing. The internal power light was on, and the external power light PWR was off. I power cycled it, and it briefly came on for about 3 secs then went off again. It did this 3 times. The PSU was stable during this time, and powering other kit that worked through this behavior. It has stayed up for for over 8 hours which is pretty good, nothing in the logs yet. I did watch the status page for a while, fan is running faster than usual, and I did observe the odd jump up in temp to 255 (max is 125c I think) but the switch did not react.

To more help/understand your post you should provide more info so we do not have to research your posts to discover your issues.

I am assuming this is running on a SMART DC switch at a site that has FM interference which caused havoc with our DC powered switches?

Would help to specify model and environment and problem it helps with.

Where as this firmware (v1.4.0rc16) will "help" the SMART DC switches run better at FM sites this is not a sure fire fix. The FIX is a hardware change to both the switch board and the DC2DC power supply which is in production now.

Switch Board RevF will have special filters to better cope with FM interference and then DC2DC power supply will be RevB will also have new filters to help combat the FM noise.

These units will start shipping end of May +/-

[sirhc]

@wisp-wand

Is obvious there is some sort of noise at your location which is interfering with the I2C communications.

I am in the high EMC (Electric train track, nearby substation NOT FM SITE) since update to RC16 the switch has now been up for 3 days! Only one instance of i2c error

rc16 is about as good as we can do software wise, the real fix for interference will be the new hardware revisions that are in production now and should be shipping around the end of the month.

I would like to know the source of the noise. I am curious if the noise is coming in through your power supply possibly created by your power supply or in through the electric service or it is present in the physical area.

To know you would have to take the switch and the power supply that you are using there back to your shop and test. If it works fine at your office then the power supply would be eliminated as a source of the noise and we would know the offending noise of either coming from the electric or being generated nearby.

Plus another good reason to do this is to find out if the board is possibly bad. It maybe that this board is just bad.

I thought this site was also near an elevator but I could be wrong?

[lligetfa]

Chris,
This thread is getting pretty long. I wonder if we could get a new thread for every RC release?

Anyway, WRT RC16, has the fan profile changed on the WS-24? Mine is in a very cool place where the fan only runs for very short spurts but notice on RC16 that the fan starts on a much higher speed than before.

[sirhc]

Chris,
This thread is getting pretty long. I wonder if we could get a new thread for every RC release?

Anyway, WRT RC16, has the fan profile changed on the WS-24? Mine is in a very cool place where the fan only runs for very short spurts but notice on RC16 that the fan starts on a much higher speed than before.

Yes I will create a new thread for the next RC release.

Yes we are messing with the fan controls to try and eliminate the false fan failures but we made a mistake on the last build, it will be corrected on the next release.