Imagine that switch port configured with FD and PC connected to that port ( 100 Mbps).If FD means that for RECIVE we have 100 Mbps and for SEND -also 100Mbps and is't right that summary will be 200 Mbps? If it so than files will be download with 200 Mbps? Is't right?
Maximum theoretical speed for the file download will be 100 Mbps, assuming that the file server source is local to your client's switch and is connected to that network over a Gigabit Ethernet connection.
Actual download speed depends on:
* where you're getting the file from (local server? Internet web site?)
* speed and duplex of all the connections and network electronics between you and the file's source (you will only be able to go as fast as the weakest link)
* any rate-limiting which may be in effect on any of the connections you're using
* speed and duplex of the file server's actual connection to the network
* how busy the file server is at the time
* whether the file server itself is configured to rate-limit the speed of the client's downloads
* the phase of the moon
Well, just kidding about the moon part.
In a best-case scenario for a file download, most of the 100 Mbps of the download side is used for transport of the file's data from the server. But some of it may be carrying session control/handshaking information from server to client, too.
Most of the upload side of that connection will be carrying session control/handshaking information from client to server.
So on the download, you can approach 100 Mbps but will probably not achieve it.
Also cutting into your 100 Mbps is the fact that in each data frame you're using up some bits for MAC address information, IP address information, protocol information, etc. in the header on each one. So, not all bytes of a max.-size data frame are actually carrying the desired payload.
But full duplex is always better for performance than half duplex, unless you're connecting to a shared media hub.
If two ends try to transmit at the same time on a half-duplex connection, a collision occurs and is recognized by both transmitters. The Ethernet portocol has rules for how each of the interfaces will stop transmitting, "fall back" for a (not really) "random" period of time, then try to transmit again.
The (not really) "random" time periods for each generally means that one of the two (or more)interfaces will get to transmit ahead of the other.
If the (re-)transmitting station again gets a collision, the "fall back" time is doubled (then doubled again ...several times to the max retries value specified by the protocol (15 tries?).
The actual "speed" of the interface is always the same, the period of time a half-duplex interface has to wait may vary. This is NOT the same as "latency" caused by buffering, as in a switch (or router)environment.
The "random" time periods are actually calculated values based on several parameters.
If I am reading your question correctly, you are worried more about the speed thant the throughput ...if that is so .. then you are right in saying that the sending/receiving SPEED is going to be the same i.e. 100 kbps, whats going to change is the throughput ...
Just for an example, if there is a link which carried 1 bit per second, and you and 5 bits to send and 5 bits to receive ...
then on a full duplex you can do send and receive simultaneously and hence your job will be done in 5 secs, since the traffic is coming and going simultaneously. But that didnt change the speed of transmission or reception its still 1 bet per sec.
now on a Half duplex, since its a single line for both send and receive .. it will take a total of 10 sec ( 5 secs send and 5 secs receive ), and god forbid if both sides start at the same time .. there will be collision .. and its gonna take a lot more time .. as illustrated by others ...
Your download will run at a max of 100mbps - the transmit rate on the link could be 200mbps if your high-end desktop multiprocessor box could transmit something to somewhere at the sam time (if I remmeber right the old NT4 couldn't run real FDX because of the old NDIS implementation)
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...