v1.4.0rc1-16 Bug reports and comments

[mayheart]

High cpu usage on rc16 with discovery enabled


3372 admin 20 0 10984 9068 556 R 84.8 7.2 431:42.41 discovery probe

[sirhc]

High cpu usage on rc16 with discovery enabled


3372 admin 20 0 10984 9068 556 R 84.8 7.2 431:42.41 discovery probe

Does the CPU stay high or does it eventually settle down?

Right now the Discovery Tab is being reviewed if we even keep it. Currently it only discovers devices that the Management/Default VLAN sees which is not what we want we would prefer it would see other devices on ports not in the default VLAN but we also need to look at how much CPU impact it has. On small segments it might not be too bad but people with large flat networks it may be to much for the little MIPS 24K to handle.

[wisp-wand]

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.

[sirhc]

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 +/-

[mayheart]

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

High cpu usage on rc16 with discovery enabled


3372 admin 20 0 10984 9068 556 R 84.8 7.2 431:42.41 discovery probe

Does the CPU stay high or does it eventually settle down?

Right now the Discovery Tab is being reviewed if we even keep it. Currently it only discovers devices that the Management/Default VLAN sees which is not what we want we would prefer it would see other devices on ports not in the default VLAN but we also need to look at how much CPU impact it has. On small segments it might not be too bad but people with large flat networks it may be to much for the little MIPS 24K to handle.

[sirhc]

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.

[mayheart]

I've disabled all options, Discovery, LLDP, CDP & UDP, no change. Status page still reports 99% cpu usage.

This device powers up a bunch of access points, it's behind a layer 3 device. There's 4 access points (three ubiquiti M5s and one Tranzeo) which approx 47 clients in total.

http://i.imgur.com/xmtL9OS.jpg

I killed the process, everything was fine. Soon as I re-enabled "discovery" under configuration, it went back to 100% usage.

[sirhc]

I've disabled all options, Discovery, LLDP, CDP & UDP, no change. Status page still reports 99% cpu usage.

This device powers up a bunch of access points, it's behind a layer 3 device. There's 4 access points (three ubiquiti M5s and one Tranzeo) which approx 47 clients in total.

http://i.imgur.com/xmtL9OS.jpg

I killed the process, everything was fine. Soon as I re-enabled "discovery" under configuration, it went back to 100% usage.

So if you Disable Discovery (the one in the picture below) and then kill the process and or reboot the unit the CPU stay normal?

avatar.jpg (17.29 KiB) Viewed 9987 times

After CPU is normal from Disabling Discovery shown above can you then enable UDP/CDP/LLDP and the CPU stays normal?

[mayheart]

Correct.

I can re-enable all the options but Discovery without the CPU spiking.

Soon as Discovery is re-enabled regardless of the other options, the cpu will goto 100%.

[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?