Anon | Connection stops while downloading!! Sometimes when I download a file bigger than 50 megs, I leave it on while I go eat or something. When I get back, most of the time it just stops and it's not the server, can someone help me please? |
|
emf3
join:2001-05-04
Laguna Hills, CA | Impulsity --
I'm not 100% sure, but it sounds like your DSL modem is loosing sync & dropping the connection . . . I had a similar problem.
a) Are you Enhanced?
b) What modem are you using?
c) How what's your distance to the CO?
d) What speeds are you getting currently?
Eric |
|
Anon | a) Are you Enhanced?
Yeah, I was uncapped
b) What modem are you using?
Westell modem
c) How what's your distance to the CO?
No clue
d) What speeds are you getting currently?
On sitse like netscape.com and blizzard.com 120k/s usually on fast servers |
|
|
|
emf3
join:2001-05-04
Laguna Hills, CA | said by impulsity:
c) How what's your distance to the CO?
No clue
Can you pre-qual at »/prequal -- it's not perfect, but it's a reference point.
said by impulsity:
d) What speeds are you getting currently?
On sitse like netscape.com and blizzard.com 120k/s usually on fast servers
Can you run thru a speed test at »/stest
Is it only with large d/loads, or is it consistently under load? How long does it typically take before the transfer stalls?
Eric |
|
Anon | c) How what's your distance to the CO?
About 15100 feet
d) What speeds are you getting currently?
** Speed 1096(down)/102(up) kbps ** |
|
Anon | reply to emf3
help please? |
|
Anon
| Yeah, well, we need more information regarding your line/router paths activities over a span of longer period.
Would you please try this for a few days and post the results back here so we can see...use one of your download site as the target...the longer path the better..
--
Not qualify? 20,000 feet? Pronto? liar !
[text was edited by author 2001-05-22 01:17:25] |
|
emf3
join:2001-05-04
Laguna Hills, CA
| reply to Anon
impulsity -- Apologies, this dropped off the radar w/ a couple other issues.
JeopCodes is right -- based on the details that you provided, there's really more info required.
Eric
BTW -- Is the problem only with large d/loads, or is it consistently under load? How long does it typically take before the transfer stalls?
Jeopcodes -- What would you guess as a stable sync speed @15k ft?
[text was edited by author 2001-05-22 01:35:12] |
|
Anon
| said by emf:
Jeopcodes -- What would you guess as a stable sync speed @15k ft?
[text was edited by author 2001-05-22 01:35:12]
With good IW and no Bridge Taps, no T1 disturbances, you can easily have a 1.5M stable sync over time...
--
Not qualify? 20,000 feet? Pronto? liar ! |
|
 vkrExMod 2001-06
join:2001-04-03
Terra | reply to Anon
If you can get in the queue, you may want to try DSLR's Tools/Line Quality "Line Packet Loss Testing".
»/testme
It may let you know if your dropping packets, or identify high latency.
vkross
--
If I'm not here, then I'm somewhere else. |
|
Anon
| said by vkross:
If you can get in the queue, you may want to try DSLR's Tools/Line Quality "Line Packet Loss Testing".
»/testme
It may let you know if your dropping packets, or identify high latency.
vkross
The "Line Testing" in DSLR is kind of short, and may not test long enough to tell the whole story. I am actually thinking about maybe his PC equipment problem but not 100% sure yet...
He can also try running some PC diagnostic software (the one that PC Manufacturer used to burn their PC for 24-48 hours before they ship) over a period of a few days to make sure his PC is in top notch..
--
 Not qualify? 20,000 feet? Pronto? liar !
