Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > NZ Computing > orcon plans (new ones)

Reply
Thread Tools

orcon plans (new ones)

 
 
Zipper
Guest
Posts: n/a
 
      10-10-2006
The Other Guy wrote:
> Zipper wrote:
>> Is it even possible for an ISP to offer xxx/256?
>> I don't think they can. For some reason Telecom don't seem to want to
>> let ISP's offer 256 up, its either 128 or fullspeed.. seems a bit
>> strange..

>
> Nope, it is either 128k up or 512k up. No option for full speed
> upstream. ADSL can't go much faster than that upstream.
>
> The Other Guy


I meant on the new plans, Telecom are changing any plans with 512
upstream currently to fullstream up.

 
Reply With Quote
 
 
 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      10-10-2006
In message <egf3dj$lue$(E-Mail Removed)>, Alan wrote:

> TCP will always perform it error correction functions despite this
> interleaving thing being on or off - I cannot see how it wouldn't, but
> I stand ready to be corrected!


TCP performs error detection, not correction. It sends a NAK instead of an
ACK response, meaning "I didn't get that, please resend".
 
Reply With Quote
 
 
 
 
Alan
Guest
Posts: n/a
 
      10-10-2006

"Lawrence D'Oliveiro" <(E-Mail Removed)_zealand> wrote in
message news:egfpvn$v77$(E-Mail Removed)...
> In message <egf3dj$lue$(E-Mail Removed)>, Alan wrote:
>
>> TCP will always perform it error correction functions despite this
>> interleaving thing being on or off - I cannot see how it wouldn't,
>> but
>> I stand ready to be corrected!

>
> TCP performs error detection, not correction. It sends a NAK instead
> of an
> ACK response, meaning "I didn't get that, please resend".
>


What is the purpose of the NAK if not to get the corrupted / lost
packet(s) resent in order to facilitate the correction of the data
stream?

Isn't detection simply one part of the correction mechanism or am I
misunderstanding what you are saying?

Thanks,

Alan.
--

The views expressed are my own, and not those of my employer or anyone
else associated with me.

My current valid email address is:

http://www.velocityreviews.com/forums/(E-Mail Removed)

This is valid as is. It is not munged, or altered at all.

It will be valid for AT LEAST one month from the date of this post.

If you are trying to contact me after that time,
it MAY still be valid, but may also have been
deactivated due to spam. If so, and you want
to contact me by email, try searching for a
more recent post by me to find my current
email address.

The following is a (probably!) totally unique
and meaningless string of characters that you
can use to find posts by me in a search engine:

ewygchvboocno43vb674b6nq46tvb




 
Reply With Quote
 
Jerry
Guest
Posts: n/a
 
      10-10-2006
Alan wrote:
> "Lawrence D'Oliveiro" <(E-Mail Removed)_zealand> wrote in
> message news:egfpvn$v77$(E-Mail Removed)...
>
>>In message <egf3dj$lue$(E-Mail Removed)>, Alan wrote:
>>
>>
>>>TCP will always perform it error correction functions despite this
>>>interleaving thing being on or off - I cannot see how it wouldn't,
>>>but
>>>I stand ready to be corrected!

>>
>>TCP performs error detection, not correction. It sends a NAK instead
>>of an
>>ACK response, meaning "I didn't get that, please resend".
>>

>
>
> What is the purpose of the NAK if not to get the corrupted / lost
> packet(s) resent in order to facilitate the correction of the data
> stream?
>
> Isn't detection simply one part of the correction mechanism or am I
> misunderstanding what you are saying?


Resending data isn't correcting it, the corrupted data is thrown away.
With error correction the data along with the checkbits are analysed,
and the original data is corrected.
 
Reply With Quote
 
whome
Guest
Posts: n/a
 
      10-10-2006

"Jerry" <(E-Mail Removed)> wrote in message
news:452c1725$(E-Mail Removed)...
> Alan wrote:
>> "Lawrence D'Oliveiro" <(E-Mail Removed)_zealand> wrote in message
>> news:egfpvn$v77$(E-Mail Removed)...
>>
>>>In message <egf3dj$lue$(E-Mail Removed)>, Alan wrote:
>>>
>>>
>>>>TCP will always perform it error correction functions despite this
>>>>interleaving thing being on or off - I cannot see how it wouldn't, but
>>>>I stand ready to be corrected!
>>>
>>>TCP performs error detection, not correction. It sends a NAK instead of
>>>an
>>>ACK response, meaning "I didn't get that, please resend".
>>>

