GS108 switch ports...
Posted by: ken c on 20 June 2015
perhaps i should spend some time reading 'the manual' but i dont recall having one.
warning: the following are probably really noddy questions, so please be gentle....
i bought some AQ ethernet cable to replace the bog-std ons that came with the gear.
the first i thought i would replace was one between NAS drive and Dratek router (i actually thought i had connected this to the switch -- but probably just forgot -- doesnt seem to have done any harm anyhow).
then i found that i couldnt connect it to just any port on the switch -- only worked on specific ones. i also found that even the old cable could ot be connected to any port on the switch only specific ones worked.
my guess, and this is what i would like someone to confirm, otherwise educate me please, is that since the AQ Cinnamon cable is Cat7 spec, only certain ports on the switch are compatible with that. if this is the case, then this change to Cat7 may not as straight fwd as i thought wih my current switch/router. is this correct?
enjoy
ken
Ok Simon, so which ones don't take advantage? Thanks.
Chris
Chris, in my experience Naim doesn't seem to hood wink, but as far as Ethernet cables a TIA/ EIA compliant Cat 6A screened or Cat 5e screened would be a good starting point. Such cables are relatively cheap, and you can try a few between streamer and switch to see which you prefer if any...
Compliant cables generally have TIA/EIA stamped on the cable jacket if they are specifically compliant.
Simon
all my comms equipment (NAS, router, modem, switch) are in a different room to the hi, and therefore on a different mains power circuit.
depending on how the ethernet cables are designed in terms of grounding, does it matter that i may have 2 different grounds here since the hifi has its own dedicated earth?
probably didnt ask that question at all well, but i am just curious anyhow
enjoy
ken
Hey guys, just wondering whether or not you believe this claim made by audioquest in relation to their cinnamon network cable...
I was actually a little bit sick in my mouth when I read this...... I highlighted my favorite parts.
DIRECTIONALITY: All audio cables are directional. The correct direction is determined by listening to every batch of metal conductors used in every AudioQuest audio cable. Arrows are clearly marked on the connectors to ensure superior sound quality. For best results have the arrow pointing in the direction of the flow of music. For example, NAS to Router, Router to Network Player.
1) It's not an audio cable
2) Hahahahaha
I was actually a little bit sick in my mouth when I read this..............
Its quite common after gazing upon the words of wisdom according to AudioQuest, you either become irrevocably hypnotised or as in your case, suffer an overdose of rarefied viper oils.
Chris, in my experience Naim doesn't seem to hood wink, but as far as Ethernet cables a TIA/ EIA compliant Cat 6A screened or Cat 5e screened would be a good starting point. Such cables are relatively cheap, and you can try a few between streamer and switch to see which you prefer if any...
Compliant cables generally have TIA/EIA stamped on the cable jacket if they are specifically compliant.
Simon
hi simon, could you please email me -- my email address is in my profile. many thanks
enjoy
ken
Hey guys, just wondering whether or not you believe this claim made by audioquest in relation to their cinnamon network cable...
I was actually a little bit sick in my mouth when I read this...... I highlighted my favorite parts.
DIRECTIONALITY: All audio cables are directional. The correct direction is determined by listening to every batch of metal conductors used in every AudioQuest audio cable. Arrows are clearly marked on the connectors to ensure superior sound quality. For best results have the arrow pointing in the direction of the flow of music. For example, NAS to Router, Router to Network Player.
1) It's not an audio cable
2) Hahahahaha
Goodness knows why these cables make difference, but they do. Just like speaker leads. My whole network uses Cinnamon leads, from router to switch and then from NAS to switch and switch to streamer. Maybe I'm deluded, but who cares.
hi simon, could you please email me -- my email address is in my profile. many thanks
enjoy
ken
Ken - i tried, but the email bounced - you could post on my wall??
Simon
hi simon, could you please email me -- my email address is in my profile. many thanks
enjoy
ken
Ken - i tried, but the email bounced - you could post on my wall??
Simon
done. the 'wall' wasnt working for me earlier -- but i managed now.
enjoy
ken
I have Audioquest cables because they make a clear and obvious improvement to sound quality.
If people are going to dismiss them on the basis of their marketing hype then good luck. That's like saying I won't eat Mars Bars because I don't believe they can will help me work, rest and play.
Keith
Spooks
Please could you recommend some audiophile air for my wireless network (nothing more than £50/litre please).
Thanks, Wat
Wat,
I'm sure () if you filled you listening room with pure nitrogen (rather than a mundane ~80/20 nitrogen oxygen mix) the sound transmitted from the speakers to your ears would be better (but you'd better not listen too long!)
There's you audiophile 'air', rather than the medium through which the digital signals travel .
I still think some audiophile cabling companies may be taking advantage of folk not understanding the technology.
I am shocked! Shocked, I tell you!
Just one final post by me on this topic. Obviously, my views are that audiophile grade network cables do not exist on the premise that the data delivery used when streaming audio is provided by TCP/IP which by its very nature is a guaranteed delivery service using various features to ensure a bit perfect delivery of the data.
The final nail in the coffin for me though, is that most of the common media players/ streaming services available (pure music, tidal, spotify, iTunes) actually buffer the music into memory before playing... so you're not actually even streaming the music live through the wire. It gets buffered first and then played from RAM.
So, since TCP/IP is guaranteeing bit perfect delivery of the data to the media player, combined with the fact that the music you are hearing has been buffered first into RAM (negating the network cable at this point) the network cable isn't going to make a blind bit of difference. Sure, shielding is going to help with excessive packet re-transmission if you live in a power sub station but it won't matter at all once the data has been successfully delivered.
I think this topic has been done enough now but I can't see any compelling evidence to suggest that these things are anything but a con. Sorry.
See? He's definitely an IT-er and no engineer
See? He's definitely an IT-er and no engineer
Yep. I'd agree with that. Logic above all else.
Yes, just binary logic and nothing else
Yes, just binary logic and nothing else
I wish I was an engineer, then I could come out with really insightful comments like you.... if only I could go back in time and tell Alan Turing to not bother with computers, we'd all be better off without them.
Yes, just binary logic and nothing else
I wish I was an engineer, then I could come out with really insightful comments like you.... if only I could go back in time and tell Alan Turing to not bother with computers, we'd all be better off without them.
This is a bit of an 'insider joke' with S-i-S.
I am a lifelong IT-er but do have an engineering background and it is so obvious that people working in IT cannot/donot look beyond the abstract binary logic they are accustomed to. While in 'real life' everything is plain analogue electronics with all the analogue side effects that occur alongside the binary logic. So if one says it is just ones-and-zeroes, he only gets half the story.
Rambling over
Yes, just binary logic and nothing else
I wish I was an engineer, then I could come out with really insightful comments like you.... if only I could go back in time and tell Alan Turing to not bother with computers, we'd all be better off without them.
This is a bit of an 'insider joke' with S-i-S.
I am a lifelong IT-er but do have an engineering background and it is so obvious that people working in IT cannot/donot look beyond the abstract binary logic they are accustomed to. While in 'real life' everything is plain analogue electronics with all the analogue side effects that occur alongside the binary logic. So if one says it is just ones-and-zeroes, he only gets half the story.
Rambling over
I started off as a biologist before moving into instrument engineering and then computing. I agree it's all binary - you're either alive or you're dead; definitely binary even in biology as well.
Yes, just binary logic and nothing else
I wish I was an engineer, then I could come out with really insightful comments like you.... if only I could go back in time and tell Alan Turing to not bother with computers, we'd all be better off without them.
This is a bit of an 'insider joke' with S-i-S.
I am a lifelong IT-er but do have an engineering background and it is so obvious that people working in IT cannot/donot look beyond the abstract binary logic they are accustomed to. While in 'real life' everything is plain analogue electronics with all the analogue side effects that occur alongside the binary logic. So if one says it is just ones-and-zeroes, he only gets half the story.
Rambling over
I understand what you are saying, however I am considering all of the things that are necessary with this situation/problem. The reason that we are able to post on this forum now is down to bit perfect data delivery system. As I said previously you cannot have data that is 'sort of right'. It either is or it isn't. Think Yoda 'Do or do not, there is no try'.
Honestly, if you only could see how ridiculous this argument is. How simple do I need to make things - data does not have characteristics/differences. There are only two options 1 and 0. Whilst the music resides in the land of data it cannot be anything but 1 or 0. Once it starts to go down your speaker cable as an analogue signal, then we can talk.
The reason things like TCP/IP exist is because of the imperfect world we live in with regard to data communication. The designers were well aware that lots of sources of interference are going to happen - this is why we re-transmit data where necessary. *sigh* you can lead a horse to water....
My rant over.
Spooks
I think the general argument here is not about the correctness of the bits entering the player, but that a piece of wire is attached to the player hardware. The wire can introduce RFI/EMI in to the player in addition to the correct data. It's this additional ingredient that good cabling seeks to eliminate. [I'm sure somebody will correct this soon].
Personally, I hear no difference between different Ethernet cables: assuming they are working properly. However, whatever we argue the counter argument will be we have not heard the particular magic cable. And it is true, I cannot say that in some systems ether sorcery is not providing a sonic enhancement.
I cannot say unicorns don't exist. I have never seen one. However, I have made up my mind that I am going to seriously reduce the amount of time I spend trying to find one.
The debate will continue for as long as there are fora to debate it and it is easy to be sucked in to such and forget that why we embarked on this high fidelity journey was simply to enjoy a few songs.
BTW what do you think about audiophile air for a wireless network?
All the best, Wat
Hey Wat, I can supply you with as much audiophile grade air as you can haul away. It's not cheap but for you 'I do good price'.
With regard to the interference down the wire during transmission. Correct data is handled by the Transmission Control Protocol, so regardless of what happens during transmission of that data (interference) if the data sent doesn't match up exactly with the data received then the data will be transmitted again....
Excerpt from wikipedia:-
Transport layer
The transport layer establishes a basic data channel that an application uses in its task-specific data exchange. The layer establishes process-to-process connectivity, meaning it provides end-to-end services that are independent of the structure of user data and the logistics of exchanging information for any particular specific purpose. Its responsibility includes end-to-end message transfer independent of the underlying network, along with error control, segmentation, flow control, congestion control, and application addressing (port numbers). End-to-end message transmission or connecting applications at the transport layer can be categorized as either connection-oriented, implemented in TCP, or connectionless, implemented in UDP.
For the purpose of providing process-specific transmission channels for applications, the layer establishes the concept of the port. This is a numbered logical construct allocated specifically for each of the communication channels an application needs. For many types of services, these port numbers have been standardized so that client computers may address specific services of a server computer without the involvement of service announcements or directory services.
Because IP provides only a best effort delivery, some transport layer protocols offer reliability. However, IP can run over a reliable data link protocol such as the High-Level Data Link Control (HDLC).
For example, the TCP is a connection-oriented protocol that addresses numerous reliability issues in providing a reliable byte stream:
- data arrives in-order
- data has minimal error (i.e., correctness)
- duplicate data is discarded
- lost or discarded packets are resent
- includes traffic congestion control
The newer Stream Control Transmission Protocol (SCTP) is also a reliable, connection-oriented transport mechanism. It is message-stream-oriented—not byte-stream-oriented like TCP—and provides multiple streams multiplexed over a single connection. It also provides multi-homing support, in which a connection end can be represented by multiple IP addresses (representing multiple physical interfaces), such that if one fails, the connection is not interrupted. It was developed initially for telephony applications (to transport SS7 over IP), but can also be used for other applications.
The User Datagram Protocol is a connectionless datagram protocol. Like IP, it is a best effort, "unreliable" protocol. Reliability is addressed through error detection using a weak checksum algorithm. UDP is typically used for applications such as streaming media (audio, video, Voice over IP etc.) where on-time arrival is more important than reliability, or for simple query/response applications like DNS lookups, where the overhead of setting up a reliable connection is disproportionately large. Real-time Transport Protocol (RTP) is a datagram protocol that is designed for real-time data such as streaming audio and video.
The applications at any given network address are distinguished by their TCP or UDP port. By convention certain well known ports are associated with specific applications.
The TCP/IP model's transport or host-to-host layer corresponds to the fourth layer in the Open Systems Interconnection (OSI) model, also called the transport layer.
Spooks,
From the digital side of things you are of course correct. However, ultimately these bits have to be pumped into a DAC and that feeds an analogue amplifier. The wire that carries the digital bits also carries a small amount of RFI. This doesn't exceed the digital switching thresholds, so the digital circuitry ignores it. However some of that RFI will creep into the analogue circuitry (through various coupling and/or conduction paths) and here it will interfere with the designed operation of the amplifiers. This is how RFI exerts an influence on the sound - through the analogue circuitry, not in the digital domain.
I hope this helps you understand why both positions are correct in their own way.
Spooks,
From the digital side of things you are of course correct. However, ultimately these bits have to be pumped into a DAC and that feeds an analogue amplifier. The wire that carries the digital bits also carries a small amount of RFI. This doesn't exceed the digital switching thresholds, so the digital circuitry ignores it. However some of that RFI will creep into the analogue circuitry (through various coupling and/or conduction paths) and here it will interfere with the designed operation of the amplifiers. This is how RFI exerts an influence on the sound - through the analogue circuitry, not in the digital domain.
I hope this helps you understand why both positions are correct in their own way.
OK, that I can understand - and makes sense. Now we are talking about DAC design and possibly out of the realms of network cable. If you have a shielded network cable (of any make/brand) it will do the same job as an Audioquest one. Also I think even using regular cat5 in a normal household environment (unless you are wrapping it around magnets - lol) the RFI caused at the DAC end would be negligible.
Secondly, how audioquest think they can get away with claiming that their data cables are directional is laughable. The fact that they say data cables are directional (which is a lie) then how are we to believe anything they come out with? Once you have found them out to be liars you might as well disregard anything they say from then on.
*EDIT*
Actually, no - typically the connection between your device and DAC will be USB cable/TOSLink and NOT a network cable....
So the point remains, no need for a special network cable. Any network cable will do in a household env.
Sorry.
Spooks,
From the digital side of things you are of course correct. However, ultimately these bits have to be pumped into a DAC and that feeds an analogue amplifier. The wire that carries the digital bits also carries a small amount of RFI. This doesn't exceed the digital switching thresholds, so the digital circuitry ignores it. However some of that RFI will creep into the analogue circuitry (through various coupling and/or conduction paths) and here it will interfere with the designed operation of the amplifiers. This is how RFI exerts an influence on the sound - through the analogue circuitry, not in the digital domain.
I hope this helps you understand why both positions are correct in their own way.
OK, that I can understand - and makes sense. Now we are talking about DAC design and possibly out of the realms of network cable. If you have a shielded network cable (of any make/brand) it will do the same job as an Audioquest one. Also I think even using regular cat5 in a normal household environment (unless you are wrapping it around magnets - lol) the RFI caused at the DAC end would be negligible.
Secondly, how audioquest think they can get away with claiming that their data cables are directional is laughable. The fact that they say data cables are directional (which is a lie) then how are we to believe anything they come out with? Once you have found them out to be liars you might as well disregard anything they say from then on.
OK, good.
Firstly most CAT5 (and Cat5e) is UTP, this will connect more of the RFI to different parts of the system than SSTP or SFTP; so there can be a difference of the effect of the RFI.
The amount of RFI in domestic environments varies enormously. In my case I seem to be quite unfortunate and I have to use a lot of ferrite chokes on cables (and inductors in mains cables) to reduce the effect common mode interference has on my audio systems. I have always had to do this at my current location, with components from many manufacturers, the problem isn't exclusive to Naim. The amount of RFI is some domestic environments is certainly enough to have an influence on analogue audio circuitry (I have seen this in my own designs).
Lastly, directionality: Although I'm not so sure on the effect here and I haven't been able to prove it for myself, there is a possible theoretical foundation for this:
Ethernet cables rely on twisted pairs to reduce differential mode interference, but the cables aren't absolutely mechanically stable, the twist does vary slightly along the length. The characteristics of the twist will produce tuned circuits and so will affect the frequency distribution of the RFI. This can cause slight variations of the effect of the RFI on the analogue circuitry. Whilst I've not heard a difference myself I don't dismiss the possibility out of hand.
Spooks,
From the digital side of things you are of course correct. However, ultimately these bits have to be pumped into a DAC and that feeds an analogue amplifier. The wire that carries the digital bits also carries a small amount of RFI. This doesn't exceed the digital switching thresholds, so the digital circuitry ignores it. However some of that RFI will creep into the analogue circuitry (through various coupling and/or conduction paths) and here it will interfere with the designed operation of the amplifiers. This is how RFI exerts an influence on the sound - through the analogue circuitry, not in the digital domain.
I hope this helps you understand why both positions are correct in their own way.
OK, that I can understand - and makes sense. Now we are talking about DAC design and possibly out of the realms of network cable. If you have a shielded network cable (of any make/brand) it will do the same job as an Audioquest one. Also I think even using regular cat5 in a normal household environment (unless you are wrapping it around magnets - lol) the RFI caused at the DAC end would be negligible.
Secondly, how audioquest think they can get away with claiming that their data cables are directional is laughable. The fact that they say data cables are directional (which is a lie) then how are we to believe anything they come out with? Once you have found them out to be liars you might as well disregard anything they say from then on.
OK, good.
Firstly most CAT5 (and Cat5e) is UTP, this will connect more of the RFI to different parts of the system than SSTP or SFTP; so there can be a difference of the effect of the RFI.
The amount of RFI in domestic environments varies enormously. In my case I seem to be quite unfortunate and I have to use a lot of ferrite chokes on cables (and inductors in mains cables) to reduce the effect common mode interference has on my audio systems. I have always had to do this at my current location, with components from many manufacturers, the problem isn't exclusive to Naim. The amount of RFI is some domestic environments is certainly enough to have an influence on analogue audio circuitry (I have seen this in my own designs).
Lastly, directionality: Although I'm not so sure on the effect here and I haven't been able to prove it for myself, there is a possible theoretical foundation for this:
Ethernet cables rely on twisted pairs to reduce differential mode interference, but the cables aren't absolutely mechanically stable, the twist does vary slightly along the length. The characteristics of the twist will produce tuned circuits and so will affect the frequency distribution of the RFI. This can cause slight variations of the effect of the RFI on the analogue circuitry. Whilst I've not heard a difference myself I don't dismiss the possibility out of hand.
Again, its still just data... The RFI interference means nothing to what is contained within the data (so long as it gets there). If the data leaving point A gets to point B and matches using techniques already alluded to then there is nothing else to discuss along the network circuit.
Once it hits the computer/device and then goes into the DAC (not via a nework cable) then I guess that's where the RFI comes into play(btw rfi can't infect the 1's and 0's like some kind of trojan)...the distance between a DAC and your Hi-Fi will usually be less than 3 meters... that's up to 3 Meters of USB cable (for arguments sake). The only thing you have to be concerned with is the connectivity from your computer/media device to your hi-fi and beyond. Up until that point you don't have a problem (it's all digital as you say).
Sorry for the stubbornness and you are clearly an intelligent person but for me it's black and white...