I have BT BB 512kbs after being online for a certain amount of time, the upstream/downstream bandwidth runs to 0 bytes - can't even open google!?!?$ I have unchecked all power management tabs I am using a BT Voyager 205 adsl router, which is connected to my pc with usb (not ethernet)
anything else?
I have a 12gb hard drive, which is getting pretty full - only have about 1gb left. I am sure that is not the problem, but i am getting desperate.
BT say there is nothing wrong with the line - they would though. one corporation i hate is bt, but as i have no bank account i have no direct debit, and bt allows you to buy broadband with your quarterly bill. i'd phone them up but it takes a few hours to get through to a human being!!
This is very annoying, as, just coming back from town, i'd left winmx running only to find all files timed out and disconnected, especailly when there is a queue of 50 or more - even more annoying, i, at last, was d/loading a joy division video which i've never seen before, and thus have just half of it.
You may want to carefully measure and throttle your upload rate. Once it gets backed up, your _downloading_ will also stop.
This is a known TCP weakness, exacerbated by asymmetric links. Nothing to do with your ISP. Does anyone have a more advanced TCP/IP stack scheduler that lets ACKs jump the outbound queue? Or does this introduce other problems?
Create a directory. On drive "C:\" (e.g., "c:\New Folder") or the desktop (e.g., "C:\Documents and Settings\lipman\Desktop\New Folder")
Download SYSCLEAN.COM and place it in that directory. Download the Trend Pattern File by obtaining the ZIP file. For example; lpt271.zip
Extract the contents of the ZIP file and place the contents in the same directory as SYSCLEAN.COM.
2) Update Adaware with the latest definitions.
3) If you are using WinME or WinXP, disable System Restore
formatting link
Reboot your PC into Safe Mode
5) Using both the Trend Sysclean utility and Adaware, perform a Full Scan of your platform and clean/delete any infectors/parasites found. (a few cycles may be needed)
6) Restart your PC and perform a "final" Full Scan of your platform using both the Trend Sysclean utility and Adaware
7) If you are using WinME or WinXP,Re-enable System Restore and re-apply any System Restore preferences, (e.g. HD space to use suggested 400 ~ 600MB),
8) Reboot your PC.
9) If you are using WinME or WinXP, create a new Restore point
Just rambling here, Robert, but I believe this is a myth.
TCP/IP does not require per-packet ACKs, the protocol allows for ACK delays and gang-ACKs. The transmitter will continue to transmit packets up to a negotiated limit (7 or more, if my recollection hasn't failed entirely) or timeout.
WinMX, on another hand, requires per MX-packet control - by this I mean that MX implements multi-sourcing by informing the transmitter of which part of the file it is to send next. Apparently, MX does not care whether multiple sources are actually transmitting - it uses this logic statically.
So we MX users get bogged down when these "command" packets get backed up in the outbound data queue (they are, after all, data not TCP/IP controls). And this queue is managed by MX not by Winsock - so failure to promote control packets is MX's problem!
Part of this problem too is that these packets contain very little data and carry a sever overhead due to TCP/IP's minimum
64 byte packet size. MX does not (and frankly, very few other applications do) take into account the actual size of the packet when throttling. Rather, it calculates the throttle on data bytes. Depending up the number and speed of downloads in progress, combined with upload file demand, the whole shebang can slow down quite a bit (relatively speaking) but it will not choke, merely limp. The MX bandwidth meter and activity stats become skewed because of the unaccounted for overhead. A separate meter would show that the uplink is fully saturated (and what more could we want?). I've yet to see a source or uploader drop off during this bandwidth crisis due to time out.
Aside from the overview, access to the details is limited to ACM members. Perhaps you can provide some more explicit info from those points?
From what I've read in the past, the argument has been well made regarding network asymmetric bandwidth (for example on cable ISP groups). In these cases, overbooking the lower bandwidth uplink can indeed cause ACK slowdown as the various modems compete for the space available. In typical home user's PCs however, the Winsock layer seems to adequately handle ACK priority and certainly in the case of WinMX this is true - as the application control packets' lag introduce their own compensating "throttle."
The reason I say this is because those MXers uploading from us also have to send control packets, which have to work their way into the download stream. And these MX controls operate outside the TCP/IP layer.
Just based on observation here (4000/560 cable) while operating as a secondary I can exchange data with a single source and maintain 70 kB upload speed. At the same download speed from multiple sources, upload data speed suffers because of the MX control packets required to support the downloads and their overhead.
Would you mind sharing your math on this.
1.5 mbps is 187,500 Bps / 1500 Bpp = 125 pps. Even if an ACK required the 64 byte minimum of a data packet, that would only be 125 packets * 64 bits or 8,000 bps. How do you come up with
40,000 bps?
Well, there is no way for the intelligent OS to know that the app is sending file positioning instructions, is there?
How so? An app merely submits data to Winsock when it is ready. How an app does its own buffering is of no concern to the socket layer. If there is hardware buffering (NIC, router, modem) then it is sufficient to handle its rated capacity, no?
Well, yes - if I'm using MX unthrottled (or max throttled) and uploading like a banshee, my browses will suffer as the outbound requests to web sites get queued too (different ports, not a socket layer queue problem - but waiting for the ISP to pass on the request). Likewise, I can only download outside of MX at the rate that my source for that download is able to compete with MX's sources.
I don't know how your cable or broadband works but mine, which is probably typical, transfers data bidirectionally at much higher speeds than my caps of 4000/560. The average bandwidth my ISP allocates to me is achieved by them simply delaying responses to bring my speed back in line.
For example, my cable modem operates at 573 MHz d/l and 33 MHz u/l (way above my caps (or it's sampling d/l @ 146 and u/l @ 60 times per bit??). This may be a more modern ISP/channel/modem interface than was referred to in the sopplied URL overview, and which mitigates the customers' modems' competition for channel capacity regardless of usage.
True. This lessens the problem, but does not eliminate it. A 1.5 Mbit/s downlink shovelling 1500 byte packets _needs_
40kbit/s uplink if it ACKs each packet, 20 if every second packet and 10 if every 4th. Furthermore, latency can cause problems.
Then it should probably use UDP to generate it's own fancier ACKs.
This gets to the heart of the problem. There is an important, limited, shared resource -- upstream bandwidth. It should be under intelligent OS control so that competing applications are allocated their fair share.
Also, note that the size of hardware outbound FIFOs can work against you.
I believe this is true for MX by itself. But there are other users of upstream bandwidth who may not have as much patience.
The OP was complaining about the usability of his machine for other tasks while MX was running. I think it was hogging the limited upstream bandwidth, and the problem is exacerbated by an OS too dumb to prioritize outbound packets.
Sometimes the app will have to assume the OS is FIFOing. But othertimes, it can use a different (hi-prio) port, or send small packets (which the OS could detect & bump up).
True. The app should be as intelligent as possible. I'm more concerned with how the OS buffers & prioritizes between competing apps.
Likely oversized, which will lead to increased latency. Some of these devices have dozens of seconds worth of outbound buffering. It may take deliberate OS throttling to drain these buffers and give good latency.
Yes, this is the problem. A smart OS would send that http request earlier. The fact that it doesn't gives users an unpleasant experience and leads them to drop p2p or other uploading software.
If the OS won't do it, then the p2p should have some sort of congestion control to ensure it doesn't interfere with other traffic.
Yes, DOCSIS cable modems cap their media access rates. I'm on 1.5/256 ADSL. I don't think it makes much difference. Saturated is saturated. ACKs are delayed or dropped, and the unsaturated pipe suffers.
There is a current discussion on this subject on a zpg mailing list by the name of 'p2p hackers' - hackers not in the daily sun sense but in the sense of those who designed tcp/ip..
The upshot of it is that doing things by UDP is a much better idea, partly because you lose the overhead of keeping numerous sockets open and partly because doing all of the buffering/flow regulation/error checking in your own code means that you are in control of the queuing and prioritising.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.