| Author |
Message |
alexander
Guest
|
 Posted:
Tue Nov 30, 2004 11:10 pm Post subject:
bandwidth runs down to zero after 30 mins or more |
|
|
anybody any ideas pretty please?
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.
any help would be appreciated
alex |
|
| Back to top |
|
 |
Robert Redelmeier
Guest
|
| Posted:
Tue Nov 30, 2004 11:50 pm Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
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?
-- Robert |
|
| Back to top |
|
|
David H. Lipman
Guest
|
| Posted:
Wed Dec 01, 2004 3:15 am Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
1) Download the following three items...
Trend Sysclean Package
http://www.trendmicro.com/download/dcs.asp
Latest Trend signature files.
http://www.trendmicro.com/download/pattern.asp
Adaware SE (free personal version v1.05)
http://www.lavasoftusa.com/
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
http://vil.nai.com/vil/SystemHelpDocs/DisableSysRestore.htm
4) 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
* * * Please report back your results * * *
Dave |
|
| Back to top |
|
|
db
Guest
|
| Posted:
Wed Dec 01, 2004 3:34 am Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
If you're running a primary connection, try secondary instead (set that on
the Networks window in WinMX). |
|
| Back to top |
|
|
Lurch
Guest
|
| Posted:
Wed Dec 01, 2004 4:38 am Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
| Quote: | i'd left winmx
running only to find all files timed out and disconnected,
|
I knew this bit was coming, get used to it. Either have an internet
connection that is usable, or clog it up with flakey P2P software.
--
SJW
A.C.S. Ltd
Please reply to group or use 'usenet' in email subject |
|
| Back to top |
|
|
Gee
Guest
|
| Posted:
Wed Dec 01, 2004 6:24 am Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
Pls see thread called "BT Broadband loses webpage access" for more
suggestions. Its possibly Voyager. |
|
| Back to top |
|
|
alexander
Guest
|
| Posted:
Wed Dec 01, 2004 7:18 pm Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
thanks, I will get back to you soon as poss. good of you to devote
such time to my problem.
alex |
|
| Back to top |
|
|
alexander
Guest
|
| Posted:
Wed Dec 01, 2004 7:21 pm Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
| Quote: | Pls see thread called "BT Broadband loses webpage access" for more
suggestions. Its possibly Voyager.
|
ta to all for advice
working on it
alex |
|
| Back to top |
|
|
Gee
Guest
|
| Posted:
Wed Dec 01, 2004 8:27 pm Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
| Quote: | ta to all for advice
working on it
alex
|
Welcome.
Do let us know what works :) Jus for da future reference :) |
|
| Back to top |
|
|
Billy Joe
Guest
|
| Posted:
Wed Dec 01, 2004 10:21 pm Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
| Quote: |
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?
-- Robert
|
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.
BJ |
|
| Back to top |
|
|
Robert Redelmeier
Guest
|
| Posted:
Thu Dec 02, 2004 12:03 am Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
| Quote: | Just rambling here, Robert, but I believe this is a myth.
|
Not quite. See http://portal.acm.org/citation.cfm?id=277877
and some RFCs (particularly 2760).
| Quote: | TCP/IP does not require per-packet ACKs, the protocol allows
for ACK delays and gang-ACKs. The transmitter will continue
|
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.
| Quote: | WinMX, on another hand, requires per MX-packet control -
|
Then it should probably use UDP to generate it's own
fancier ACKs.
| Quote: | And this queue is managed by MX not by Winsock - so failure
to promote control packets is MX's problem!
|
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.
| Quote: | 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.
|
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.
-- Robert |
|
| Back to top |
|
|
Billy Joe
Guest
|
| Posted:
Thu Dec 02, 2004 1:26 am Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
Robert Redelmeier wrote:
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.
| Quote: | TCP/IP does not require per-packet ACKs, the protocol allows
for ACK delays and gang-ACKs. The transmitter will continue
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.
|
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?
| Quote: | WinMX, on another hand, requires per MX-packet control -
Then it should probably use UDP to generate it's own
fancier ACKs.
And this queue is managed by MX not by Winsock - so failure
to promote control packets is MX's problem!
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.
|
Well, there is no way for the intelligent OS to know that the
app is sending file positioning instructions, is there?
| Quote: | Also, note that the size of hardware outbound FIFOs can work
against you.
|
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?
| Quote: | 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.
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.
|
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.
Of course, I could be wrong ;-0)
BJ |
|
| Back to top |
|
|
Robert Redelmeier
Guest
|
| Posted:
Thu Dec 02, 2004 2:25 am Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
| Quote: | Aside from the overview, access to the details is limited to ACM
members. Perhaps you can provide some more explicit info from
those points?
|
Sorry, try this:
| Quote: | 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.
|
Downloading through a fat pipe & sending small ACKs up the
skinny pip is unlikely to cause trouble.
| Quote: |
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?
|
IIRC, a TCP ACK packet is 40 bytes, not 64 bits! You missed
8 bits/byte: 125 p/s * 8 bit/byte * 40 byte/p = 40kb/s
| Quote: | Well, there is no way for the intelligent OS to know that
the app is sending file positioning instructions, is there?
|
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).
| Quote: | How an app does its own buffering is of no concern
to the socket layer.
|
True. The app should be as intelligent as possible.
I'm more concerned with how the OS buffers & prioritizes
between competing apps.
| Quote: | If there is hardware buffering (NIC, router, modem) then
it is sufficient to handle its rated capacity, no?
|
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.
| Quote: | 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
|
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.
| Quote: | 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
|
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.
-- Robert |
|
| Back to top |
|
|
Billy Joe
Guest
|
| Posted:
Thu Dec 02, 2004 2:37 am Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
Robert Redelmeier wrote:
<snip>
| Quote: | IIRC, a TCP ACK packet is 40 bytes, not 64 bits! You missed
8 bits/byte: 125 p/s * 8 bit/byte * 40 byte/p = 40kb/s
snip |
Oh slap me, I needed that !! Thanks for the math refresher ;-0)
BJ |
|
| Back to top |
|
|
Dave J
Guest
|
| Posted:
Fri Dec 03, 2004 3:20 pm Post subject:
Re: bandwidth runs down to zero after 30 mins or more |
|
|
| Quote: | 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.
Well, there is no way for the intelligent OS to know that the
app is sending file positioning instructions, is there?
|
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.
Dave J. |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in