>>
>>
>> What is the purpose of the NAK if not to get the corrupted / lost
>> packet(s) resent in order to facilitate the correction of the data
>> stream?
>>
>> Isn't detection simply one part of the correction mechanism or am I
>> misunderstanding what you are saying?

>
> Resending data isn't correcting it, the corrupted data is thrown away.
> With error correction the data along with the checkbits are analysed, and
> the original data is corrected.


So, my question:

Is there a higher chance that a file downloaded through the internet will be
corrupt when ADSL interleaving is switched off?

I was hoping that perhaps some other protocol would mean there is no
increased chance of corruption. Seems to me that interleaving is
unnecessary when there are other protocols that perform error detection and
recovery.


 
Reply With Quote
 
ChrisOD
Guest
Posts: n/a
 
      10-11-2006
In article <452c1725$(E-Mail Removed)>, Jerry wrote:
> Alan wrote:
>> "Lawrence D'Oliveiro" <(E-Mail Removed)_zealand> wrote in
>> message news:egfpvn$v77$(E-Mail Removed)...
>>
>>>In message <egf3dj$lue$(E-Mail Removed)>, Alan wrote:
>>>
>>>
>>>>TCP will always perform it error correction functions despite this
>>>>interleaving thing being on or off - I cannot see how it wouldn't,
>>>>but
>>>>I stand ready to be corrected!
>>>
>>>TCP performs error detection, not correction. It sends a NAK instead
>>>of an
>>>ACK response, meaning "I didn't get that, please resend".
>>>

>>
>>
>> What is the purpose of the NAK if not to get the corrupted / lost
>> packet(s) resent in order to facilitate the correction of the data
>> stream?
>>
>> Isn't detection simply one part of the correction mechanism or am I
>> misunderstanding what you are saying?

>
> Resending data isn't correcting it, the corrupted data is thrown away.
> With error correction the data along with the checkbits are analysed,
> and the original data is corrected.


I thought that was "Forward Error Correction". TCP's resend of data is a
type of error correction. A type that in a reasonably high quality link
is much more bandwidth friendly than FEC. The problem with TCP comes in
low quality links where a significant fraction of the data is lost,
causing a large part to be resent and then some of that is lost etc.


 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      10-11-2006
In message <(E-Mail Removed)>, whome wrote:

> So, my question:
>
> Is there a higher chance that a file downloaded through the internet will
> be corrupt when ADSL interleaving is switched off?


Theoretically, I would have to say yes. TCP checksumming is quite
simple--has to be, otherwise it would be too slow. So if bits can be
corrupted on the wire, then there is a small chance that a bad packet gets
through with a valid checksum.

This is one reason why it's common practice for open-source sites, at least,
to publish fingerprints of their archive files, that you can verify against
your downloaded copy to ensure it's an exact copy.
 
Reply With Quote
 
Dave Taylor
Guest
Posts: n/a
 
      10-11-2006
Lawrence D'Oliveiro <(E-Mail Removed)_zealand> wrote in
news:eghs1b$o6i$(E-Mail Removed):

> Theoretically, I would have to say yes. TCP checksumming is quite
> simple--has to be, otherwise it would be too slow. So if bits can be
> corrupted on the wire, then there is a small chance that a bad packet
> gets through with a valid checksum.
>
> This is one reason why it's common practice for open-source sites, at
> least, to publish fingerprints of their archive files, that you can
> verify against your downloaded copy to ensure it's an exact copy.
>
>


TTL comes into play also. NACK is no good if TTL expired IIRC.
So I would not rely on TCP to transmit good data. I agree that is why we
have MD5 and other checksumming.

--
Ciao, Dave
 
Reply With Quote
 
 
 
Reply

Thread Tools

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

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Test plans and "refined test plans" DZantow Python 0 12-20-2011 06:24 PM
new orcon plans Alan Macdougall NZ Computing 45 03-17-2006 04:31 AM
Important question to Seeby about new Orcon plans - are they really as good as they seem? MarkH NZ Computing 6 08-18-2005 10:20 AM
Orcon UBS 2MBit or stick with Telecom/Orcon 2MBit ADSL? Jamie Kahn Genet NZ Computing 3 04-29-2005 10:10 PM
changing from Orcon UBS to Orcon Jetstream Brendan NZ Computing 2 02-25-2005 08:39 AM



Advertisments