Uploads crash when new DL connects

[LazyRosa]

First..My System....

Pentium 4, 3.0 GHz, 512 Ram
Windows XL Sp2 on auto update
Windows Firewall Off
McAfee Antivirus and Firewall (WinMX full access)
Belkin Router/modem 4 port wired F1PI241ENau
Internet ADSL2 (tested 1057 KiloBytes/sec Down and 122 KB/s Up)
Peak no-limit Uplink sighted on my WinMX was 109 KB/s but spikey.
I normally limit Uploads at 60 KB/s
I leave Downlink unlimited.
WinMX connection Secondary (Patch running)
Currently using static internal IP and port forwarding.
This is the only networked machine with WinMX installed.
Two Other machines connected to LAN but idle.
================================

My problem is losing all uploads when there is a modest jump in download bandwith.

Picture this typical scenario example....
   Two Downloads using combined 25 KB/s (say 10 and 15)
   Ten pending downloads (AFS 15sec AEQ 50)

   Three Uploads using combined 60 KB/s (say 20 each)
   Five queued uploads

   Stable, Bandwidth graph reasonably steady.
   max Downloads 6 and 1, max Uploads 3 and 1

These are the trigger events that usually cause download bandwidth to jump and generate a problem....

   1. A pending download becomes active, begins download
   2. An active download connects to a 2nd user, begins download
   3. I browse a user's files

Any one of these three events will trigger an immediate decay in Upload rate (from 60KB to zero in 10 secs) followed by timeouts in pending uploads.
Then progressively, all pending downloads lose their pending position and move up to the red "no sources" status as each AFS activates

Even though the increase in DL bandwidth is modest, say from 25 KB/s to 35 KB/s the effect on uploads is dramatic.

Best rescue method found (so far)....
   Quickly clear all pending or inactive    downloads, then change AFS of currently    downloading files to "Never"

This action usually keeps the current downloads active at previous speeds.
Most current Uploads will remain connected at near zero speed (less than 1 KB/s each) for 5-15 minutes, then, very gradually, speed will improve to the original 20 KB/s each. This "rescued" situation seems to be very stable if it is left unchanged.

Fixes I've checked or tried...
   1. Re-Instal WinMX versions 3.53, 3.54 beta
   2. Test static IP and port forwarding versus dynamic IP
   3. Reduce inactive/active/pending downloads to max 10
   4. Firewalls: McAfee full access, Windows off, Router set to DMZ for this computer.
    5. Speed tests by various services to confirm true D/U bandwidth
   6. Tested Ram usage from many apps running to none running.
   7. Compared time of day for busy internet variations.
   8. Tried different MX bandwith settings from tight to open.
None of these tests appeared to have any affect on the "problem"    

My questions are...
What do you think might be the root cause of the problem?
What could I check next?   

'Tis a puzzlement    
LazyRosa

[Me Here]

To be honest this sounds like a way of throttling.  I have found this once in a while with certain users when they enter my uploads it causes instablity in the other uploads however, the problem your describing with downloads I've not seen myself.  So what could be the root cause?
I suspect a couple of things mainly the ISP. 

More importantly I suggest you do the following:
Make sure your using the patch from this site, your update bar should say Patch Online above the Networks button.
Use secondary for a period of time to see if this helps.
Make sure you have limits set for uploads by limiting your Outgoing Bandwidth according to this page:
https://www.winmxworld.com/scripts/bandwidth/
Do this test with everything off except the page testing.

Run like this for at least 24 hours or better and see if this helps in any way.  Post back to let us know please.

[LazyRosa]

Thanks Me Here for considering my problem.
I've been running as suggested for the past couple of weeks...
ie Secondary connection, Always check "patch online" is showing, Uploads limited at 30, 40, 50, 60, 70 and 80 on different days for daily tests (problem can occur at any level but current 60KB/s has been adopted as a standard while testing other variables)

It's hard to be sure about ISP control, but a variety of tests suggest there is no throttle (unless it is WinMX specific)
For example, I can download at high speed from variety of sites while WinMx is running, without affecting WinMX download or Upload Bandwidth.

(Me Here, At this point of responding to your post, I decided to do a  test right now, hoping to answer the question "Is WinMX bandwidth affected when I download from other sources?" The following detail strongly suggests to me that the ISP is not causing my upload decay problem. I am convinced it is the Host connection)

