Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   NZ Computing (http://www.velocityreviews.com/forums/f47-nz-computing.html)
-   -   xtras FS (http://www.velocityreviews.com/forums/t579939-xtras-fs.html)

Blue 10-28-2006 08:14 AM

xtras FS
 
Gentle people, as I understand it with a 128kb/s upstream limit, all that
one is going to get down stream is approx 4Mb/s. So it seems to me that
telecom is getting near to the edge of the fraud envelope saying that they
offer FS/128, when the line may well be able to handle 8Mb/s.

Craig Whitmore 10-28-2006 10:25 AM

Re: xtras FS
 

"Blue" <flash130@yahoo.com> wrote in message
news:pan.2006.10.28.08.14.02.684392@yahoo.com...
> Gentle people, as I understand it with a 128kb/s upstream limit, all that
> one is going to get down stream is approx 4Mb/s. So it seems to me that
> telecom is getting near to the edge of the fraud envelope saying that they
> offer FS/128, when the line may well be able to handle 8Mb/s.


I don't know where ppl get this "4M limit from" but people can get over 4M
definately (I know from the test results on my website. Most of the limit is
the Operating system (people with windows XP will get slower downloads on
single connections than people on say MacOSX or Linux due to the standard
windowing on TCP)

I've seem most people Max out at about 4.5Mbps (XP Machines) on single TCP
Downloads (how the speedtest works on the website), but 6.5Mbps is the other
threshold of connections (Probably with FS/FS connections), but with
interleaving off I(which is not possible from Xtra) 've seen 7.2Mbps tests
(the Max ppl will get)

My results are not 100% scientific, but are based on the results I am
seeing.

Thanks
Craig
http://www.nzdsl.co.nz




David Empson 10-28-2006 11:08 AM

Re: xtras FS
 
Craig Whitmore <lennon@orcon.net.nz> wrote:

> "Blue" <flash130@yahoo.com> wrote in message
> news:pan.2006.10.28.08.14.02.684392@yahoo.com...
> > Gentle people, as I understand it with a 128kb/s upstream limit, all that
> > one is going to get down stream is approx 4Mb/s. So it seems to me that
> > telecom is getting near to the edge of the fraud envelope saying that they
> > offer FS/128, when the line may well be able to handle 8Mb/s.

>
> I don't know where ppl get this "4M limit from" but people can get over 4M
> definately (I know from the test results on my website. Most of the limit is
> the Operating system (people with windows XP will get slower downloads on
> single connections than people on say MacOSX or Linux due to the standard
> windowing on TCP)


There will be a theoretical limit due to the rate at which TCP/IP can
send acknowledgements. Working with some rough numbers:

The maximum packet size (MTU) is typically 1500 bytes, so assuming the
sending machine can saturate the connection at 8 Mbps, that is about 1
MB per second, or 666 packets per second.

The receiving machine will attempt to acknowledge every incoming packet,
so it is therefore trying to send 666 packets per second, each
acknowledging one of the incoming packets. The size of a TCP/IP
acknowledgement packet is about 40 bytes, so that means sending about
26.6 KB per second, which is 213 kbps.

This means that the acknowledgement packets will be backing up,
saturating the 128 kbps upstream link. At some point, the sending
machine's transmit window will fill up as it will have to wait for the
next acknowledgement, and it will automatically slow down its rate of
transmission to match the rate at which acknowledgements are arriving.

Working backwards, if the maximum transmission rate for acknowledgements
is 128 kbps, that is about 16 KB per second, which is 400
acknowledgement packets per second; multiplying by 1500 bytes gives
about 600 KB per second, which is about 4.8 Mbps maximum download speed.
(Actual file data will be less, as 40 bytes out the 1500 are used in
TCP/IP headers.)

If the download comes in any faster, the upstream link will be
completely saturated with acknowledgements, and the download will slow
down to match.

All of the above assumes that the receiver is acknowledging every
packet. If it chose to send acknowledgements less often then a FS/128
link would able to support a maximum download speed. I don't know
offhand whether any TCP/IP stack is smart enough to do this.

There will also be limitations due to the window size and end-to-end
latency - if the sender gets 64KB ahead without getting any
acknowledgements, it will stop and wait.

--
David Empson
dempson@actrix.gen.nz

Lawrence D'Oliveiro 10-28-2006 09:33 PM

Re: xtras FS
 
In message <1hnxzas.vq3xue1iosc25N%dempson@actrix.gen.nz>, David Empson
wrote:

> There will be a theoretical limit due to the rate at which TCP/IP can
> send acknowledgements. Working with some rough numbers:
>
> The maximum packet size (MTU) is typically 1500 bytes, so assuming the
> sending machine can saturate the connection at 8 Mbps, that is about 1
> MB per second, or 666 packets per second.
>
> The receiving machine will attempt to acknowledge every incoming packet..


Realistic TCP/IP stacks are smarter than this. They will try to use delayed
ACKs where they can to 1) acknowledge more than one received packet at
once, and 2) piggyback outgoing data in the same packet as the ACK.


David Empson 10-28-2006 10:02 PM

Re: xtras FS
 
Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:

> In message <1hnxzas.vq3xue1iosc25N%dempson@actrix.gen.nz>, David Empson
> wrote:
>
> > There will be a theoretical limit due to the rate at which TCP/IP can
> > send acknowledgements. Working with some rough numbers:
> >
> > The maximum packet size (MTU) is typically 1500 bytes, so assuming the
> > sending machine can saturate the connection at 8 Mbps, that is about 1
> > MB per second, or 666 packets per second.
> >
> > The receiving machine will attempt to acknowledge every incoming packet..

>
> Realistic TCP/IP stacks are smarter than this.


I was pointing out the theory behind the "4 MB limit" claim, which I
agree is a theoretical and unlikely scenario.

> They will try to use delayed ACKs where they can to 1) acknowledge more
> than one received packet at once, and 2) piggyback outgoing data in the
> same packet as the ACK.