[text was edited by author 2001-05-22 03:05:13] |
|
vkrExMod 2001-06
join:2001-04-03
Terra | said by JeopCodes:
The "Line Testing" in DSLR is kind of short, and may not test long enough to tell the whole story. I am actually thinking about maybe his PC equipment problem but not 100% sure yet...
We're probably on the same page;
The Line Quality test *may* identify a *consistent* marginal line problem.
Yes, it is short and unlikely to identify an *intermittent* problem.
Then again if PingPlotter is issuing a standard ping it *may* not detect the failure either. You can have outages affecting specific ports/sockets. I've had times when ping worked and trace route didn't and vice-versa. And, many other examples like this.
I am also wondering about the workstation or OS. I vaguely remember something about long downloads and Windows, but CRS at this moment.
vkross
--
If I'm not here, then I'm somewhere else. |
|
Anon
| That rings a bell! What we need is a real time analysis program like this NETSTAT program running while he download that 50MB file so we can see his DSL line condition as well as the local system resource usage (see whether he is overloading the CPU cycles or the DSL bandwidth)..
Good point !
--
Not qualify? 20,000 feet? Pronto? liar!
[text was edited by author 2001-05-22 04:46:42]
[text was edited by author 2001-05-22 04:49:06] |
|
vkrExMod 2001-06
join:2001-04-03
Terra | said by JeopCodes:
What we need is a real time analysis program like this NETSTAT program running while he download that 50MB file so we can see his DSL line condition as well as the local system resource usage (see whether he is overloading the CPU cycles or the DSL bandwidth)..
Good point !
Good idea.
I haven't used AnalogX, maybe someone can elaborate on it's functionality. I use ZDNet Netmonitor, but am always looking for a better monitor. It would be nice to find one that monitors and includes a decent trace facility...
I still think the Line Quality Test and PingPlotter have a benefit, if he can run them as well.
vkross
--
If I'm not here, then I'm somewhere else. |
|
Anon | It usually takes files over 50 megs and if I'm downloading over 50k/s or higher. Should I try that netStat thing? How does it work? |
|
Anon | Ok, I downloaded AnalogX NetStat, what do you guys need me to do? |
|
Anon
| While running these tests, I played an mp3 for like 3 minutes which could have contributed to CPU usage. I didn't do anything after that. I'd post pictures but geocities sucks please copy the link and paste into your browser because geocities won't post pictures.
Test 1 [Part 1]
»www.geocities.com/fubartemp/test1p1.jpg
I think the server died on this one.
Test 2 [Part 1]
»www.geocities.com/fubartemp/test2p1.jpg
It was going steady here after 20 megs
Test 2 [Part 2]
»www.geocities.com/fubartemp/test2p2.jpg
It stayed like this pretty much until the end. I think this is the first time I have ever downloaded a file over 100 megs without it stopping.
[text was edited by author 2001-05-24 23:12:16] |
|
Anon | reply to Anon
Install NETSTAT and fire it up! It shows you the traffic as it appears on your line as well as it monitors your CPU loads. Try familiar yourself with NETSTAT first. With NETSTAT running, try to go to a download website and start your 50M Download and watch the "load" indicator on NETSTAT and see where it is when connections stop. Click on NETSTAT window to make it active so your can "Alt"+"Prnt Scrn" and take a snapshot, load it in some "Paint" or equivalent graphic program, reduce size, color whatever to make file size small but readable, save it in GIF format, and upload here so we all can take a look what at state your computer is when the connection stop...
--
Not qualify? 20,000 feet? Pronto? liar! |
|
Anon
| reply to Anon
Test 1 [Part 1]
»www.geocities.com/fubartemp/test1p1.jpg
I think the server died on this one.
Test 2 [Part 1]
»www.geocities.com/fubartemp/test2p1.jpg
It was going steady here after 20 megs
Test 2 [Part 2]
»www.geocities.com/fubartemp/test2p2.jpg
Looks like Test 1 is in the process of cranking up speed and then DIED !!
Test 2, Part 1, things start warming up with steady stream of data at 149K down, 7.5k up, with 24% cpu utilization, which is quite heavy cpu usage..
Test 2, Part 2, things are even steadier with 151K down, up remains the same at 7.5k, cpu utilization steady at 25% which is good..
So the problem is "INITIAL" crank-up that cause your connection to DROP like a bomb, going, going, going, and then bomb, it's dead !! I need some time to think about what cause the "INITIAL DEAD" !!
--
Not qualify? 20,000 feet? Pronto? liar!
[text was edited by author 2001-05-24 23:24:07]
[text was edited by author 2001-05-24 23:33:19] |
|
Anon | reply to Anon
...back again...thinking about the logic/function chains happened when a download is initiated.
User requests --> CPU Acknow, sent IRQ --> NIC activated --> sending download request via modem and onto the website.
WebSite responses, after some handshaking, started to send data downstream --> modem --> NIC start receiving data --> CPU --> harddisk controller --> hard disk starts saving data...
And so data stream coming in faster and faster on its way to the normal download speed for a 1.5M line --> NIC starts passing data all the way to the harddisk...
All out of a sudden, CPU doesn't see any more data coming and of course knows there are "supposed" to be more data coming so CPU went into "wait" state...
So who stops receiving data here? The modem? The NIC itself? Or the "Receive Windows Buffer" is too small (buffer overflow?) or slow to adjust itself to a gradually increasing speed of data stream?
1) So have you gone to the "Tweak" section yet to tweak your computer?
2) Any loose connection between the wall jack to the modem, or the 10BaseT cable to the PC?
3) Have you try a different NIC yet or putting the NIC to a different PCI slot?
Still thinking, will be back later, got to eat...
--
Not qualify? 20,000 feet? Pronto? liar! |
|
