Cable Modem not full Dupex?

SuperCow · 13-10-2005, 08:02

Hi all

Something I have noticed recently is that the Cable Modem provided by NTL (Terrayon) does not seem to work in full Duplex mode. I'm on the 3Megs service and as a test I opened two FTP sessions, one downloading a file and the other uploading a file. If only the upload session is running I reach 32Kb/secs which I believe is the correct figure for the 3Megs service. If only the download session is running I get close to 250kb/s (this is a limitation of the remote FTP server as I've reached 330kb/s downloading from other locations). Now, I would expect to be able to run both sessions simultaneously at virtually the same speed (obviously I appreciate some transactions packets are required), but in practice my download speed drops to 110kb/s or so when the full 32kb/s upload is achieved. I've got the same issue with Bittorrent, to the point where I choose to limit my upload rate (usually to 16kb/s) just so that I am able to download faster!
Does anyone know what's going on here? (and please don't tell me this is expected!)

Jon M · 13-10-2005, 09:24

Yes, it IS expected.

"Full Duplex" is a term used in relation to the speed negotiation between LAN (local area network) clients and little to do with your modem speed. (It has an impact, but in your case seems to be working as expected)

Quote:

There is more than enough bandwidth in a 10 Mbps semi-duplex link to keep both download and upload fully loaded on a cable modem. So, yes, you can download and upload simultaneously with a half-duplex ethernet setting.

Synchronous bandwidth levels are what you seem to be describing.

The "transaction" or ACK packets that you are correct in mentioning are the cause.

Have a read of this for some technical information on the behaviour you're getting:
http://homepage.ntlworld.com/robin.d...ps/downup.html

If you saturate your upload bandwidth, it's logical that there isn't therefore the capacity to download at full speed. (read the article above for why that is the case)
__________________

To use a metaphor... how can you expect the postie to deliver new mail through your letterbox if you're pushing out as many as will fit in the letterbox at the same time. (yes, I know it's a bit of a simplification, but bear with me)
__________________

Technically, the metaphor is more accurate if we say this:

The postie is delivering lots of parcels (your download) you're sending lots of parcels too (your upload).. the postie can send his parcels through the open door, but you can only send yours through the letterbox.
The postie however needs a confirmation slip through the letterbox for each of his parcels, so even though the door is open and able to take several parcels at a time, he is sat there waiting for you to push your parcel out and get another confirmation slip out after it.

SuperCow · 13-10-2005, 13:51

Thanks for your answer Jon. I did think the ACK packets would reduce the effectiveness of simulateneous download/upload but not as much as this.

ntl.wotcha · 14-10-2005, 14:00

Quote:

Originally Posted by SuperCow

Thanks for your answer Jon. I did think the ACK packets would reduce the effectiveness of simulateneous download/upload but not as much as this.

No, me either. Bare in mind ack frames are tiny in comparison to data frames and the queuing of the upstream data should not really impact the ack frames that much. I supposed you'd need to sniff it to get a clearer picture but it doesn't bother me that much so....

Another possible explanation is that as far as I can tell, the NTL connection seems to be CSMA/CD half-duplex type which means data collisions will occur. Contrary to popular belief 10Mb is a theoretical throughput and in practice in a contended environment the maximum you will see is about 3-4mbits.