If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Length of network cord
I know 300 ft is the limit for cat5, but I wonder if you are using a
100 ft cord when it could be 60 ft would effect the performance much? |
#2
|
|||
|
|||
Length of network cord
Seymore4Head wrote:
I know 300 ft is the limit for cat5, but I wonder if you are using a 100 ft cord when it could be 60 ft would effect the performance much? So what parameter would it alter ? Amplitude ? Crosstalk ? SNR ? The speed of light in a dielectric is such that it probably doesn't make that much difference. And the transfer protocols are pipelined, to handle much much larger delays. ******* An example of a "dumb" protocol, is async SCSI, where the transfer rate is apparently a function of cable length. Using a super-short cable is supposed to squeeze 5-6MB/sec out of it. I think possibly it's using a sampling strobe for each unit of data which is affected or something. But that's an extreme case. Sync SCSI, I'm not aware of the same issues being an issue. And if I was operating my SCSI scanner on that async cable, it only becomes a real issue when the cable becomes so long, it can no longer support the actual scan rate (1-2MB/sec, which is well less than the max with the current piece of cable). The SCSI scanners, I think were kinda sensor limited. The scanner would have to start and stop during the scan, if the cable held it up. You'd notice if it happened. If the cable was too long, the motor would start and stop, start and stop. ******* But Ethernet doesn't work that way. Perhaps the BER is altered with length, but any time I've run Verify on objects passed over an Ethernet link here, I don't think I've ever caught an actual transmission error as such. Each Ethernet packet is covered by CRC32, and a corrupted packet would likely cause a retransmit request. If there were a ****load of retransmit requests... it affects the overall transfer rate. For example, if I saw my FTP transfer drop from 112MB/sec to some lower number, I might be suspicious (file sharing has enough issues, you cannot use speed as a metric there - the OS can arbitrarily throttle the rate, and seems to on Windows 10 Pro). I've never seen anything like that here with my small sampling of GbE gear. The CRC32 can only drop the perceived error rate by several orders of magnitude. It doesn't drop the possibility of errors to zero or anything. It has limited error detection power, and was merely a convenient polynomial at the time (it was the best we could do with available math theory). It just makes the apparent error rate lower by some amount. Maybe you could find some academic paper that studies this ? Programs like 7ZIP, the most recent ones, have a right-click menu choice, that if a file doesn't have its own internal error detection (like a Macrium file), you can compute SHA1 or SHA256 on the overall file, and compare the checksum on either end of the Ethernet link. But I don't think I've ever caught an error doing that test. And I've done that more than once. And usually with large files, like backups being moved across the room. I transfer, and I don't delete the source file, until the destination file checksum matches. There's never been an error requiring a re-transfer. I have had corrupt Macrium files, but it was caused by bad RAM sticks inside this computer. Which have been replaced. The only reason I don't own longer cables here (I think I have a couple 50 foot ones), is they cost too much :-) That's the best reason for not buying max_length ones. I could probably buy a trolley to haul the cable around in the house :-) I await your paper comparing the 60ft one to the 100ft one. If I keep doing this test over and over again, I'm eventually going to detect an error. Eventually. Because the CRC32 per packet isn't perfect and can't catch everything. The same could happen with SATA - the SATA packets have protection too, for in-flight data. Paul |
#3
|
|||
|
|||
Length of network cord
On Thu, 22 Feb 2018 23:41:44 -0500, Paul
wrote: Seymore4Head wrote: I know 300 ft is the limit for cat5, but I wonder if you are using a 100 ft cord when it could be 60 ft would effect the performance much? So what parameter would it alter ? Amplitude ? Crosstalk ? SNR ? The speed of light in a dielectric is such that it probably doesn't make that much difference. And the transfer protocols are pipelined, to handle much much larger delays. ******* An example of a "dumb" protocol, is async SCSI, where the transfer rate is apparently a function of cable length. Using a super-short cable is supposed to squeeze 5-6MB/sec out of it. I think possibly it's using a sampling strobe for each unit of data which is affected or something. But that's an extreme case. Sync SCSI, I'm not aware of the same issues being an issue. And if I was operating my SCSI scanner on that async cable, it only becomes a real issue when the cable becomes so long, it can no longer support the actual scan rate (1-2MB/sec, which is well less than the max with the current piece of cable). The SCSI scanners, I think were kinda sensor limited. The scanner would have to start and stop during the scan, if the cable held it up. You'd notice if it happened. If the cable was too long, the motor would start and stop, start and stop. ******* But Ethernet doesn't work that way. Perhaps the BER is altered with length, but any time I've run Verify on objects passed over an Ethernet link here, I don't think I've ever caught an actual transmission error as such. Each Ethernet packet is covered by CRC32, and a corrupted packet would likely cause a retransmit request. If there were a ****load of retransmit requests... it affects the overall transfer rate. For example, if I saw my FTP transfer drop from 112MB/sec to some lower number, I might be suspicious (file sharing has enough issues, you cannot use speed as a metric there - the OS can arbitrarily throttle the rate, and seems to on Windows 10 Pro). I've never seen anything like that here with my small sampling of GbE gear. The CRC32 can only drop the perceived error rate by several orders of magnitude. It doesn't drop the possibility of errors to zero or anything. It has limited error detection power, and was merely a convenient polynomial at the time (it was the best we could do with available math theory). It just makes the apparent error rate lower by some amount. Maybe you could find some academic paper that studies this ? Programs like 7ZIP, the most recent ones, have a right-click menu choice, that if a file doesn't have its own internal error detection (like a Macrium file), you can compute SHA1 or SHA256 on the overall file, and compare the checksum on either end of the Ethernet link. But I don't think I've ever caught an error doing that test. And I've done that more than once. And usually with large files, like backups being moved across the room. I transfer, and I don't delete the source file, until the destination file checksum matches. There's never been an error requiring a re-transfer. I have had corrupt Macrium files, but it was caused by bad RAM sticks inside this computer. Which have been replaced. The only reason I don't own longer cables here (I think I have a couple 50 foot ones), is they cost too much :-) That's the best reason for not buying max_length ones. I could probably buy a trolley to haul the cable around in the house :-) I await your paper comparing the 60ft one to the 100ft one. If I keep doing this test over and over again, I'm eventually going to detect an error. Eventually. Because the CRC32 per packet isn't perfect and can't catch everything. The same could happen with SATA - the SATA packets have protection too, for in-flight data. Paul OK So I will put you down for a No. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Extension for Dell power adapter DC Cord ( NOT the AC Cord....) | James | Dell Computers | 7 | September 26th 10 10:54 PM |
Length of warranty length versus expected lifetime of disks | Mark F[_2_] | Homebuilt PC's | 5 | May 27th 09 06:16 PM |
Lat 6x0/830 AC Cord | Frank Haber | Dell Computers | 1 | October 12th 07 10:19 PM |
ADSL Wall PC Cord Length Impact? | Johanna | Homebuilt PC's | 9 | September 20th 06 02:22 PM |
Power Cord? | Eugene | Dell Computers | 6 | June 12th 04 10:18 PM |