THE TEST I ATTEMPTED and WHAT HAPPENED
First step... Check WinMx is currently stable with typical uploads/downloads.  Perfect.. Three uploads 25, 10, 25 and about a dozen queued.  Two downloads active 1 user each, combined speed 22 KB/s five pending with a couple of found sources each and one red, waiting for sources.
Bandwidth graph very stable. Online 9hrs 7mins. Patch online.

Second step... Download music tracks from eMusic while watching for any changes in WinMX bandwidth. 27 megs downloaded in 2 minutes = 225 KB/s
There was no affect on Bandwith graph, up or down.

Third step... Watch for a further 10 mins to observe or rule out delayed instability. It remained steady.

Fourth step... Try to trigger some instability then repeat eMusic test.
Usually, the fastest way to generate my problem is browse someone.
So I chose the first inactive queued uploader; Whois showed 432 files.
Browse seemed to stall after 38 files. I closed the Browse and Whois.
There was no effect on Down/Up Bandwidth.. still 22 and 60. Steady.
Tried Whois on a couple of other users. No reply.

Fifth step... Search for something easy to download and try to trigger by increasing the download bandwidth... I searched for "Elvis" Audio. There were NO results in the search!! Am I still connected?
Check green light is on. Yes. Top of window shows Online 9 hours plus.
Then why am I getting no whois or search results???
Then the pending downloads progressively lost their sources, turned red and became inactive. Bandwith for active uploads/downloads remained steady at 22 and 60.

Sixth step... There was obviously a problem with the host connection so, nothing to lose, I refreshed the connection. Green light.
I searched again for Elvis... plenty.
I did "Find sources Now" on each of the inactive downloads.. All found sources and returned to pending.
I did a "whois and browse" on one 117 files ok.
So a good connection exists for this browse. Closed browse.

Then a couple of minutes later, while I was musing "What to do next?", by chance one of the Uploads "Completed"

WHAT HAPPENED NEXT is the key.

The other two Uploads immediately began to decay... within 10 secs they were down to zero. From then on, the sequence was as outlined in the original post.. Queued uploads and pending downloads timeout, trickles of connection for active uploads, less than 1 KB/s for 8 mins, then gradually recovering to 60, new upload connecting and stability returning.

THE POINT IS.... The bandwidth decay problem can be triggered without an INCREASE in bandwidth use. It can also be triggered by a 20 KB/s DECREASE in bandwith use!!! 
The concept of ISP control is not consistent with that observation.

Because of the other observations relating to host connection, I am now convinced the problem is not with the ISP.
It is more likely an instability in Host connection that can be triggered in more than one way.

So Me Here, where does that leave me?
OpenNap only? Some advantages but too many disadvantages.
I'd rather avoid the decay "triggers" than restrict myself to OpenNap.
   
I think there is only one option left to try.
Your suggestion of a 24 hour "Leave it alone" connection and see if that leads to better stability. I haven't seriously tested that option so it's worth a try. It may not be easy to go for 24 hours without one of my "triggers" happening, but certainly it should be attempted.

I'll post any results, successful or otherwise.
Thanks again for giving this consideration.

[Me Here]

Hi Rosa,

Im reading this over my first cuppa of the day and so if my thoughts seem a bit scattered forgive me.

Great explanations btw, one thing that strikes me in your post is the 'host connection'.  I think its important that we use the same language here so, I may be about to explain something that you already know and are just using a different term for.

WinMX is decentralized, there is no host connection or central server to be responsible for this.  If your not sure what I mean we have a small page that explains this and it may be worth a read if  you have a sec so that you and myself and any others here have any ideas for this problem can all understand each other.
https://www.winmxworld.com/tutorials/wpn.html

OK so that would mean that this Host Connection your referring to is the pirmary user out there in WPN land.  They cant all cause this so, we have to look at things that can.  Once a connection is made to another user for a transfer, that user and yourself are directly connected, there is no middle man anymore like with searches.
That also means queued files, and transferring files.

As for the ISP issue, I do agree that a drop triggering it could indicate its not the ISP doing this however, WinMX unfortunatly is easy to pick on with the new software that ISPs use to throttle and it is VERY possible that it would be isolated in this activity, there are others that can be effected such as Bit Torrents and a few other smaller p2p systems.  Im not entirely ready to rule it out just because WInMX is the only one effected because thats actually quite common.
I do doubt that it is the cause simply because before the triggering things are rolling at decent speeds and everntually go back to those speeds.

