EtherREGEN: All posts about firmware moved here

[JohnSwenson]

5 minutes ago, Bricki said:

Since the firmware update brings improved PHY performance on the A side... Is there something to be gained by going from B side to A side??? Assuming that there is only one endpoint connected on the A side (ie no leakage)

In a word: NO.

 

John S.

[JohnSwenson]

5 minutes ago, soares said:

It must be me Alex, as I am just using the fiber. 🤪

but I haven’t touch anything on the system. And whether I am having some ear troubles or it’s not my imagination... 

I am sorry Alex, but it’ what I am hearing. I will check tonight if I disconnected anything from my system.

cheers Jorge

The changes only affect the RJ45 ports on the A side, not the SFP port or the RJ45 port on the B side.

 

Could you remind me of your connectivity again? Do you have anything else on the A side? I've been racking brain trying to figure out how changes to just the A side RJ45 ports could possible affect anything on the SFP port if there is nothing attached to them. The changes only affects signals on the RJ45 ports, so if nothing is connected then I don't see how anything could possibly be changed.

 

We do know that sometimes the SFP modules make poor contacts with the connector inside the SFP cage. Could you try taking the optical cable out, pulling out the SFP module, reinsterting it, firmly pushing it in, then reconnect the optical cable and see if that makes any difference.

 

Thanks,

 

John S.

[JohnSwenson]

53 minutes ago, Ehsu said:

Of course I remember the reason for the update. It was SUPPOSED to fix connection issue only! You do know they changed other codes for SQ as Alex said himself? So I do not know what is your point here? If you love you ER v2 or Tesla, thats fine. I am not asking you to change! If we have a choice, it wont affect people who love their version2. My point is this, I bought a Porsche then it turns into a Tesla or Bentley or whatever after a few weeks?  

This is not true, the changes were NOT made for SQ purposes at all.  Here is the full story on the technical side of this, do with it as you will.

 

Quite a while ago while working on the opticalRendu I noticed the switch chip (the same switch chip was being used at that time) the connection to the CPU was going up and down, many times. I could not figure out what it was. Then an errata sheet came out for the switch chip which talked about the EEE bug, I wrote the code for the workaround on the main processor and fed that to the switch chip, It worked.

 

The EtherREGEN uses the same chip as I had originally on the oR (I picked it for the ER, but used it for prototyping on the oR since I knew it well). At this point the ER did not exist in the final form, it was several different boards trying out different parts of the system. I had not seen the EEE problem at all, probably because I was not testing it with anything that supported EEE. After I finally got the functionality for the ER working and I had the whole system up and running I wrote the code to send the workaround to the switch chip, it was much more complicated because I had to do it for 4 ports instead of one, it was also written for a completely different processor and environment. Somewhere along the line I made a mistake in that code that didn't actually implement the workaround, but I didn't know that at the time. Since I couldn't make the EEE problem happen, (it only happens for some boards and some equipment), I didn't know it wasn't working. Neither my testing, nor Alex's or the beta testers have the problem.

 

The problem only showed up when the ER went out into the field with enough different configurations that some people started having the problem. Remember that at this point I thought I had the workaround for the EEE stuff in every ER out there. It took some time and a lot of looking at the code to realize there was a bug in the code. While in the process I found a new errata sheet for the switch chip that added some new problems for the chip and workarounds for them.

 

At this point I fixed the EEE workaround code and found out that that it actually CAUSED dropouts every time an RJ45 A port connected. The connection would go up, then down, then back up. I could not figure this out, it didn't make any sense. I then tried adding the workarounds for the other two errata issues, both of which were supposedly only for rare "corner cases" which should only occur for long cables. One was for transmit, it increased the transmit amplitude very slightly, and the other was for receive which increased the probability of receiving very weak signals. Viola! The up down up behavior went away. I listened to it for quite some time with no problems, but did notice a small improvement in SQ, I still have no idea why.

 

Well that is it. This was all done in an attempt to improve connectivity issues. The sound change was not something that was intended, it was not something that was "tuned" it just showed up as a result of adding the workarounds for problems that already existed in the chip. I still have no idea how these changes could be affecting SQ.

 

John S.

[JohnSwenson]

6 minutes ago, Jud said:

 

If I'm understanding this, "just fixing EEE without touching anything else" is not an option.

Correct, there is no way I'm sending out anything that causes a connection to go up then down then up, ALL the TIME for everything I tested it on.

 

John S.

[JohnSwenson]

44 minutes ago, rickca said:

Things like this are not unusual in product development.  I think engineers encounter similar things on most projects.  The difference is that John and Alex are so transparent about their R&D process.  And that's something I value a great deal.

The switch chip we are using is an interesting take on this process. The chip was originally designed by one semiconductor company, that was bought by another, then THAT company was bought by yet another semiconductor company. The original designers are long gone. The current company was getting all kinds of complaints about these chips (there is a whole line of them) and THEIR engineers had no idea what was inside. So a couple years ago they gave one of their most experienced engineers the task of finding out what was inside, how it worked and what could be done about the complaints from their customers (engineers putting these chips on boards).

 

The head of the team grabbed several experienced engineers and they spent many months pouring over the files for these chips, learning what was inside and how they worked. They also tested them exhaustively to find out how they really behaved. They found a number of problems and then went the extra mile and figured out ways to program the chip to workaround the problems in the silicon. 

 

I've actually done similar things myself and I'll tell you it is not an easy task. I have a tremendous amount of admiration for the team that did this, and the management that determined it was necessary and stuck with the process.

 

BTW these chips are worth it. There are only a couple chips with similar functionality on the market and they cost at least 6 times as much!

 

John S.

[JohnSwenson]

11 minutes ago, Ricardo007 said:

What is EEE? And associated bug?

Go to post number 2 in this thread and click on the link. That takes you to UpTone's blog page. The second entry describes what is going on.

 

John S.