EtherREGEN: Installation, Usage, Difficulty, Questions thread

[Bricki]

I may as well kick this thread off with a question about ethernet speeds.

 

I have my server and endpoint bridged and I was thinking of installing my Etheregen in this bridge. I have changed my ethernet speed on this bridge to 10Mb/s and half duplex with auto negotiation turned off, with this slower speed it sounds a little more relaxed. Will the Etheregen work with these current settings? or will I need to change these settings back to full duplex and 1000Mb/s? or 100Mb/s before I install it? 

[Bricki]

2 hours ago, Superdad said:

I'll come back to you on this in a few hours.  I honestly can not remember how we handle super-slow 10Mbps connections. EtherREGEN's 'B'-side port is 100Mbps and not 1000Mbps(Gigabit) for sure, I just don't remember if it can negotiate down to 10Mbps. I'll check with @JohnSwenson later today.

That's ok 👍. I'm in the 3rd batch, order number 9051... So I don't need an answer right away... I've made a number of server changes in the last week with audiolinux 2, so I'm going to retest with 100Mb/s and full duplex again and see if I still prefer it at 10Mb/s.

 

So is the A side backwards compatible with 100Mb/s or can the A side only accept gigabit?

[Bricki]

2 minutes ago, JohnSwenson said:

The A side RJ45 jacks are 10/100/1000, the A side SFP port is just 1000, The B side RJ45 is 100.

 

That's the way it is, there is no way to change any of that.

 

John S.

Excellent, thanks for that 👍... I'll change my settings to 100Mb/s before installing it

[Bricki]

3 hours ago, Superdad said:

 

Stay tuned on that.   

As John and I were studying the most current errata sheet for the main switch chip used in the EtherREGEN, we noticed a section regarding register code changes for improved PHY performance. I asked him to consider trying those.  

He did try those tweaks, and to quote the e-mail he sent me at nearly 1:00 a.m. last night:

 

"And it sounds quite a bit better as well! No Idea why, but it does. It is weird, the headphones are giving quite a bit better soundstage.
Listen to it your self, you might want to recommend this for everyone.
Wow! I'm listening to this as I'm typing, a new song just came on and I got goosebumps." 

 

So yes, it seems that maybe everyone will want the new firmware code loaded. 

 

Now, as usual the morning flew by with all sorts of logistics chores (getting more Crystek clocks delivered, getting parts on order and shipments out, replying to urgent e-mails) and I've yet to have lunch. So while I have the "magic" new firmware file that is to cure the EEE/connectivity problem and potentially bring another sonic bump, I have made zero progress on the instruction sheet. My wife is not well today and we have no food in the house, so I now headed to town for lunch and to market.

 

Will I have a chance to it myself? Not right away.

My first priority is to write the instructions and first send them and the firmware to a group of users in my e-mail box who have the worst cases of the connectivity blues. We want to confirm it solves the issue for them. (John and I both have had a hard time replicating the problem consistently; It never even showed up for any of our beta testers.) Once we have that confirmation, then I will roll it out publicly. Those few users who first test it can also give me feedback on my instruction sheet.

 

Most of you know that I am an easily distracted fellow--especially when it comes to responding here on the forum.  So the quieter you can keep things here, the sooner I'll have the above firmware update roll-out process going.

And please, even if you are having the issue, I'd rather you not e-mail me to jump into the above early test group. The names I already have slated to receive it represent a diverse enough range of devices for us to know if we have the problem licked.

 

Thanks all!

--Alex C.

Will these register code changes give improved performance for the B side PHY as well? Or do these changes only effect the PHY performance on the A side?

[Bricki]

11 minutes ago, Summit said:

 

Yes I would need to reorganize my audio system, because I don’t have any unused power outlets left on my power conditioner or on the mains wall outlet close to my audio system. I have lots of unused outlets on my other power conditioner used for my routers, switch etc.

 

I must say that I find the reaction to my question almost unfriendly. It is a thread for question and I have bought ER and read things like this below and was wondering if it was affecting SQ if using longer cables. I guess now I know better than to ask again here.

 

 The point being that what comes before the isolation--and final clocking "out" to the DAC-connected device--is what will matter much less.  But the cable from that--typically the lone 'B"-side port--will be the one that still matters.  Hence we suggest keeping the EtherREGEN close to the DAC-connected Ethernet renderer (or Ethernet DAC) and using a short, high-quality cable for that connection.

 

 

In my experience, a 1 meter Ethernet cable sounds better than a 10 meter Ethernet cable and in some cases a 1 meter lesser quality cable sounds better than a 10 meter higher quality cable... So yes length matters in my experience, however if you can't make it work in your setup then don't fuss about it too much 👍

[Bricki]

2 hours ago, lxgreen said:

I just completed firmware update and everything seems to work fine. FYI, I didn’t realize I had an issue with EtherRegen but now I realize I did. I use a sonictransporter for Roon Core. When I plugged sonictransporter Ethernet cable into sonictransporter, Roon could not find Core. So I got it to work by plugging sonictransporter into Ethernet port on router. Now, after firmware update, I can plug sonictransporter Ethernet directly into EtherRegen. However, now I have copper Ethernet from router going to EtherRegen B port so I can use optical from A side to my optical renduSE. So I have two inputs into A side ( optical to rendu and copper to sonictransporter. I’m still a bit confused on how to use A ports in this configuration. Would I be better off plugging sonictransporter back into router so I leave A ports empty except for optical?

If you are feeding your optical rendu from the SFP on the A side then you do not want to have any other devices connected on the A side because the other devices clock phase noise will contaminate the ground on the A side.... You should connect your SonicTransporter to your router... You want everything else on the B side of the moat 👍

[Bricki]

3 minutes ago, lxgreen said:

I know that this guidance has been mentioned in previous posts but then more recent posting say it’s ok to use other A ports. That’s why I’m still not sure.

It's ok to use other A side ports if your dac attached renderer/endpoint is connected to the B side... But if your dac attached renderer/endpoint is on the A side then you will be introducing the other A side devices clock phase noise to your endpoint

[Bricki]

2 minutes ago, André Gosselin said:

@lxgreen Please see my post on Nov.10 about a very similar interrogation to the one you have. The answer by @JohnSwenson was unequivocal:

•  
•  
•  
• 1644 posts

• Report post
•  
•  #10

Posted November 10

What you are describing is probably the best way to go.  In this case most of the packets are going to the endpoints, hence crossing the moat, thus there should be little interaction between endpoints.

 

That is certainly how I would connect things.

 

John S.

It appears crystal clear to me that you can connect more than one audio equipment to the A side, if everything goes through the moat from the router on the B side, and the NAS/music server is connected to the router (and, I guess, provided that PS are not shared between endpoints on the A side.). "That is the way I would connect things", to quote John.

Yes, however, @lxgreen has his SonicTransporter on the A side... In this case, those packets between server and endpoint are not crossing the moat... I think@JohnSwenson was talking about multiple endpoints on the A side would be ok... I still think that @lxgreen would be better off with his SonicTransporter attached to his router to ensure that packets between server and endpoint are crossing the moat 👍