Does high quality digital cables matter?
Comments
-
I didn't miss anything. Unlike others in this debate, I choose to read the entire articles instead of picking and choosing what I want to fixate on. Case in point, villain chooses only to acknowledge, in the Audiophile article posted by pretzelfisch, that there may or may not be any measurable differences. In fact, you folks only seem to like to focus on parts that support your claims instead of the other parts that go against them.
As for "perfect copying channel"...yeah...I have seen "perfect" networks produce errors. I have seen "perfect" OSes spew forth errors constantly and still work well within their established margin of error. Let me ask you this, in all seriousness...if a packetized data network is perfect, why the need for error checking/error correction? Exactly.
TCP as an example is either going to reliably deliver the entire package or something that clearly doesn't work. There isn't a grey area to be had.
I just had a problem with a WinXP virtual machine and the Java Online installer package, for what ever reason, kept getting a corrupt package. So I downloaded the full offline installer and guess what it worked.
The need for error checking and correction is the reason why it ends up either perfect or totally unusable. The original package was still there at Oracle HQ. I just D/L'd it a different way and voila' I have the 60 build of Java.
Ethernet, as an data eco system, did exactly what it was supposed to do. -
Bollocks
-
Allying yourself with someone like villain isn't doing your argument any favors. I think we have already established that he can't argue anything that isn't a direct parrot from someone else.
My point in posting that was to show that errors can be introduced into digital files in many ways. villain asked for examples of ways to introduce errors into digital files... Jitter is an error is it not? If, at some point, jitter is introduced into the file and not corrected and the file is saved again, does the file not have jitter?
As for your argument that a file is simply copied from point A to point B, it isn't copied from point A to point B. Are you trying to tell me that a FLAC file as it exists on a hard drive is the same as a FLAC file as it exists as electrical pulses on an ethernet transmission? We both know better than that. Hell, just look at your own test results from your cables. If your theories were correct, wouldn't they all be identical? Wouldn't the extra "noise" on the cable be identical?
Your problem is you ignore every possible link in the chain except when it is convenient to your argument, then it IS the argument."Some people find it easier to be conceited rather than correct."
"Unwad those panties and have a good time man. We're all here to help each other, no matter how it might appear." DSkip -
Using your TCP example, the IP checksum is a 16 bit 1's complement sum of all the 16 bit words in the IP header. This does not cover the TCP header or any of the TCP data. The TCP checksum is a 16 bit 1's complement sum of all the 16 bit words in the TCP header plus the IP source and destination address values, the protocol value (6) and the length of the TCP segment (header + text). For purposes of the calculation the checksum field has a value of 0.
The checksum calculation will NOT detect
Reordering of 2 byte words, i.e. 01 02 03 04 changes to 03 04 01 02
Inserting zero-valued bytes i.e. 01 02 03 04 changes to 01 02 00 00 03 04
Deleting zero-valued bytes i.e. 01 02 00 00 03 04 changes to 01 02 03 04
Replacing a string of sixteen 0's with 1's or 1' with 0's
Multiple errors which sum to zero, i.e. 01 02 03 04 changes to 01 03 03 03
But according to your argument, TCP/IP is infallible...it is not. Granted, your specific application *should*, but doesn't always catch the above possible errors."Some people find it easier to be conceited rather than correct."
"Unwad those panties and have a good time man. We're all here to help each other, no matter how it might appear." DSkip -
Allying yourself with someone like villain isn't doing your argument any favors. I think we have already established that he can't argue anything that isn't a direct parrot from someone else.
My point in posting that was to show that errors can be introduced into digital files in many ways. villain asked for examples of ways to introduce errors into digital files... Jitter is an error is it not? If, at some point, jitter is introduced into the file and not corrected and the file is saved again, does the file not have jitter?
As for your argument that a file is simply copied from point A to point B, it isn't copied from point A to point B. Are you trying to tell me that a FLAC file as it exists on a hard drive is the same as a FLAC file as it exists as electrical pulses on an ethernet transmission? We both know better than that. Hell, just look at your own test results from your cables. If your theories were correct, wouldn't they all be identical? Wouldn't the extra "noise" on the cable be identical?
Your problem is you ignore every possible link in the chain except when it is convenient to your argument, then it IS the argument.
What are you even talking about? The CRC errors are HANDLED errors. Handled in one of a few ways, RESEND the data until verified, or give up and give you a corrupted file. The thing that won't happen is that you get a file that is LESS then what it was that still works.
You FIX the problem and you re-transfer.
If you have your source HD crash you either restore from back up or you rip all your CD's again and also re-download tracks from whatever service you use.
Your FLAC argument makes no sense. It's coming from someone that doesn't understand how this works. -
You're right. I don't know how it all works. My resume of over 20 years of IT is a sham. My certifications are all shams too.
I am trying to figure out this fantasy world you live in where magically, a file that is stored on a hard drive is identical to packets containing that file's information that are being transmitted over a network. Magnetic storage and ethernet don't work the same. A file has to be converted into a format that can be transmitted and then converted back. This is hardware/software/networking 101.
Ethernet CRC will detect the vast majority of errors. Unfortunately, "vast majority" is not "all". But you keep living in your perfect fantasy world. If things were perfect, there would be no need for IT staff. You would just need trained monkeys to plug things in and walk away."Some people find it easier to be conceited rather than correct."
"Unwad those panties and have a good time man. We're all here to help each other, no matter how it might appear." DSkip -
Monk and ZLTFUL: Should be a good time when you two guys get together to settle this. I'd love to have a video of the whole thing or at the very least audio of the uncomfortable conversation and prolonged periods of silence. Talk about awkward.Things work out best for those who make the best of the way things work out.-John Wooden
-
You would just need trained monkeys to plug things in and walk away.
Hey, why are you poking fun at me now? What did I ever do to you
:biggrin:
"....not everything that can be counted counts, and not everything that counts can be counted." William Bruce Cameron, Informal Sociology: A Casual Introduction to Sociological Thinking (1963) -
EndersShadow wrote: »Hey, why are you poking fun at me now? What did I ever do to you:biggrin:
Get out of here Dan...you're one of those automation specialists...that's worse than a CCNA! (I keed! I keed!)"Some people find it easier to be conceited rather than correct."
"Unwad those panties and have a good time man. We're all here to help each other, no matter how it might appear." DSkip -
You're right. I don't know how it all works. My resume of over 20 years of IT is a sham. My certifications are all shams too.
I am trying to figure out this fantasy world you live in where magically, a file that is stored on a hard drive is identical to packets containing that file's information that are being transmitted over a network. Magnetic storage and ethernet don't work the same. A file has to be converted into a format that can be transmitted and then converted back. This is hardware/software/networking 101.
Ethernet CRC will detect the vast majority of errors. Unfortunately, "vast majority" is not "all". But you keep living in your perfect fantasy world. If things were perfect, there would be no need for IT staff. You would just need trained monkeys to plug things in and walk away.
Because TCP isn't the only thing in the stack performing error checking!
You can use UDP which has ZERO error checking in and of itself and STILL get validation higher up in the OSI stack. Particularly at the Session or Application layer.
Here's the thing: I can setup a server at Digital Ocean, upload 1411Kbps PCM (.wav) files and with a 56K dial up modem with TCP/IP and FTP, eventually, download it. Perform a file compare and get the same exact hash.
Just so we are clear on this:
Using your example are you stipulating that this is going to happen when I come out? That this is going to happen with a $14 cable that blows past spec and not on what ever cable you are going to get cert'd out?
What a red herring. -
Get out of here Dan...you're one of those automation specialists...that's worse than a CCNA! (I keed! I keed!)
HA, they changed my title now... I am a IT Specialist..... so HA!"....not everything that can be counted counts, and not everything that counts can be counted." William Bruce Cameron, Informal Sociology: A Casual Introduction to Sociological Thinking (1963) -
"Some people find it easier to be conceited rather than correct."
"Unwad those panties and have a good time man. We're all here to help each other, no matter how it might appear." DSkip -
Monk and ZLTFUL: Should be a good time when you two guys get together to settle this. I'd love to have a video of the whole thing or at the very least audio of the uncomfortable conversation and prolonged periods of silence. Talk about awkward.
It won't take long to hit 5 incorrect guesses. -
Great, so what does this have to do with the certified cables we are using. Sauce good on goose is equally good on gander.
You either are or you are not drawing a distinction between two cables. -
Habanero Monk wrote: »What a red herring.
The "test" has nothing to do with the topic of the thread or the discussion at hand. As such, I am not trying to distract from anything. All I am trying to do is show that this perfect protocol that you keep referring to as infallible has its faults.
As for the test, nothing has changed. But, if you aren't willing to admit that *maybe* there could be something more to it than what you "know", then what exactly is the purpose of the test anyway? You claim that you aren't in it for the money. Is it the chance to prove someone wrong? What happens when YOU are the one proven wrong? Will you come here and eat your crow with a smile on your face? I somehow doubt it as your red herring keeps seeming to be that 1 person isn't enough of an "N" to get a valid result. And while I agree with you, a scientific study was never our plan nor our intention. If it was, using my system or your testing methodology would invalidate it from the offset."Some people find it easier to be conceited rather than correct."
"Unwad those panties and have a good time man. We're all here to help each other, no matter how it might appear." DSkip -
I love the articles you link to:
What did I just say and what does your linked to article say:
. The causes span the entire
spectrum of a network stack, from memory errors to bugs
in TCP. After an analysis we conclude that the checksum will fail
to detect errors for roughly 1 in 16 million to 10 billion
packets. From our analysis of the cause of errors, we propose
simple changes to several protocols which will decrease the
rate of undetected error. Even so, the highly non-random
distribution of errors strongly suggests some applications
should employ application-level checksums or equivalents. -
The "test" has nothing to do with the topic of the thread or the discussion at hand. As such, I am not trying to distract from anything. All I am trying to do is show that this perfect protocol that you keep referring to as infallible has its faults.
Compared to 28 hops to get to my Bank. Well I will take my chances in a LAN with a segement or even two.
From what you just linked to:
After an analysis we conclude that the checksum will fail
to detect errors for roughly 1 in 16 million to 10 billion
packets. -
Habanero Monk wrote: »Great, so what does this have to do with the certified cables we are using. Sauce good on goose is equally good on gander.
You either are or you are not drawing a distinction between two cables.
So here is the problem as I see it. Several different topics are getting muddled into one.
Cables --> Our test is directly related to this. The only *argument* directly related to this is you say I can't hear a difference between cables that meet spec. I postulate that I can. All other discussion is completely and totally extraneous to this as it pertains to "us".
Digital files, jitter, error detection/correction, tcp/ip theory, etc etc are all extraneous discussions that spun wildly out from the original topic like some psychotic supernova. And while they are related to the above, they aren't part directly related to the test except in that they are some of the unintentional co-conspirators if you will of the test itself. But, I reiterate, those discussions are not the root of the test."Some people find it easier to be conceited rather than correct."
"Unwad those panties and have a good time man. We're all here to help each other, no matter how it might appear." DSkip -
Will you come here and eat your crow with a smile on your face? I somehow doubt it as your red herring keeps seeming to be that 1 person isn't enough of an "N" to get a valid result. And while I agree with you, a scientific study was never our plan nor our intention. If it was, using my system or your testing methodology would invalidate it from the offset.
I'll even buy you dinner in addition to Crow.
In the context of a home environment, with all the upper layer checksums etc while nothing is 'impossible' I'll put my $$ on improbable.
Heck they even make ECC Buffered RAM for servers for that 1 in 4 billion error. -
Habanero Monk wrote: »Compared to 28 hops to get to my Bank. Well I will take my chances in a LAN with a segement or even two.
From what you just linked to:
After an analysis we conclude that the checksum will fail
to detect errors for roughly 1 in 16 million to 10 billion
packets.
Case in point, you ignore the other part where:Traces of Internet packets from the past two years show that
between 1 packet in 1,100 and 1 packet in 32,000 fails the
TCP checksum, even on links where link-level CRCs should
catch all but 1 in 4 billion errors. For certain situations,
the rate of checksum failures can be even higher: in one
hour-long test we observed a checksum failure of 1 packet in
400. We investigate why so many errors are observed, when
link-level CRCs should catch nearly all of them.
If taken out of context, your choice of quote can be misleading. And to the same end, my quote above can also be misleading. But in context of the paper as a whole, the conclusion offers reinforcement that TCP and CRC are not infallible.Our conclusion is that vital applications should strongly con-
sider augmenting the TCP checksum with an application
sum."Some people find it easier to be conceited rather than correct."
"Unwad those panties and have a good time man. We're all here to help each other, no matter how it might appear." DSkip -
So here is the problem as I see it. Several different topics are getting muddled into one.
Cables --> Our test is directly related to this. The only *argument* directly related to this is you say I can't hear a difference between cables that meet spec. I postulate that I can. All other discussion is completely and totally extraneous to this as it pertains to "us".
Digital files, jitter, error detection/correction, tcp/ip theory, etc etc are all extraneous discussions that spun wildly out from the original topic like some psychotic supernova. And while they are related to the above, they aren't part directly related to the test except in that they are some of the unintentional co-conspirators if you will of the test itself. But, I reiterate, those discussions are not the root of the test.
You can't use your articles to preclude the overwhelming probability of a perfect copy how ever.
10 billion packets at 1500 (1.5K) is 146484MB that TCP may not catch but an upper layer may. -
Habanero Monk wrote: »So for a TI particular implementation, even at injected jitter of 2.63ns at 492 feet, there is ZERO, NUNCA, ZILCH, NADA, DUT(device under test) and it's Partner Errors.
A question I find myself asking: What box of 500 ft cable where they using? What was the cost per foot? Certainly food for thought.
Didn't you read the whole review? There's a reason it performed so good, and put to shame every generic ethernet cable out there. They used 500ft of Blastx Hyphenator Extreme Cat7. Quad-sheilded, magnetically luxed, renfer slashed, and magnesium connectors. It's the bee's knees. You can get it for something like $69 an inch on their ebay site. Their real site is down right now, but it's all the highest quality, hand built cable.Too many good quotes to list..waiting for some fresh ammo. -
I didn't miss this:
Traces of Internet packets from the past two years show that
between 1 packet in 1,100 and 1 packet in 32,000 fails the
TCP checksum,
You need to read this:
After an analysis we conclude that the checksum will fail
to detect errors for roughly 1 in 16 million to 10 billion
packets.
The first part means that the the packet fails the TCP checksum it means it was a caught error. It doesn't mean "the checksum will fail to detect errors"
That is the 1 in 16 million to 10 billion.
Again on a local network where I have ripped my CD's or even downloaded a high resolution file I'll take my chances on repeatedly streaming them between TCP and upper layer error detection and correction. -
You must have missed this:
A "perfect copying channel" is trivial, and accomplished by even the cheapest of computers.
I think everyone knows that editing, or transcoding a file to a lossy format will not be an exact copy.
ZLTFUL obviously doesn't know what he's talking about. He just posted that huge "Digital generation loss" article because it probably looked super complex to him, when all it talked about was the fundamentals and absolute basic terminology behind a few things. As if we didn't know what "Transcoding" was, or the difference between "Lossy" and "Lossless". Seriously, It's hard not to be a dick about a post like that..but I'm going to just let him bask in his own ignorant bliss. I actually feel bad for the hole he's dug.Too many good quotes to list..waiting for some fresh ammo. -
As for your argument that a file is simply copied from point A to point B, it isn't copied from point A to point B. Are you trying to tell me that a FLAC file as it exists on a hard drive is the same as a FLAC file as it exists as electrical pulses on an ethernet transmission? We both know better than that. Hell, just look at your own test results from your cables. If your theories were correct, wouldn't they all be identical? Wouldn't the extra "noise" on the cable be identical?
Glad to see that you're still stuck in the "Analog" train of thought. That extra "noise" ISN'T part of the digital signal being sent, and it's not reproduced as such. Can somebody please find a Digital Signals 101 article for ZLTFUL??Too many good quotes to list..waiting for some fresh ammo. -
It's an interesting write up and certainly bit rot is a problem even today. You can only minimize it.
Something of interest as it pertains to cabling from the article:
In general, the CRC will detect the errors on the links and network
interfaces will log them, thus making the errors visible. So
our problem is with the hosts and routers.
Also the paper was written in 1999/2000 from what I can gather. I am curios as to what the metrics are now days.
From an entropy viewpoint nothing is ever the same. -
Habanero Monk wrote: »It's an interesting write up and certainly bit rot is a problem even today. You can only minimize it.
Something of interest as it pertains to cabling from the article:
In general, the CRC will detect the errors on the links and network
interfaces will log them, thus making the errors visible. So
our problem is with the hosts and routers.
Also the paper was written in 1999/2000 from what I can gather. I am curios as to what the metrics are now days.
From an entropy viewpoint nothing is ever the same.
To an extent, I agree with you but while the technology and the materials/methods of hardware construction have improved, the basics have not. In fact, if anything, the error detection and correction has to get better (which it has not) as volumes of data and speeds of transfers increase.
Frankly, though, I am done with this whole conversation unless it is directly related to our test. Villain has no desire to contribute, only argue and you placating him only makes it worse. All he has done and continues to do is parrot you instead of constructing arguments and providing sources of his own. So feel free to discuss the test, outside of that, I am done being involved in this "conversation". You have no desire to educate anyone. You only seek to degrade and insult anyone who has a difference of opinion from yours. An inability to consider other possibilities is the worst form of ignorance."Some people find it easier to be conceited rather than correct."
"Unwad those panties and have a good time man. We're all here to help each other, no matter how it might appear." DSkip
This discussion has been closed.