🚀 go-pugleaf

The Old Bear wrote:

> Matt <mwalcoff@onecom.com> writes:
> 
>>From: Matt <mwalcoff@onecom.com>
>>Newsgroups: comp.dcom.modems.cable,cableinet.cable_modems
>>Subject: Odd problem with @Home service
>>Date: Mon, 10 Sep 2001 03:05:27 GMT
>>
>>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.
>>However, I have been able to use e-mail without problems and am doing
>>OK with Usenet, although it stalled after loading 700 or so message
>>headers. I tried uninstalling Netscape and putting on the version of
>>Internet Explorer provided with the modem, but that did not help.
>>
>>The problem may have something to do with the age of my computer --
>>it's an old P150 with 16MB of RAM. On the other hand, in the past I
>>ran ISDN on this computer with no problems, and I read one post from
>>someone who says he uses a 33Mhz 486.
> 
> All the stuff about more memory, larger swap file, etc. are good
> things to do but probably won't fix this problem.
> 
> Pardon my analogy to wolfing down food, but it might help explain
> what's likely going on.
> 
> 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.



-- 
Please remember the September 11th victims and their families.  Make a 
donation to a charity.


To reply to this message, replace everything to the left of "@" with 
james.knott.