A computer components & hardware forum. HardwareBanter

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.

Go Back   Home » HardwareBanter forum » General Hardware & Peripherals » Homebuilt PC's
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Length of network cord



 
 
Thread Tools Display Modes
  #1  
Old February 23rd 18, 03:09 AM posted to alt.comp.hardware.pc-homebuilt
Seymore4Head[_2_]
external usenet poster
 
Posts: 15
Default 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  
Old February 23rd 18, 05:41 AM posted to alt.comp.hardware.pc-homebuilt
Paul[_28_]
external usenet poster
 
Posts: 1,467
Default 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  
Old February 24th 18, 03:29 AM posted to alt.comp.hardware.pc-homebuilt
Seymore4Head[_2_]
external usenet poster
 
Posts: 15
Default 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

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


All times are GMT +1. The time now is 09:45 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.