The reason I asked you to try secondary for at least 24 hours was not to leave your system alone and not trigger this it was to see if running as secondary (there are a lot less resources used and lots less connection needed directly) made any difference.  From what Im reading above your tests where on secondary and therefore it made no difference?


I do have an idea that may help this, its just as likely to make no difference at all, however at this stage Im willing to try a few things that cant hurt if you are.

XP and Vista have a TCP connection Limit set to 10.  Now this normally wont effect  WinMX unless your in alot of rooms, using opennap and have transfers running using a primary connection.  There has been a 'hack' or patch as we like to call it out for years now to manualy up this limit and at this point I would suggest we give that a try.

So first thing I'd like you to do is read this thread, the first post explains the TCP Limit, and then scroll down to the post by me there giving exact directions on how to change this limit.
https://forum.winmxworld.com/index.php?topic=1013.0.html

Change this limit, reboot as directed, run WinMX and test it, stress it, see what happens for me next.  then Post back.

[LazyRosa]

Thanks Me Here.
The explanation around "host" answers some questions I was planning for my next post.
My gut feel is that your TCP suggestion could be right on the button.
It would explain probably ALL of the odd things I've seen happen while watching the 24 hr tests.
I'll give it a go right now and report back in 24hrs or so.
Incidentally, I have been on secondary all the time, using your preferred ports 1917 and 5353
24 hr test hasn't been going too well.  Usually I see unrequested resets occur every few hours (indicated by window caption "Online x time") without any obvios trigger.

Anxious to try your TCP link now. Thanks

[LazyRosa]

Good Morning Me Here

Get your cuppa ready for a preliminary report on test  TCP = 50
TCP patch you suggested successfully raised TCP from 10 to 50

I began  a 30 minutes of WinMX test before hitting the cot last night. As usual, within 2 minutes, 3 files were uploading at 20,20,20 = 60 K/s, the limit I set as standard for stability tests.

My list of 15 AVI downloads in progress, set at 15 min auto find and enter remote queue at 100, were finding and entering queues with apparent ease on "Find sources now".
Only one was actively downloading at about 10 K/s.
I began by trying the most consistent offender of my "upload decay triggers".  i.e.  Browsing peers.

I executed "Whois and browse" on uploading peers and queued uploaders while watching Bandwidth graphs for any significant movement.

Result: No decay in upload speed. It stayed rock steady at 60 K/s
 
So I left it running overnight, with 1 download active, about 12 downloads remotely queued and 3 uploads active and about 20 queued, stable for the past 30 mins....and thinking "I must take Me Here shopping for some Italian shoes".

This morning,
One download was active. 10 minutes to completion.
Fourteen others in the download list were red; none in remote queues.
The uploads window was empty. Some may have completed but not many; there had not been enough time for all AVIs in the midnight queue.

The caption in WinMX window showed Online for only 1 hour 20 mins.

That in itself was not a surprise. My connection to WPN frequently drops out and queued uploads/downloads all timeout. Only Active Up/Dn continue.
I tried the two standard searches I use to test if a connection is real...
"Elvis" as Audio and "John Wayne" as Video. Zero results on both.
I waited until the one download completed, closed WinMx, rebooted and restarted WinMX. Within minutes, both queues were filling and 3 uploads active at a steady 60 K/s.

I spent the next 4 hours trying to make the Uploads decay by browsing, searching, and sometimes, when browse and search gave no reply, by refreshing the connection.
The upload graph remained flat at 60 K/s.  Not a hint of decay.

During this time, browsing and searches caused semi-connections.
By semi-connection I mean the window caption showed "Online X time" but whois, browse and search produced no reply, and both queues emptied via timeout. After some minutes (varied 3 to 20 mins) of nothing except the 3 active uploads, both queues would begin to refill. This is what I would call recovering to a full-connection.

After achieving full-connection, the first one or two Whois, Browse or search attempts worked perfectly, but subsequent attempts produced no reply. In other words, the browsing generated a semi-connection.
Within minutes, the queues would again progressively timeout.

For the full 4 hours of this full-semi-full-semi cycle there was NO decay in the active uploads rate. Good news? Maybe.

At Midday, I decided enough of that test. Browsing causes problems but the TCP change has in some way stopped the upload decay. Progress has been made. So I decided on a fresh WinMX start to clear any connection problems I might have generated.

