Flow Control option request!

[wtm]

Well, we just put in our Netonix switches, and the first Mimosa B5c unit on an old UBNT Rocket Dish backhaul system.

The system is an 1 Gig Fiber <-> UBNT ERL3 <-> Netonix WS-8 <-> Mimosa B5c ~~~ Mimosa B5c <->Netonix WS-8<->UBNT Rocket~~~UBNT Rocket<->Netgear fS-108 switch <-> rest of network

Once we took the main router off 100 Mbps-Half mode to "Auto" to allow it to connect to 1 gig LAN's we started seeing errors on both switches. FC did not seem to help!
Firmware at the point they were installed was 1.1.5, so we upgraded to the 1.1.8 today, and the errors on the Main switch went away, but the mid point switch still has them.

Most are RX drops, and RX Filtered. Most likely because of the transition from the 1 gig Mimosa ports to the 100 Mbps UBNT Rocket ports.

Thought I had, was having the option of extending the Frame Control Delay might help the situation. This would allow additional time to process the backup of data. I don't see where having additional delay would hurt anything, as if the backed up data gets caught up before the delay time ends, it automatically sends a signal to start sending the data.

Thoughts ?

I am happy with the switches, but I would have thought that they would have helped eliminate the backup of the data on the port speed transition better?

Wayne

[RebusCom]

We've seen Rx drop errors at a high rate following firmware updates on the 8 port switches until they are actually power cycled. Have you performed a power cycle since the last update?

[wtm]

Nope, I will have to try that !
Thanks,
Wayne

[Dave]

please let us know if power cycling helps...

[sirhc]

Power cycling or really just a UI reboot after upgrading to v1.1.8 would be prudent because of the software changes we did in v1.1.8.

Once v1.1.8 or later is installed this should not make a difference. Prior to v1.1.8 the PHYs were left powered on during the reboot process which was a mistake (mine). But since the code to power down the PHYs prior to reboot was not put in place until v1.1.8 the first reboot when upgrading to v1.1.8 would use the reboot sequence that does not power down the PHYs prior to reboot.

So once v1.1.8 is installed a UI/CLI reboot should be the same as a power cycle.

This NOT powering down the PHYs prior to reboot was a call I made back in August of last year and was a mistake, mine. We have been chasing the ill effects ever since until we released v1.1.8 which has the PROPER reboot sequence. Since we left the PHYs powered up it allowed network traffic to enter the switch before the software was able to properly initialize and configure the switch and the effects were random as it all depended on what traffic it was at a specific moment if the initialization.

There was another mistake regarding memory allocation that was fixed in v1.1.6 or v1.1.7 that was also fixed. Basically Eric was used to a newer version of C when you grab/allocate memory it would automatically be zeroed or blanked out and since the Vitesse C is of an older different version this memory was not blanked out automatically so there were random issues.

Since both of these bugs had RANDOM effects they were very hard to track down because the symptoms were random.

So in closing v1.1.8 is the most stable version we have released to date and we strongly recommend you upgrade all switches to this version and you might want to tell the switch to reboot again after the upgrade and or even power cycle if it makes you feel better but as I stated a simple UI/CLI reboot after upgrade should be sufficient.

Now if you are upgrading a crucial tower you night want to do so on site but once you are on v1.1.8 and you have power cycled again you are good to go.

[wtm]

Well, re-booted the switch, and that did not seem to help the errors much.
We also moved the Mimosa channels a bit and that did seem to help!
Now showing a whole lot less on the amount of errors, but still getting them ! We will be replacing the second half of the backhaul link this next week. That will give us all 1 gig ports on the backhaul link.

I really think that the option of lengthening out the delay parameter on the "Flow Control" might help the situation. Could be something to look at, it would not hurt anything, as any traffic that gets finished being caught up earlier than the delay time just sends a transmit signal up the line to start sending again. It would only be in the advent that the backlog of traffic has not caught up yet, that the delay runs out, and traffic starts to get sent again, which might be causing the RX drops?

Not sure what delay time is currently being used on the "Flow Control" in your switches? I know that several Juniper and Cisco routers and switches have this option!

[RebusCom]

Well, re-booted the switch, and that did not seem to help the errors much.

Did you also try actually removing power from the switch?