Max simultaneous TCP connections in Win98?

Does anyone know what the maximum number of simultaneous TCP/IP sessions
that Win98 can handle is?

I'm trying to help a friend who is using AOL+very cheap router. Everything
is fine, except when using bittorrent with 50+ peers connected.

Symptoms are total loss of connectivity, as if ethernet cable was unplugged.
He tells me that switching router off and on again gets things going, but I
don't know if this is the router locking up or a problem with Win98. I've
not been there when it happens, so i can't try the router's web page or
telnet to find out....

Anyone seen anything like this before? The router is a 'mentor' - conexant
chipset, and i've already tried latest firmware, which made no difference...

Thanks,
Dan.

On Thu, 15 Jul 2004 22:28:08 +0100, "Mr. Wood"
<(E-Mail Removed)> wrote:

>Does anyone know what the maximum number of simultaneous TCP/IP sessions
>that Win98 can handle is?

That isnt the cause of your problem.

>I'm trying to help a friend who is using AOL+very cheap router. Everything
>is fine, except when using bittorrent with 50+ peers connected.

That is the cause of the problem.

>Anyone seen anything like this before?

Yes, the p2p peers are filling up the 256k reverse path.
Congesting TCP ACK traffic as a consequence.

Use a decent btorrent client and limit uploads to 192 kilobits.


greg


--
Konnt ihr mich horen?
Konnt ihr mich sehen?
Konnt ihr mich fuhlen?
Ich versteh euch nicht

> Yes, the p2p peers are filling up the 256k reverse path.
> Congesting TCP ACK traffic as a consequence.
>

D'oh. Obvious when you think about it! Cheers...

Dan.

> >Does anyone know what the maximum number of simultaneous TCP/IP sessions
> >that Win98 can handle is?
> That isnt the cause of your problem.

Oooooh yes it is. Win98 has a problem where it forgets to drop
connections and eventually won`t accept any more connections, reporting
buffer deadlock / tcpip stack errors.

> >I'm trying to help a friend who is using AOL+very cheap router. Everything
> >is fine, except when using bittorrent with 50+ peers connected.
> That is the cause of the problem.

My cheap router is fine, and has been since around last April - never
been rebooted unless I changed settings.

> >Anyone seen anything like this before?
> Yes, the p2p peers are filling up the 256k reverse path.
> Congesting TCP ACK traffic as a consequence.

No, I have the same problem, and i`ve used a decent bittorrent client for
months.

The data traffic up/downstream is of no consequence to this particular
problem, and it can manifest itself with zero traffic. I can have ~4
active connections in total, but the machine can still throw out errors.

Having said all that, www.sourceforge.net and download Azureus.

The update feature on it is a pain in the ass, but if you go through the
config page and limit the max connections per torrent and overall max
connections to about 45-50 and you`ll find the problem alleviates for a
while, but will still need to reboot regularly.

You can sometimes get an app to connect to the net again once you hit
this problem by closing down a *working* stack connection, ie. a torrent,
and you might find you can suddenly get mail etc. again - but it is a
sure sign you need to reboot and swear on oath you will never buy another
M$ product again.

--
Please add "[newsgroup]" in the subject of any personal replies via email
--- My new email address has "ngspamtrap" & @btinternet.com in it ;-) ---

On Fri, 16 Jul 2004 00:40:39 +0100, Colin Wilson <(E-Mail Removed)>
wrote:


>
>No, I have the same problem, and i`ve used a decent bittorrent client for
>months.

That's because you have no clue about what I am referring to.

A 'decent' bittorrent client will congest a 256k reverse path serving peers
every bit as easily as an 'indecent' one.


>
>The data traffic up/downstream is of no consequence to this particular
>problem, and it can manifest itself with zero traffic. I can have ~4
>active connections in total, but the machine can still throw out errors.

The number of active connections is *irrelevant* if TCP ACK traffic is
disrupted by congestion.