Rebooted and restarted WinMX
As usual on a fresh start, queues filled quickly and I had 3 uploads at steady 60 K/s and one download at about 10.
I decided to increase downloads by one search for "Elvis" audio. Of the few selected, two began without much delay. I switched to Bandwidth view.

A screen dump of the next 10 minutes graph tells the story better than words..
See Attached ForMeHere.JPG

At this point, I shut it down and went back to my head scratching act.
(Considering possible ISP involvement, I wondered might LimeWire be throttled? Started Limewire, picked a few "Elvis", they zipped in at better than 200 K/s. Hmm... Proves nothing).

Conclusion:
A shoe shopping spree might still be on, but not quite yet.

[Me Here]

Well Rosa I needed more than a cuppa to digest all of this really and to think about what else we can do.  It would appear that your getting hit with some sort of packets more then likely UDP and some of the monitoring tools could make the hits worse for you.

So here is what we suggest:

Lower your outgoing bandwith by half.  So from previous posts then I would assume that you will need to set it at 30000 for now.  Run for a time, test and stress it.

If you continue to see this activity then we suggst you run some network tools that allow you to see the traffic, Peerguardian 2 is one that will allow you to see any hits if they are coming from an IP address already listed in their lists, (chances are good considering the amount of IPs they have, nearly 1/3 or more of the internet)  and log it for short periods and see what ips your getting.

There are also other network tools to use and I'd rather discuss those in PM.  So if you want to PM me on site here, I can recommend a few.

Its still on my and others I've asked to read this minds that there maybe some type of throttling going on from the ISP, that when you are at peak it throttles you down levels to maintain the usage. although thats just a theory on my part.

ok so for now first thing is to lower the outgoing limits on bandwidht throttle in MX settings and run and report back to me.

Second thing Id like to know are what other protective (if any) programs you actually have running, spyware, antivirus besides McAfee, anything like that you can think of.  I noticed in your screen shot the icons on the left.. what are those for example?

Post back and let me know and we'll go from there..

* Me Here goes to get a bottle of wine.. we're gonna need it ..

[LazyRosa]

As I said in my first post Me Here.... 'tis a puzzlement

Will do on the half current upload limit.
I'm not up on all post and chat jargon (by nature I'm a hermit), but I presume PM = Personal Message?
Will do on the Peergaurdian as a first step of monitoring.

McAfee is the only antivirus/spyware etc I run. Whenever I've tested something on WinMx, I have No other Apps running, no scheduled tasks, Power saver, screen saver options all off.  Windows and McAfee AutoUpdates should be the only potential interruptions but i espect they are too infrequent to account for all my "events".
Disregard the Icons on left. They are show desktop, a shortcut to an XL file and sortcut to a VB application I wrote so I know it can not in any way effect communications or connectivity (and never run while testing)
The green Icon on the right near McAfee is an ISP connection speed monitor and router control, part of the ISP/Router software  (perhaps it does more than it pretends)
In other words I'm running as lean and clean as I know how.

Even so, this morning first thing, checked how Winmx went last night.
"Connecting", two downloads continuing, uploads queue empty, no pending downloads remotely queued. I watched without touching. At one time it connected for 13 mins then back to "connecting".
Closed out. Restarted Winmx. connected in a few secs, queues filled, uploads/downloads began. Running ok now for an hour or so.
 
I'll report back any new info or changes

[LazyRosa]

Good Morning Me Here.
Results of reducing upload bandwidth limit to 30 K/s

No searches, whois or browse attempted.
Smooth running for a little over an hour, then..... See screen dump.
Testing again at 20

[LazyRosa]

Results of re-test with Upload limit set at 20 K/s

Existing status:
Four downloads at combined 25 K/s
Two uploads, each at 10 K/s
Stable rates for nearly an hour

Trigger Event:
2nd user becomes active on a current download, jumping total rate to 40+ K/s

Immediate Effect:
Uploads decay to less than 1 K/s
Remotely queued downloads begin to drop off, then queued Uploads drop off

Longer Term Effect:
On this occasion, both active uploads stayed connected at near zero for about 15 mins, then recovered to original 20 K/s limit without affecting downloads at 40+.

Conclusion:
Same pattern of upload decay occurs at any set upload limit between 20 and 80 K/s (80 is the limit recommended by WinMx World site bandwidth test)