🚀 go-pugleaf

James Knott <the.lights.are.on.but.no.one.is@home.com> writes:

>From: James Knott <the.lights.are.on.but.no.one.is@home.com>
>Subject: Re: Odd problem with @Home service
>Newsgroups: comp.dcom.modems.cable,cableinet.cable_modems
>Date: Sat, 15 Sep 2001 23:39:32 GMT
>
>The Old Bear wrote:
>>
>> Matt <mwalcoff@onecom.com> writes:
>>> 
>>>I am having trouble with my new cable modem service. Whenever I
>>>request a Web page, it loads up only the first 10 KB or so -- the
>>>background or the very top of the page, if anything -- then stalls.
>> 
>> It looks like some kind of overflow problem where your computer can
>> take medium size mouthfuls of data just fine (mail, news, part of a
>> web page) but chokes once its mouth is full and your cable modem keeps
>> trying to push more in faster than your computer can chew and swallow.
>> (Yucch!)
>> 
>> Usually this is handled by flow control at the ethernet level (between
>> your PC's Network Interface Card and the Cable Modem.)  I think that
>> folks who have been advising you about your ethernet settings are on
>> the right track.  But the problem may be that your ethernet card is
>> defective -- something which does happen occassionally.
>
>The flow control is performed by TCP or in the case of UDP, certain 
>applications.  TCP uses a sliding window (determined by the receiving 
>host), which determines how much unacknowledged data may be 
>outstanding.  Also, TCP determines the weighted average ack time for 
>packets that don't require retransmission, and waits a bit longer than 
>that time, before retransmitting.  If a packet fails to be acked within 
>that time an a retransmission is required, the transmit portion of TCP 
>will reduce the allowed amount of outstanding data to one packet and 
>retry.  It will then keep on trying, with longer wait times, until it 
>starts to again receice acks for packets, without retransmission.  Then 
>it will start calculating the new average and start ramping up to the 
>full sliding window size.  There is no flow control at the ethernet 
>level, other than packet and collision detection.

Yes.  This is why I suggested that the winsock dll files be reinstalled 
along with the network card drivers.

The most likely problem is the half-duplex/full-duplex issue already 
discussed here, but Matt has written that his particular network card 
does not offer that option.  It is likely an older card that runs in 
half-duplex mode only which suggests that it may be a failure in the 
card itself.  Therefore, if winsock and driver reinstalls don't solve 
the problem, it could be the NIC card demostrating some kind of flakey 
behavior.

James is absolutely correct about how TCP operates.  I erred in using 
the term "flow control" but did so because is was an easier concept to 
deal with than getting into to the specific wheres and hows of the 
protocol.  Had I been competent enough to explain it as succinctly as 
James, I might have done a better job.  I appreciate James taking the 
time to jump into the thread and set things straight.

Cheers,
The Old Bear