>
>Having said all that, www.sourceforge.net and download Azureus.
>
>The update feature on it is a pain in the ass, but if you go through the
>config page and limit the max connections per torrent and overall max
>connections to about 45-50 and you`ll find the problem alleviates for a
>while, but will still need to reboot regularly.

Clueless bullshit. 45-50 active peer connections down a 256k pipe just
wont work period.

I suggest figuring out how TCP retransmit and backoff works to see why.

>You can sometimes get an app to connect to the net again once you hit
>this problem by closing down a *working* stack connection, ie. a torrent,

Which *removes* congestion from the reverse path. Allowing TCP ACK traffic
to flow, what a surprise.

>and you might find you can suddenly get mail etc. again - but it is a
>sure sign you need to reboot and swear on oath you will never buy another
>M$ product again.

Oh puhleeze get a f*cking grip. It has SFA to do with what OS is running.

Try reading

http://btfaq.com/cgi-bin/fom?_recurse=1&file=34#file_38

"Sometimes, limiting your upload rate will increase your download rate.
This is especially true for asymmetric connections such as cable and ADSL,
where the outbound bandwidth is much smaller than the inbound bandwidth. If
you are seeing very high upload rates and low download rates, this is
probably the case. The reason this happens is due to the nature of TCP/IP
-- every packet received must be acknowledged with a small outbound packet.
If the outbound link is saturated with BitTorrent data, the latency of
these TCP/IP ACKs will rise, causing poor efficiency."


http://www.benzedrine.cx/ackpri.html


It may enlighten you somewhat.



greg

--
Konnt ihr mich horen?
Konnt ihr mich sehen?
Konnt ihr mich fuhlen?
Ich versteh euch nicht

> I suggest figuring out how TCP retransmit and backoff works to see why.
>
> >You can sometimes get an app to connect to the net again once you hit
> >this problem by closing down a *working* stack connection, ie. a torrent,
>
> Which *removes* congestion from the reverse path. Allowing TCP ACK traffic
> to flow, what a surprise.

Not wishing to prolong the slanging match, but if they substitute a
Windows2000 laptop for the Win98 machine and leave all other settings as
they are, the problem goes away.

It could be that Win2000 has the ability to have many simultaneous TCP/IP
sessions, while Win98 cannot. Or it could be that Win2000 has a more
intelligent TCP/IP stack that gives priority to sending ACK packets before
anything else...

Don't suppose we'll really know what's happening until I can get over there
and sniff some packets with a cheapo hub and Ethereal...

Has anyone running win98 got a 'preferred' bittorrent client they could
recommend?

Cheers,
Dan.

On Fri, 16 Jul 2004 17:06:22 +0100, "Mr. Wood"
<(E-Mail Removed)> wrote:

>

>It could be that Win2000 has the ability to have many simultaneous TCP/IP
>sessions, while Win98 cannot.

IF the uplink is congested, the OS is irrelevant.

>Or it could be that Win2000 has a more
>intelligent TCP/IP stack that gives priority to sending ACK packets before
>anything else...

It doesnt.




greg

--
Konnt ihr mich horen?
Konnt ihr mich sehen?
Konnt ihr mich fuhlen?
Ich versteh euch nicht

> Has anyone running win98 got a 'preferred' bittorrent client they could
> recommend?

Azureus www.sourceforge.net

--
Please add "[newsgroup]" in the subject of any personal replies via email
--- My new email address has "ngspamtrap" & @btinternet.com in it ;-) ---

> Clueless bullshit. 45-50 active peer connections down a 256k pipe just
> wont work period

I see this problem even if there are <5 peer connections with no
throughput (ie. on well seeded torrents) after the machine has been on
for a couple of days.

Win98 *has* got a well documented problem with the tcp/ip stack which I
believe was resolved (eventually) in the NT kernel.

> Oh puhleeze get a f*cking grip. It has SFA to do with what OS is
> running.

I don`t hear many complaints from linux users on this issue.

You talk a good game though.

--
Please add "[newsgroup]" in the subject of any personal replies via email
--- My new email address has "ngspamtrap" & @btinternet.com in it ;-) ---

On Fri, 16 Jul 2004 22:13:54 +0100, Colin Wilson <(E-Mail Removed)>
wrote:





>
>Win98 *has* got a well documented problem with the tcp/ip stack

You haven't produced a whit of documentary evidence.

Least of all evidence linking this allegedly 'documented' problem with that
of reverse path congestion.


>which I believe was resolved (eventually) in the NT kernel.

Which has *what* to do with reverse path congestion on asymmetric broadband
traffic.

>
>> Oh puhleeze get a f*cking grip. It has SFA to do with what OS is
>> running.
>
>I don`t hear many complaints from linux users on this issue.

Don't teach your grandmother how to suck eggs.

http://tinyurl.com/6b2nm

Note the newsgroup and the date.




greg

--
Konnt ihr mich horen?
Konnt ihr mich sehen?
Konnt ihr mich fuhlen?
Ich versteh euch nicht