Piggybacking outgoing data is only useful if there is bidirectional
traffic for the same TCP connection. I wouldn't expect much upstream
traffic (other than TCP acknokwledgements) are involved in an HTTP or
FTP download.

Bittorrent will have more traffic going both ways.
--
David Empson
dempson@actrix.gen.nz

Mark C 10-29-2006 09:09 AM

Re: xtras FS
 
dempson@actrix.gen.nz (David Empson) wrote in
news:1hnxzas.vq3xue1iosc25N%dempson@actrix.gen.nz:

> There will be a theoretical limit due to the rate at which
> TCP/IP can send acknowledgements. Working with some rough
> numbers:
> ...
> The receiving machine will attempt to acknowledge every incoming
> packet...
> ...
> All of the above assumes that the receiver is acknowledging
> every packet. If it chose to send acknowledgements less often
> then a FS/128 link would able to support a maximum download
> speed. I don't know offhand whether any TCP/IP stack is smart
> enough to do this.


Windows implements RFC1122 Delayed ACKs, so usually, only every
second segment is acknowledged.

If a downloaded packet contains 1500 bytes, and an uploaded ACK 40
bytes, then: 128kbps = 400 ACK/s, which would cover 800 data
packets/s, or 9600kbps of download.
But (assuming ADSL) the ACKs have to fit into an ATM frame with a 48
byte payload, so 8 bytes are wasted, and the ACKs will likely be
counted as if they are 48 bytes each.
128kbps = 333 ACKs/s, which would cover 666 data packets/s, or
7992kbps of download.

In Windows XP (apparently) you can tweak the ACKs to be only every
third, or fourth segment. See this link:
http://support.microsoft.com/kb/328890/
.... which might allow a lower upload.

AFAIK, Win9x/ME/NT do NOT do RFC1122 Delayed ACKs, so you are
stuffed.

David Empson 10-29-2006 10:31 AM

Re: xtras FS
 
Mark C <mark.c@somewhere.invalid> wrote:

> dempson@actrix.gen.nz (David Empson) wrote in
> news:1hnxzas.vq3xue1iosc25N%dempson@actrix.gen.nz:
>
> > There will be a theoretical limit due to the rate at which
> > TCP/IP can send acknowledgements. Working with some rough
> > numbers:
> > ...
> > The receiving machine will attempt to acknowledge every incoming
> > packet...
> > ...
> > All of the above assumes that the receiver is acknowledging
> > every packet. If it chose to send acknowledgements less often
> > then a FS/128 link would able to support a maximum download
> > speed. I don't know offhand whether any TCP/IP stack is smart
> > enough to do this.

>
> Windows implements RFC1122 Delayed ACKs, so usually, only every
> second segment is acknowledged.


Ah, so the problem is avoided if you have a new enough version of
Windows, though a similar one might kick in if Telecom goes as far as
introducing ADSL2+ with a 128 kbps upload limit (the theoretical limit
would be about 8 Mbps down if every second packet was acknowledged).

This explains other claims of operating system differences - Linux and
other Unixes presumably have a smarter TCP/IP stack which uses
techniques like delaying acknowledgements, and does a better job than
older versions of Windows.

--
David Empson
dempson@actrix.gen.nz


All times are GMT. The time now is 11:04 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.